Cka 정리3

CKA 정리3

cka3

120: OS Upgrade

base S/W를 업데이트하거나 보안패치등을 클러스터에 적용하는 등의 유지보수 목적으로 일부 노드를 중단하는 시나리오를 생각해보고 이 때 사용할 수 있는 옵션들을 알아보자

앱을 여러 노드와 파드들로 배포하였다. 특정 노드가 다운된 상황을 가정하자. 이 때, 파드를 배포한 방법에 따라 사용자는 파드에 접근할 수도 있고 없을 수도 있다

다른 노드에 replica로 존재하는 파드라면 서비스 접근에 문제 없을 것이지만 다운된 해당 노드에만 유일하게 존재하던 파드라면 사용자는 해당 서비스를 이용하지 못할 것이다.

k8s는 해당 노드가 다시 뜨면 파드를 다시 띄우겠으나 노드가 5분 이상 다운되면 k8s는 죽은 것으로 간주하고 해당 pod를 종료한다. 파드가 다시 온라인 상태가 될 때까지 기다리는 시간을 pod-eviction-timeout이라고 하며 컨트롤러 매니저에서 default값 5분으로 설정된다. 노드가 오프라인 상태가 될 때마다 마스터 노드는 노드가 죽은 것으로 간주하기 전에 최대 5분 동안 기다려주는 것

pod eviction timeout 이후 노드가 다시 온라인되면 노드는 파드 없이 비어있는 상태가 된다물론 replicaset의 일부인 pod였다면 다른 노드에서 띄울테니 상관없다하지만 이보다 더 안전한 방법이 있으니 실행중인 workload를 클러스터의 다른 노드로 옮겨 의도적으로 노드를 비울 수 있다.

• $ kubectl drain node-1

위 명령어는 파드를 이동시킨다기보다는 현재 노드의 파드들을 종료시키고 다른 노드에서 생성되게 하는 것이다. 그렇지만 replicaset이라면 에러가 발생하고 –ignore-daemonset 옵션 추가해줘야할 수 있다

• $ k drain –ignore-daemonsets node01

또한 노드는 cordoned되거나 unschedulabled로 표시되어 제한을 제거할 때까지 이 노드에서 파드를 예약할 수 없다. 이후 노드를 재부팅하면 온라인 상태가 되었지만 여전히 unschedulabled이다. Pod가 다시 스케쥴링될 수 있도록 uncordon해준다

• $ kubectl uncordon node-1 drain 및 uncordon 외에도 cordon이라는 또 다른 커맨드가 있다. Cordon은 단순히 노드를 unschedulable로 표시합니다. drain과 달리 기존 노드에서 파드를 종료하거나 이동하지 않고 단순히 새 파드가 해당 노드에 스케쥴링되지 않도록 한다.

  123: Kubernetes Software Versions

  k8s SW의 버젼 확인하는 법을 알아보자

• $ k get nodes

  125: Cluster Upgrade Process

  k8s의 클러스터 업그레이드를 알아보자 지금은 ETCD 및 CoreDNS와 같은 외부 컴포넌트에 대한 종속성을 유지하면서 핵심 컨트롤 플레인 컴포넌트에 집중할 것입니다. 이들 모두가 동일한 버전을 갖는 것이 필수일까요? 아닙니다. 컨포넌트는 다른 릴리스 버전을 가질 수 있습니다. kube API server는 컨트롤 플레안의 primary 컴포넌트이고, 다른 모든 컴포넌트와 통신하는 컴포넌트이기 때문에 다른 컴포넌트는 kube API 서버보다 높은 버전이면 안됩니다. 컨트롤러 매니저와 스케줄러는 한 버전 낮을 수도 있습니다. 따라서 kube API 서버가 x에 있으면 컨트롤러 매니저와 kube 스케줄러는 x-1에 있을 수 있습니다. 그리고 kubelet 및 kube 프록시 컴포넌트는 x에서 2를 뺀 두 가지 낮은 버전일 수 있습니다. 따라서 kube API 서버가 1.10인 경우, 컨트롤러 매니저와 스케줄러는 1.10 또는 1.9 일 수 있습니다. kubelet 및 kube 프록시는 1.8일 수 있습니다.  1.11처럼 kube API 서버보다 높은 버전만 아니면 됩니다. 

그러나 kubectl은 다릅니다. kubectl 유틸리티는 API 서버보다 높은 1.11버전일 수 있습니다. 또는 API 서버와 동일한 1.10 버전일 수도 있습니다. 혹은 API 서버보다 낮은 1.9버전일 수도 있습니다. 이제 이 허용 가능한 버전 skew를 통해 라이브 업그레이드를 수행할 수 있습니다. 필요한 경우 컴포넌트별로 업그레이드를 진행할 수 있습니다.

클러스터 업데이트 전략

1. 동시 일괄 업데이트
   • 모든 노드 중지하고 파드들 내쫓고 업데이트
   • 완료후 재개
   • downtime 존재
2. 하나씩 업데이트
   • 여러 노드에 배포된 다른 파드에서 서비스 제공받을 수 있으므로 하나씩 업데이트
3. 신규 sw 노드를 클러스터에 추가
   • 자원이 넉넉한 경우 미리 업데이트된 노드를 추가
   • 파드를 신규 노드로 이주
   • 기존 노드 제거

kubeadm - Upgrade master node

kubeadm으로 $ kubeadm upgrade plan 커맨드를 실행하면 현재 클러스터 버전, kubeadm tool 버전, Kubernetes의 최신 stable 버전 등 유용한 정보를 많이 얻을 수 있다

• controlplane 컴포넌트를 업데이트한 뒤 각 노드에서 kubelet 버젼을 수동으러 업데이트한다.
  1. kubeadm tool update
• $ apt-get upgrade -y kubeadm=1.12.0
  1. $ kubeadm upgrade plan output
  2. $ kubeadm upgrade apply

kube control get nodes 커맨드를 실행하면 여전히 마스터 노드가 1.11로 표시됩니다. 이는 이 커맨드의 출력에서 API 서버 자체의 버전이 아니라 API 서버에 등록된 각 노드의 kubelet 버전을 표시하기 때문

다음은 kubelet을 업데이트한다  설정에 따라 마스터 노드에서 실행 중인 kubelet이 있을 수도 있고 없을 수도 있다. 이 경우 kubeadm으로 배포된 클러스터에는 마스터 노드에 kubelet이 있으며, 이는 마스터 노드에서 컨트롤 플레인 컴포넌트를 실행하는 데 사용된다.

마스터노드에 kubelet이 있는 경우

• $ apt-get upgrade kubelet
• $ systemctl restart kubelet
• 확인
  • $ k get nodes 결과, 마스터 노드 버젼이 업데이트 됨을 알 수 있다

    kubeadm - Upgrade worker node

    워크로드를 다른 노드로 옮기기 $ kubectl drain node01

• node를 cordon하고 unschedulable하게 만든다

마스터노드에서처럼 워커 노드의 kubeadm과 kubelet업데이트 $ apt-get upgrade -y kubeadm=1.12.0-00 $ apt-get upgrade -y kubelet=1.12.0-00

$ kubeadm upgrade node config –kubelet-version v1.12.0

• 신규 kubelet 컴포넌트들 업데이트 $ systemctl restart kubelet 노드에 파드를 예약가능하게 다시 변경
• $ kubectl uncordon node-1

  126: Demo - Cluster Upgrade

  kubeadm을 이용하여 배포된 k8s 클러스터 업데이트를 시연한다

우선 업그레이드할 수 있는 가장 최신 버젼을 확인한다.

• $ kubeadm upgrade plan

최선 버전으로 가능한지 확인한다.

• $ apt-update
• $ apt-cache madison kubeadm 1.30.0으로 업데이트해야하는데 1.29까지만 나온다면
• $ vim /etc/apt/sources.list.d/kubernetes.list
• 파일 내부를 수정한다.
• deb [signed-by=/etc/apt/keyrings/kubernetes-apt-keyring.gpg] https://pkgs.k8s.io/core:/stable:/v1.30/deb/ /

apt-mark unhold kubectl &&
apt-get update && apt-get install -y kubectl=1.30.0-00 &&
apt-mark hold kubectl

이후 업그레이드 확인은

• $ k get nodes 에는 아직 표시되지 않는다
• $ kubeadm upgrade plan 에서는 kubeadm 버젼이 업그레이드 된 것이 표시된다. 업그레이드 적용
• $ kubeadm upgrade apply v1.30.0 이후 kubelet도 업데이트해줌
• $ apt-get install kubelet=1.30.0-1.1 재시작
• $ systemctl damon-reload
• $ systemctl restart kubelet 버젼 확인
• $ k get nodes
• 현재 노드의 Version이 v1.30.0으로 업데이트된 것을 알 수 있다.

node01의 kubeadm 버젼 업그레이드 하기 노드로 이동

• $ ssh node01 이하 동일

$ kubeadm upgrade node

129: Backup and Restore Methods

다양한 백업 및 복원방법을 다룬다

Backup Candidates

백업을 고려해야하는 항목 지금까지 deploymnet, pod, service 등을 definition 파일을 이용해 다양하게 배포했다.

• Resource Configuration
• ETCD Cluster
• 영구 볼륨

  Resource Configuration

• imperative하게 create, run, expose 등으로 생성한 파일
• declarative하게 정의한 definition file

github를 활용하면 쉽게 백업 가능하지만 imperative하게 cli로만 오브젝트를 생성했다면 어떨까? -> Kube API 서버를 쿼리하는 것이더 좋은 리소스 구성을 백업하는 방식이다.

kubectl 커맨드를 쓰거나 API 서버에 직접 접근해서 클러스터에 생성된 모든 오브젝트에 대한 모든 리소스 configuration을 복사하고 저장한다.

• $ kubectl get all –all-namespaces -o yaml > all-deploy-services.yaml 하지만 이는 일부 리소스 그룹에만 적용된다. 다른 리소스 그룹들도 고려해야 한다.

  ETCD

  etcd 클러스터는 클러스터 상태에 대한 정보를 저장한다. 클러스터 자체, 클러스터 내에 생성된 노드 및 기타 모든 리소스 정보가 저장된다. 리소스 백업 대신 etcd 서버 자체를 백업할 수 있다.

etcd는 마스터 노드에서 호스팅되는데 etcd를 구성할 때 모든 데이터를 저장할 데이터 디렉토리를 지정했다. 그곳을 백업하도록 구성하면 된다.

• 또한 etcd에는 기본 내장 스냅샷 솔루션이 있다. 다음 커맨드로 쉽게 etcd db의 스냅샷을 저장할 수 있다.
• $ ETCDCTL_API=3 etcdctl snapshot save snapshot.db
• $ ETCDCTL_API=3 etcdctl snapshot status snapshot.db (백업 상태 확인) 백업 db로부터 클러스터를 복원하려 할 때
• Kube API 서버 서비스를 중지한다
  • $ service kube-apiserver stop
• 복원한다
  • $ ETCDCTL_API=3 etcdctl –data-dir /var/lib/etcd-from-backup \
• snapshot restore /opt/snapshot-pre-boot.db
  • 신규 데이터 디렉토리가 생성된다. 이를 사용하도록 etcd configuration 파일 구성한다.
  • $ vi /etc/kubernetes/manifest/etcd.yaml 의 data-dir 수정, volumes의 hostPath 의 경로에도 수정해준다.
• 서비스 데몬 로드 및 etcd 서비스 재시작
  • $ systemctl daemon-reload
  • $ service etcd restart
• Kube API 서버 서비스 시작
  • $ service kube-apiserver start

cert, key, cacert 그리고 endpoint 지정 모든 etcdctl 커맨드를 사용할때는 인증을 위한 certificate 파일을 지정하고 etcd 클러스터에 대한 endpoint와 etcd 서버 증명을 지정해야한다

$ ETCDCTL_API=3 etcdctl –endpoints=https://[127.0.0.1]:2379 –cacert=/etc/kubernetes/pki/etcd/ca.crt
–cert=/etc/kubernetes/pki/etcd/etcd-server.crt –key=/etc/kubernetes/pki/etcd/etcd-server.key snapshot save /tmp/snapshot.db

130: Working with ETCDCTL

etcdctl은 etcd용 cli 클라이언트이다.

백업 및 복원에 etcdctl을 사용하려면 ETCDCTL_API=3 을 해줘야한다. 아니면 export ETCDCTL_API=3 으로 미리 환경변수 선언

• “kubectl config” command를 통해 현재 접속한 노드의 클러스터 관련 정보 알 수 있다.
• k config use-context cluster2 를 통해 현재 노드에서 내부 여러 클러스터들에 접근할 수 있다.

외부 etcd가 있는지 확인하는 방법은 해당 클러스터의 controlplane에 직접 ssh로 접근해서 ps 를 통해 확인가능 –etcd-servers=https://192.160.244.3:2379 해당 클러스터 ip가 아닌 다른 값이 있으므로 외부임을 알 수 있다.

+외부 etcd 에 원격 접속해서 ps aux | grep etcd하면 어디에 데이터를 저장하는지 알 수 있다 +외부 etcd에서 현재 내 클러스터가 몇개의 노드로 구성됐는지 확인 할 수 있는 명령어 ETCDCTL_API=3 etcdctl
–endpoints=https://127.0.0.1:2379
–cacert=/etc/etcd/pki/ca.pem
–cert=/etc/etcd/pki/etcd.pem
–key=/etc/etcd/pki/etcd-key.pem
member list

136: Security Section Introduction

k8s cluster 접근 권한은 어떻게 얻으며 얻으면 어떻게 제어할까? 클러스터의 설정과 인증 방식을 알아보자

TLS인증서를 이용해서 다양한 컴포넌트를 지키는 방법에 대하여.. 다양한 컴포넌트 사이에서 클러스터 내 사용되는 인증서가 많다.

목차는 다음과 같다

• k8s security primitives
• Authentication
• TLS certificates for cluster components
• Secure Persistent key-value store
• Authorization
• Image Security
• Security Contexts
• Network Policies

  138: K8S Security Primitives

  Secure Hosts

  클러스터를 구성하는 호스트로 시작해보자. 호스트에 대한 모든 접근은 보호돼야하고 route 접근, password 접근을 비활성화하고 SSH 키 기반 인증만을 사용해야한다.

  Secure Kubernetes

  초점은 k8s security이다. kube-apiserver는 k8s 모든 작업의 중심에 있다. kubectl을 통해 혹은 API에 직접 접근해 클러스터의 거의 모든 작업을 수행할 수 있다. 그러므로 API 서버에 대한 액세스 컨트롤. 이것이 첫 번째 방어선이다.

두 유형의 결정이 필요하다.

• 누가 클러스터에 접근할 수 있는가?
• 접근한다면 무엇을 할 수 있는가?

  Authentication

  누가 API서버에 접근할 수 있는지는 authentication 매커니즘에 의해 정의된다. static file/ 토큰에 저장된 사용자 ID와 pwd / 인증서 또는 LDAP같은 외부 인증 등 API 서버에 인증할 수 있는 다양한 방법이 잇다.

  Authorization

  클러스터에 대한 접근 권한을 얻고 수행할 수 있는 작업은 authorization 매커니즘에 의해 정의된다. authorization은 사용자가 특정 권한들이 있는 그룹에 연결되는 role-based access control을 이용해 구현된다 (AWS IAM처럼) 또한 attribute-based access control도 있고 Node authorizers, webhooks 등 여러 authorization 모듈이 있다.

  TLS Certificates

  ETCD 클러스터, kube-controller-manager, 스케쥴러, API 서버 등 다양한 컴포넌트와 kubelet & kube-proxy 처럼 워커 노드에서 실행되는 컴포넌트 사이의 모든 통신은 TLS 암호화를 사용해 보호된다. 다양한 컴포넌트 간에 인증서를 설정하는 방법에 대해 살펴볼 시간이 별도로 있다

  Network Policies

  클러스터 내 애플리케이션간 통신은 어떠한가? 기본적으로 모든 파드는 클러스터 내 다른 모든 파드에 접근할 수 있다. 네트워크 정책을 이용하면 그들간의 접근을 제한할 수 있다.

  139: Authentication

  Accounts

  유저는 여러 종류가 있을 수 있다.

• 관리자: 유저 중 관리 작업을 수행하기 위해 클러스터에 접근
• 개발자: 애플리케이션을 테스트하거나 배포하기 위해 클러스터에 접근
• End User: 클러스터에 배포된 애플리케이션에 접근
• 타사 애플리케이션: 통합 목적으로 클러스터에 접근

내부 컴포넌트간 통신을 보호하고 authentication & authorization을 통해 클러스터 관리 지점을 보호하는 법을 다룬다. 엔드 유저는 애플리케이션에서 할 부분이므로 제외하자

• 실제 개발, 관리자들과 다른 서비스들에서 접근한느 경우가 있겠다 k8s는 자체적으로 사용자 계정들을 관리하지 않는다. 사용자 세부 정보가 있는 파일, 인증서, LDAT와 같은 타사 인증 서비스에 의존한다. 그래서 k8s 클러스터에서는 사용자를 생성하거나 목록을 추려볼 수 없다.
• $ k create user admin 과 같은 명령어는 없다. 그러나 서비스 계정의 경우 k8s에서 관리할 수 있다.
• $ k create serviceaccount sa1
• k8s API를 사용해 서비스 계정을 만들고 관리할 수 있다.

kubectl로 접근하는 관리자와 API로 접근하는 개발자 구분없이 모든 사용자 접근은 kube-apiserver에서 관리한다. 서버는 요청을 처리하기 전에 인증을 먼저 검토한다.

Auth Mechanisms

• static password file에 유저 이름 및 passwd 목록 존재하는 경우
• static token file에 사용자 이름 및 토큰 목록이 있는 경우
• Certificates 사용
• 서드파티 인증 사용

  Basic - static passwd

  

• csv 파일에 사용자와 passwd 목록을 생성하고 유저 정보 소스로 이용할 수 있다.
• (암호, 유저명, 유저 id) 튜플 구성 위 옵션을 적용하려면 kube api를 재시작해야함 kubeadm tool을 이용하여 cluster를 설정한 경우 kube-apiserver pod definition 파일을 수정해야한다.
• /etc/kubernetes/manifests/kube-apiserver.yaml 위 파일을 업데이트하면 kubeadm tool이 자동으로 Kube API 서버를 재시작한다.

  Authenticate User

  API서버 접속 인증으로 basic한 static passwd를 이용해 인증하려면 curl에 유저:비밀번호 추가한다

• $ curl -v -k https://master-node-ip:6443/api/v1/pods -u “user1:password123” +추가로 그룹도 가질 수 있다. (passwd, user ,userid, group)

  static token

  user-details.csv에 토큰 열을 추가해서 (token, user ,userid, group) 처럼 가질 수 있고 토큰으로 요청할 수 있다.

• $ curl -v -k https://master-node-ip:6443/api/v1/pods –header “Authorization: Bearer {token}” 그렇지만 위처럼 유저이름, 비밀번호, 토큰을 일반 텍스트로 static 파일에 저장하는 인증 방법은 안전하지 않아 권장되지 않는다.

  140: TLS Introduction & Basics

  TLS로 클러스터를 보호하고 관련 문제를 해결하기 위해 인증서가 안팎으로 작동하는 방식을 배울 것임 TLS 인증서가 무엇인지와 필요한 이유 그리고 SSH 또는 웹 서버 보안을 위해 인증서를 구성하는 방법을 앓아보자.

  Certificate

  인증서는 거래 중 두 당사자간 신뢰 보장용이다. 유저가 웹 서버에 접근하려할 때 TLS 인증서는 유저와 서버간 통신을 암호화하고 서버가 누구인지 확인한다. 이런 보안 연결이 없으면 유저가 온라인뱅킹으로 접근하며 입력한 certificate이 일반 text 형태로 전송된다. 네트워크 트래픽을 스니핑하는 해커는 손쉽게 cert를 검색하고 이를 사용해 유저 은행 계좌를 해킹한다.

  Symmetric Encryption (대칭 암호화)

  암호화 키를 사용하여 전송 데이터를 암호화해야한다. 데이터를 난수와 알파벳 집합인 키를 활용해 암호화하고 서버에 전송한다. 스니핑 해커는 데이터를 얻어도 암호화돼있어 아무 것도 할 수 없다. 물론 서버도 암호화된 데이터로 받는다. 서버가 해독할 수 있도록 키 복사본도 보내야한다. 이 과정에서 다시 스니핑당할 수 있고 결과적으로 또 다시 해킹당할 수 있다.

안전한 암호화 방식이지만 데이터를 암호화하고 복호화하는데 동일한 키 를 이용하고 수신자와 송신자간에 키를 교환해야하므로 해커가 키에 접근할 위험이 있다.

Asymmetric Encryption (비대칭 암호화)

private key, public key 두개를 사용한다. Private 열쇠와 공개된 자물쇠로 이해하면 쉽다. Private key를 항상 안전하게 보관하고 Public key로 여기저기서 암호화한 것을 오로지 private key로만 풀 수 있다.

$ ssh-keygen

• id_rsa(Private key)와 id_rsa.pub(Public key) 두 키를 얻는다 public key로 잠긴 문을 제외하고 서버에대한 모든 접근을 잠가 서버를 보호한다.
• 일반적으로 공개 키가 있는 항목을 서버 SSH authorized_keys 파일에 추가해 보호한다.
• cat ~/.ssh/id_rsa_user1.pub » /home/user1/.ssh/authorized_keys
• SSH를 시도할 때 개인키 위치를 전달한다
• $ ssh -i id_rsa user1@server1 또한 하나의 키 쌍으로 둘 이상의 서버를 보호할 수 있다.
• 공개 자물쇠 복사본(public key 복사본)을 만들어 원하는만큼 사용할 수 있다.
• 동일한 하나의 private key를 이용해 모든 서버에

다른 유저가 서버에 접근하고자 할 때는 어떻게 할까? 신규 유저도 Private key & Public key를 발급해야한다. 이후 서버에 접근할 수 있는 유저가 되도록 서버측의 ~/.ssh/authorized_keys에 추가한다. 그 이후 추가 진입로를 만들고 공개 자물쇠(Public key)로 잠그고 $ cat ~/.ssh/id_rsa_user2.pub » /home/user2/.ssh/authorized_keys

예제로 돌아가서 대칭 암호화에서 겪은 문제는 암호화에 사용된 키가 데이터와 함께 네트워크 통해 서버로 전송되므로 해커에 노출될 위험이 있었다. 하지만 어떻게든 서버의 키를 안전하게 얻을 수 있다면 어떨까? 그렇다면 서로 대칭키로 안전하게 통신할 수 있을 것이다.

클라이언트에서 서버로 대칭 키를 안전하게 전송하기 위해서 비대칭 암호화를 사용해보자.

• 서버에서 공개 키 및 개인 키 쌍을 생성한다.
• 유저가 https를 이용해 웹에 접근하며 서버로부터 공개 키를 가져온다
• 해커 또한 공개키를 가지게 된다
• 유저는 서버로부터 얻은 공개 키로 대칭키를 암호화하여 안전하게 서버로 전송한다.
• 해커 또한 서버의 공개키로 암호화된 대칭키를 가로챈다
• 서버는 본인의 공개키로 암호화된 대칭키를 전달받고 개인 키를 이용해 복호화한다.
• 해커는 서버의 공개키로 암호화된 대칭키를 복호화할 ‘서버의 개인키’가 없다.
• 서버와 유저는 안전하게 대칭키를 이용할 수 있다.
• 비대칭 암호화를 사용해서 대칭키를 사용자에서 서버로 안전히 전송했다.
• 대칭 암호화를 이용해 향후의 모든 통신을 보호했다.

해커가 우리의 자격 증명을 얻을 수 있는 유일한 방법은 해커의 서버 양식에 유저가 직접 입력하는 것이다. 해커는 본인 서버에 은행 웹사이트와 똑같이 생긴 웹사이트를 만들고 본인의 키 쌍(private & public)을 만들고 유저를 기다린다. 유저가 이름과 passwd를 입력하면 브라우저는 해커 서버의 공개키를 수신하고 암호화된 대칭 키를 보낸 뒤 해당 키로 암호화된 자격 증명을 보내고 수신자는 같은 대칭 키로 자격 증명을 해독한다.

서버에서 받은 키를 보고 실제 은행에서 보낸 합법적인 키인지 알 수 있다면? 서버가 키를 보낼 때 키가 포함된 인증서를 보내면 어떨까? 해커의 인증서를 자세히 보면 실제 인증서같지만 디지털 형식임을 알 수 있다.

여기엔 인증서가 발급된 사람(Issuer), 해당 서버의 공개 키, 서버 위치 등에 대한 정보가 있다. 모든 인증서에는 이름이 있고 인증서가 발급된 사람 또는 주체는 신원 확인에 도움이 되는 중요한 필드이다. 웹 서버용인 경우 유저가 브라우저 URL에 입력한 내용과 일치해야 한다 (차후 CA 공개키를 이용해 인증서의 서명을 검증하는데 유효한 경우 인증서의 공개 키를 믿고 사용하게 되는 것이다)

은행이 다른 이름으로 알려져 있고 사용자가 다른 이름으로도 애플리케이션에 액세스하기를 원하는 경우 이 인증서의 이름 섹션의 subject 아래 모든 다른 이름들을 지정해야 놓아야한다. 하지만 누구나 이와 같은 인증서를 생성할 수 있어 자신이 Google이라고 말하면서 직접 생성할 수 있고 해커들은 이렇게 작업한다.

그렇다면 인증서의 어느 부분을 보고 적법힌 것인지 알 수 있을까? 바로 인증서의 발급과 서명 파트에서 알 수 있다. self-signed certificate 즉, 발급자와 서명자가 같은 경우 수상한 인증서이고 신뢰도가 떨어진다. 모든 웹 브라우저는 인증서 유효성을 검사하고 수상하면 경고해준다.

웹 서버가 신뢰하는 인증서는 권한있는 사람 혹은 단체의 서명을 받는 일이다. 이것이 인증기관 Certificate Authority(CA)이다

CA의 검증 3단계

• Certificate Signing Request(CSR)
• Validate Information
• Sign and Send Certificate

해커가 인증을 받으려하면 valid에서 실패할 것이다.

그럼 브라우저는 이 인증서가 위조되지 않은 유효한 CA로부터 받은 것인지 어떻게 알까?

CA 자체에는 일련의 공개 및 개인 키 쌍이 있고 CA는 개인 키를 사용하여 인증서에 서명한다. 모든 CA의 공개 키는 브라우저에 builtin되어 브라우저는 CA의 공개 키를 사용하여 인증서가 실제로 CA 자체에 의해 서명되었는지 확인합니다.

• 디지털서명: CA가 개인키로 일정 부분을 암호화한 서명을 브라우저에 내장된 CA공개키로 검증하는 것
• 암호화: 공개키로 암호화한 것을 개인키로 복호화하는 것

서버가 인증서를 갖게 되는 flow

• 관리자는 한 쌍의 키로 서버에 들어오는 ssh 연결을 보호한다.
• 서버는 인증서 서명 요청(CSR)을 CA에 보내고 CA는 검증 뒤 개인 키로 서명한다.
• 모든 사용자(브라우저)는 CA의 공개키를 갖고있다
• 서명된 인증서가 다시 서버로 전송된다.
• 서버는 서명된 인증서로 애플리케이션을 운영한다.

서버와 유저의 통신 flow

• 유저가 애플리케이션에 접근할때마다 서버는 공개키와 함께 인증서를 보낸다
• 유저의 브라우저는 인증서를 읽고 브라우저 내재된 CA의 공개 키를 사용해 인증서의 서명을 검증하고 유효하면 인증서의 서버 공개 키를 신뢰한다.
• 이후 앞으로 모든 통신에 사용할 대칭 키를 생성한다.
• 서버의 공개 키를 사용해 대칭 키를 암호화하고 다시 서버로 전송된다.
• 서버는 개인키로 복호화하여 대칭키를 찾아내고 이를 통해 통신한다.

서버는 https로 웹 사이트를 보호하기 위해 pulbic private key pair를 생성한다. 인증 기관 CA는 인증서에 서명하기 위한 한 쌍의 고유한 key pair를 생성한다. 최종 사용자는 통신을 위한 대칭키만을 생성한다.

Public Key Infrastructure

CA, 서버, 유저 그리고 디지털 인증서 생성, 배포, 유지 및 관리 프로세스를 포함한 이 전체 인프라를 공개 키 인프라 또는 PKI라고 한다.

+개인키와 공개키를 열쇠와 자물쇠로 비유했으나 공개 키로만 암호화할 수 있는게 아니다. 둘 중 하나로 암호화하면 나머지로 복호화할 수 있다.

하지만 이름짓는 컨벤션이 있다.

key라는 단어가 포함되지 않았으면 일반적으로 공개 키이거나 인증서이다.