[CKA] Security - 1

CKA (https://www.credly.com/org/the-linux-foundation/badge/cka-certified-kubernetes-administrator)

Security

강의 개요

• 쿠버네티스 보안의 초기 단계
• 쿠버네티스 접근 가능 이유, 접근 통제 방법
• 다양한 인증 메커니즘
• 보안 관련 또는 인증서 관련 이슈 핸들

---

Security Primitives

• 쿠버네티스 호스트부터 시작해보자. 호스트에 대한 모든 액세스는 보안 처리가 되어야한다.
• Root 액세스 해제, 암호 기반 인증 해제, Only SSH 키 기반 인증만 사용 가능해야한다.
• 클러스터 보안을 위해 어떤 위험과 조치를 취해야 할까?
• 쿠버네티스의 중심에는 kube-apiserver가 있다.
• kubectl 이나 API에 직접 액세스 함으로써 상호작용 하게된다. API를 통하게 되면 클러스터에서 거의 모든 작업을 수행할 수 있다. API 서버 자체에 대한 액세스를 제어하는 게 1차 방어선이다.
• 두가지 결정을 내려야한다.
  • 누가 클러스터에 접근하는지?
  • 뭘할 수 있는지?
• 누가 API 서버에 액세스할 수 있는지는 인증(Authetication) 메커니즘에 의해 정의된다.
  • 유저 네임과 비밀번호를 이용
  • 유저 네임과 토큰을 사용
  • 인증서를 사용
  • 외부 인증 공급자를 사용(LDAP와 같은)
  • Service Accounts를 사용
• 누군가 인증이 완료되었다면 다음은 인가(Authorization) 메커니즘에 의해 뭘할 수 있는지가 정의된다.
  • RBAC(Role Based Access Control) Authorization
  • ABAC(Attribute Based Access Control) Authorization
  • Node Authorization
  • Webhook Mode
• ETCD 클러스터, Controller Manager, Scheduler, API server, kubelet, kube-proxy 같은 클러스터와의 모든 통신 구성 요소 간에는 TLS 암호화로 보안된다. 구성요소 사이에 인증서를 설정하고 의논한다.
• 클러스터 내의 응용 프로그램 간 통신은 어떻게 하는가? 기본 설정상 모든 파드는 무리 내의 다른 파드에 접근할 수 있다. 네트워크 정책을 이용해 그들 사이의 액세스 권한을 제한할 수 있다.

---

Authentication

• 인증 매커니즘을 통해 쿠버네티스 클러스터에 액세스 권한을 확보하는 데 초점을 맞춰보자.
• 클러스터에 액세스 할 수 있는 다양한 사용자가 있다.
• 클러스터에 배포된 응용 프로그램에 액세스하는 엔드 유저의 보안은 응용 프로그램 자체에 의해 내부적으로 관리된다.
• 우리는 관리 목적으로 사용자가 쿠버네티스 클러스터에 액세스하는 것만 알면 된다.

• 클러스터에 접근하는 사용자는 관리자, 개발자, 클러스터 액세스를 요구하는 다른 프로세스나 서비스 / 응용 프로그램인 Bots 로 분류된다.
• 쿠버네티스는 사용자 계정을 직접 관리하지 않는다.
• 사용자 세부 정보나 인증서가 있는 파일이나 LDAP 같은 타사 ID 서비스가 있는 사용자들을 외부 서비스로 관리한다.
• 쿠버네티스 클러스터에서 사용자를 생성하거나 사용자 리스트를 볼 수 없다.
• Service Account의 경우 쿠버네티스가 관리할 수 있다. 쿠버네티스 API를 이용해 Service Account를 생성하고 관리할 수 있다.
• Service Account에 대한 독립적인 섹션도 있어서 서비스 계정에 대해 관리할 수 있다.

• kubectl 툴이나 API를 통해 직접 클러스터에 액세스 하던지 아니던지 모든 사용자 액세스는 API 서버에 의해 관리된다.
• 이 모든 요청은 kube-apiserver로 가게되고, 요청을 처리하기 전에 인증을 하게된다.
• 그리고 이 인증을 하기 위한 다양한 인증 메커니즘이 있다.
  • Static Password File : 사용자 이름과 암호 리스트가 적힌 파일
  • Static Token File : 사용자 이름과 토큰이 적힌 파일
  • Certificates : 인증서
  • Identity Serviced : LDAP이나 Kerberos와 같은 타사 인증 프로토콜
• Staitc Password File은 CSV 파일에 사용자 목록과 암호를 만들 수 있다. 그리고 그걸 사용자 정보의 소스로 사용한다. 파일은 암호, 사용자 이름, ID로 세 개의 열로 구성돼 있다.
• 그리고 파일 안에 있는 정보들을 kube-apiserver에게 옵션으로 전달해준다.

• 명령어로 직접 kube-apiserver를 구성했다면 위와 같이 --basic-auth-file 옵션을 설정해주면 된다.

• kubeadm 을 이용해서 클러스터를 구성했다면 /etc/kubernetes/manifests/kube-apiserver.yaml 파일 내부에 있는 command 라인에 --basic-auth-file 옵션을 설정해주면 된다.

• 사용자 및 암호를 지정해 기본 자격 증명을 이용해 API 서버에 액세스할 수 있다. 

• 또한 CSV 파일에 유저 뿐만 아니라 group을 지정할 수도 있다. CSV 파일 유저 열 오른쪽에 그룹 정보가 있어 특정 그룹에 유저를 할당할 수 있다.
• 정적 암호 파일 대신에 정적 토큰 파일도 가질 수 있다. 토큰 파일은 정적 암호 파일과 비슷하게 --token-auth-file이라는 옵션을 지정해 kube apiserver에 넘겨주면 된다.
• API에 직접 요청을 할 경우 헤더 옵션을 이용해 토큰 정보를 담아준다. "Authorizaion: Bearer <token contents>" 꼭 이렇게 구성해야 한다.

Notes

• 고정 파일에 사용자 이름, 암호, 토큰을 명확한 테스트에 저장하는 메커니즘은 불안정 하기에 권장하지 않는다.
• kubeadm에서 설정을 했다면 인증 파일을 얻기 위해 볼륨 마운트도 고려해야 한다.

---

TLS Basics (추가 내용이라 스킵 가능)

• 인증서는 transaction 중에 두 당사자 사이의 신뢰를 보장하기 위해 사용된다.
• 가령, 사용자가 웹 서버에 액세스하려 할 때 TLS 인증서는 사용자와 서버 사이의 통신이 암호화되도록 한다.

• 일반적으로 Secure 한 연결이 없다면 사용자가 온라인 뱅킹 앱에 접속할 경우 입력한 자격 증명이 일반 텍스트 형식으로 전송되게 된다.
• 만약 악의적으로 네트워크 트래픽을 탐지하게 되면 자격 증명을 쉽게 추출해 사용자의 은행 계좌를 해킹할 수 있다.
• 그래서 기본적으로 난수의 숫자와 알파벳으로 설정된 집합으로 구성된 키로 데이터를 암호화하게 된다. 

• 만약 해커가 데이터를 얻게 되어도 랜덤한 숫자와 알파벳으로 구성된 내용만 얻게 되니 해커 입장에서는 아무것도 할 수 있는게 없을 것이다.
• 그러나 데이터를 받게 되는 서버도 마찬가지다. 키 없이는 데이터를 해독할 수 없으니 키의 복사본을 서버로 보내서 서버가 메시지를 해독하고 읽을 수 있게 해야한다.
• 그러나 키도 안전하지 않은 네트워크로 전송되니까 해커도 이를 탈취하면 메시지를 해독하고 읽을 수 있을 것이다.
• 이러한 방식을 대칭키 암호화(Symmetric Encryption)라고 한다.
• 키가 탈취 당하면 데이터를 해독 당할 위험이 있기 때문에 나온 것이 비대칭키 암호화(Asymmetric Encryption)다.
• 단일 키를 사용하는 대신에 Private key 와 Public key로 나누어 두 개의 키를 사용하는 방법이다.
• Public key는 공용 자물쇠라고 생각해도 된다. 그리고 Private key는 나만 갖고 있는 비공개 열쇠이다.
• 만약에 공용 자물쇠로 데이터를 암호화하게 되면 관련 키로만 열 수 있다. 열쇠는 항상 안전하게 가지고 있어야 하고 다른 사람과 공유해서는 안된다. 
• 자물쇠는 공개되어 있고 그걸로만 무언가를 잠글 수 있다. 그리고 개인 열쇠로만 열 수 있다.
• 예를 들어 SSH 액세스를 키 페어를 이용해 보안 강화하는 사용 사례를 알아보자.

---

SSH 액세스 키 페어 이용 사례

• 접근이 필요한 서버가 있을 때 암호로만 서버에 접근이 가능하게 되면 위험해서 사용할 수 없다.
• 그래서 공개와 비공개 키 페어를 이용하기로 한다.

]$ ssh-keygen
id_rsa id_rsa.pub

• id_rsa는 사설 키이고, id_rsa.pub은 공개 키이다.
• 서버에서 공개키 내용을 ssh 설정 파일에 넣어주면 ssh로 해당 서버에 접근이 가능하다. (비공개 키가 있는 경우)

]$ cat ~/.ssh/authorized_keys
sh-rsa ASsmY095ywPsBo1XQ9PqhnN1..생략..8GvaQ== user1

• 내 서버에서는 ssh 명령어를 입력해서 접근하게 된다.

]$ ssh -i id_rsa user1@server1
Successfully Logged In!

• 만약 서버가 여러 개면 어떻게 되는가?
• 퍼블릭 키를 여러 서버에 위치하게 해서 ssh에 대한 동일한 프라이빗 키를 모든 서버에 안전하게 사용할 수 있다.
• 만약 다른 사용자도 해당 서버에 접근하고 싶다고 한다면?

• 키 페어를 하나 더 발급 받아 user2에 대한 공개 키를 각 서버에 등록 해주면 된다.

---

• 다시 웹 서버에서 사용 사례로 넘어가보자.

• 위와 같이 openssl 명령어를 이용해서 

 

(이어서 작성...)

---

TLS in Kubernetes

• kubernetes 클러스터를 TLS 인증서로 보호하는 방법에 대해 살펴보겠다.
• 서버가 공개 및 개인 키를 사용해 연결할 때 해당 키를 "서버 인증서" 라고 부를 것이다.
• 또한 CA는 서버 인증서를 서명하는 데 사용하는 자체의 공개 및 개인 키 집합이 있는데 이를 "루트 인증서"라고 부를 것이다.
• 그리고 서버가 클라이언트에게 클라이언트 인증서를 사용 해 자신을 확인 하도록 요청하는 "클라이언트 인증서"가 있다.
• 네이밍 컨벤션은 아래와 같다.

• 보통 Public Key 는 crt 또는 pem가 확장자이고,  Private Key의 경우 key 또는 key.pem 이 확장자이다.
• 쿠버네티스 클러스터에서는 이러한 개념이 어떻게 사용될까?
• 쿠버네티스 클러스터는 마스터 노드 및 워커 노드로 구성된다.
• 마스터 노드와 워커 노드가 통신하는 과정에서 모든 통신은 안전하고 암호화 되어야 한다.
• 또한 모든 서비스 및 그들의 클라이언트 간의 모든 상호 작용이 안전해야 한다.
• 예를 들어 kubectl 명령어를 이용해 kubernetes 와 상호 작용하거나 kube-apiserver에 직접 액세스하는 경우 안전한 TLS 통신을 해야한다.
• kubernetes 클러스터 내의 모든 구성 요소 간의 통신도 안전하고 보호되어야 한다.
• 위 두 가지 요구 사항은 클러스터 내의 모든 다양한 서비스가 서버 인증서를 사용하고 모든 클라이언트가 클라이언트 인증서를 사용해야 한다는 것이다.

• 쿠버네티스 전체로 보았을 때 필요한 인증서는 다음과 같다.
• 모든 구성 요소 간의 통신을 보호하기 위해서 모든 구성 요소에는 인증서 및 키 페어를 생성해야 한다.
• 먼저 kube-apiserver이다.
• kube-apiserver는 kubernetes 클러스터를 관리하기 위해서 다른 구성 요소 및 외부 사용자가 사용하는 HTTPS 서비스를 노출한다. 따라서 모든 클라이언트와의 통신을 보호하기 위해서 인증서 및 키 페어를 생성해야 한다.
• 또한 etcd 서버는 클러스터에 대한 모든 정보를 저장한다. 따라서 자체적으로 인증서 및 키 쌍이 필요하다.
• 또한 kubelet은 kube-apiserver와 상호 작용하기 위해 HTTPS API 엔드포인트를 노출한다. 여기에도 인증서 및 키 쌍이 필요하다.
• kube-apiserver, etcd, kubelet은 kubernetes 클러스터의 서버 구성 요소이다.
• 아래는 클러스터의 클라이언트 구성 요소이다.
• 서비스에 액세스하는 클라이언트는 누구일까?
• kube-apiserver에 액세스하는 클라이언트는 kubectl 및 API 직접 접속이다. 관리자는 kube-apiserver에 인증하기 위해서 인증서 및 키 페어가 필요하다.
• 스케줄러는 스케줄링이 필요한 파드를 찾고 이 파드를 올바른 워커 노드에 스케줄링 하도록 kube-apiserver와 통신한다. 스케줄러는 kube-apiserver에 액세스하는 클라이언트이다. 그러므로 인증서 및 키 페어가 필요하다.
• kube-controllermanager도 kube-apiserver에 액세스하는 클라이언트이다. 마찬가지로 인증서 및 키 페어가 필요하다.
• kube-proxy는 kube-apiserver에 인증하기위해 클라이언트 인증서가 필요하다. 인증서 및 키 페어가 필요하다.

• 또한 서버들도 상호 작용을 한다. 예를 들어 kube-apiserver는 etcd 서버와 통신한다.
• etcd 서버는 kube-apiserver가 클라이언트이므로 인증이 필요하다. kube-apiserver는 자체 API 서비스에 사용한 인증서를 사용할 수 있다. apiserver.crt 및 apiserver.key 파일
• 또는 etcd 서버에 대한 인증을 위해 새로운 인증서 및 키 페어를 생성할 수도 있다.
• kube-apiserver는 각 개별 노드의 kubelet 서버와도 통신한다.

---

TLS in Kubernetes - Certificate Creation

• 인증서를 생성하는 방법을 살펴보자
• 인증서를 생성하기 위해서는 Easy RSA, OpenSSL, CFSSL 등 다양한 도구를 이용할 수 있다.
• 먼저 CA 인증서를 생성해보자 openssl 명령어를 이용해보겠다.

]$ openssl genrsa -out ca.key
ca.key

• 생성된 ca.key와 함께 CSR을 생성한다. CSR은 모든 세부 정보가 포함된 인증서와 유사하지만 서명이 없다.

]$ openssl req -new -key ca.key -subj "/CN=KUBERNETES-CA" -out ca.csr
ca.csr

• CSR에는 인증서가 어떤 구성 요소를 위한 것인지를 CN (Common Name) 필드에 지정한다. 쿠버네티스 CA 인증서를 만드는 중이니까 KUBERNETES-CA 라고 이름을 붙인다.

]$ openssl x509 -req -in ca.csr -signkey ca.key -out ca.crt
ca.crt

• 이전에는 인증서에 서명이 되어 있지 않았으므로, 인증서 서명 요청으로 인증서를 서명한다.
• CA는 이제 자체의 개인 키와 루트 인증서 파일을 갖추게 되었다.

 

• 이제 클라이언트 인증서 생성을 보도록 하자
• Admin user (쿠버네티스 클러스터를 관리하는)에 대한 인증서를 먼저 생성해본다.

]$ openssl genrsa -out admin.key 2048
admin.key

• 그 다음 CSR을 생성해 admin user의 이름을 지정한다. 이것이 kubectl 클라이언트 인증을 위한 것임을 상기하고 이름을 지정하면 된다. CN=kube-admin으로 지정해주었다.

]$ opensssl req -new -key admin.key -subj "/CN=kube-admin" -out admin.csr
admin.csr

• 그리고나서 openssl x509 명령어를 이용해서 서명된 인증서를 생성해준다.

]$ openssl x509 -req -in admin.csr -CA ca.crt -CAkey ca.key -out admin.crt
admin.crt

• 이제 인증서에 서명이 되고 클러스터 내에서 유효한 인증서가 되었다.
• 관리자가 쿠버네티스 클러스터에 이 인증서를 사용해서 인증하게 된다.

• 이 과정 전체는 새 사용자를 위한 사용자 계정을 생성하는 것과 유사하다. 인증서는 검증된 사용자 ID이고 키는 비밀번호와 유사하다. 그저 간단한 사용자 이름과 비밀번호보다 훨씬 더 안전하다.
• 그래서 이 인증서와 key는 Admin user를 위한 것이다.
• 다른 사용자와 이 사용자를 구분하려면 어떻게 해야 하는가?
• 사용자 계정에 대한 그룹 세부 정보를 인증서에 추가함으로써 해당 계정을 관리자로 식별해야한다.

• 쿠버네티스에는 관리 권한을 가진 system:masters라는 그룹이 있다.

• CSR을 요청할 때 O 매개 변수에 그룹 세부 사항을 추가하면서 CSR을 생성할 수 있다.
• 서명된 후에는 admin 권한이 있는 admin 사용자를 위한 인증서가 생성이 된다.
• 또한 kube-apiserver에 액세스하는 모든 구성 요소에 대해 클라이언트 인증서를 생성하는 데 동일한 프로세스를 따른다.
• 먼저 kube-scheduler이다. kube-scheduler는 kuberneres control panel의 일부인 시스템 구성요소이므로 이름은 반드시 system: 키워드로 접두사를 붙여야한다. kube-controllermanager도 동일하다.
• 시스템 구성요소는 반드시 키워드 system으로 접두사를 붙여야한다.

 

• 이런 컴포넌트에 대한 인증서를 모두 생성한 뒤 어떻게 사용하면 될까? 이 인증서를 사용해 kube-apiserver에 대한 REST API 호출에서 사용자 이름과 암호 대신에 이 인증서를 지정할 수 있다.

• 인증서를 쉽게 사용하는 방법은 모든 매개 변수들을 kube-config.yaml이라는 Config 파일로 옮기는 것이다.
• 대부분의 kubernetes 클라이언트는 config 파일 내에서 API 서버 엔드포인트, 사용할 인증서 등을 지정한다.
• 서버가 인증서를 보내고 클라이언트가 서버의 인증서를 검증하고 반대로 클라이언트가 서버에게 자신의 인증서를 보내고 서버가 이를 검증하려면 모든 사용자가 CA의 공개 인증서의 사본이 필요하다.
• 이것은 웹 애플리케이션의 경우 이미 사용자의 브라우저에 설치된 것과 유사하다.
• Kubernetes에서는 이러한 다양한 구성 요소가 서로를 확인하기 위해 CA의 루트 인증서의 사본이 필요하다
• 서버 또는 클라이언트를 인증서로 구성할 때마다 CA 루트 인증서를 지정해야한다.

• 위 그림과 같이 모든 구성요소가 CA의 공개 인증서를 가지고 있는 것을 알수 있다. (초록색 인증서)

 

• 이제 서버 쪽 인증서를 보도록하자
• 먼저 etcd 서버이다. 절차는 이전과 동일하다.

• ETCD 서버는 고가용성 환경과 같이 여러 서버에 걸쳐 클러스터로 배포될 수 있다. 이 경우 클러스터의 다른 멤버 간의 통신을 보안하려면 추가적인 피어 인증서를 생성해야한다. (etcdpeer1.crt 등)

• etcd 서버를 시작할 때 이를 지정하는 옵션이 있다.
• 예를 들어 key-file, cert-file은 etcd 서버 키를 지정할 수 있고, etcdpeer1.crt 와 같은 파일은 --peer-cert-file 과 같은 옵션을 이용해준다.
• 그리고 etcd 서버에 연결하는 클라이언트가 유효한지 확인하려면 ca root 인증서가 필요하다. trusted-ca-file 옵션에는 ca root 인증서를 입력해준다.

 

• 이제 kube-apiserver에 대해 이야기 해보겠다.

• kube-apiserver는 모든 구성 요소가 kube-apiserver에 연결되며, 모든 작업이 kube-apiserver를 통과한다.
• 클러스터 내에서 무언가가 이동하면 api server는 해당 사실을 알고 있다.
• kube-apiserver는 다양한 이름으로 불리게 된다. 도메인 네임을 말하는 것이다. 실제로 범위에 따라서 다르게 불리기 때문에 여러 도메인 네임을 갖고 있는 것이 좋을 것이다.
• 어떤 곳에서는 간단히 IP 주소로만 언급하기도 한다. kube-apiserver를 싱행하는 호스트 또는 해당 Pod의 IP 주소이다.
• 그래서 이러한 모든 이름은 kube-apiserver를 위해 생성된 인증서에 포함되어야한다.
• 그렇지 않으면 이러한 이름으로 kube-apiserver를 참조하는 사람들은 유효한 연결을 설정할 수 없다.
• 대체이름을 모두 지정하기 위해서는 openssl config 파일을 만들어야한다. 파일을 생성하고 파일의 alt_names 섹션에 대체 이름을 지정해준다.

• 그 다음 만들어진 csr 파일을 이용해 인증서에 서명해주면 된다.

• kube-apiserver를  실행할 때 api 클라이언트 인증서의 위치는 kube-apiserver의 실행 파일이나 서비스 구성 파일에 전달된다.
• 먼저 ca 파일을 전달해야한다. --client-ca-file 옵션을 이용해 ca 파일을 지정해준다.
• 각 구성 요소가 자신의 클라이언트를 확인하기 위해 ca 인증서가 필요하다.
• 그런 다음 --tls-cert-file 옵션에 apiserver.crt api 서버 인증서를 제공한다. 
• 그 다음 etcd 서버에 연결하는데 사용하는 인증서를 입력해준다.
• 또한 kubelet에 연결하는 인증서를 연결해준다.

 

• kubelet 서버는 각 노드에서 실행되는 api 서버로서 노드를 관리하는 역할을 한다.
• 그래서 각 노드에 대한 키-인증서 페어가 필요하다.

• 인증서의 이름은 node01, node02와 같이 노드의 이름을 따라야한다. 인증서가 생성되면 kubelet-config.yaml 파일에서 사용한다.
• 항상 루트 CA 인증서를 지정하고 kubelet의 인증서를 제공한다. 

• 노드는 시스템 구성요소로 API 서버는 어떤 노드가 인증을 하는 지 알아야 하고 올바른 사용 권한 세트를 줘야한다.
• 따라서 노드가 올바른 형식에 올바른 이름을 갖추도록 해야한다.
• 이전에 설정 했듯이 마찬가지로 system:node:node01 과 같은 형식으로 system:node:라는 접두사를 이용해야한다.
• 물론 Group도 마찬가지로 설정해줘야한다.

---

View Certificate Details

• 이번에는 기존 클러스터에서 인증서를 확인하는 방법을 살펴보자
• 먼저 클러스터가 어떻게 설정되었는지 알아내는 것이 중요하다.
• kubernetes 클러스터를 배포하는 다양한 솔루션이 있으며 인증서를 생성하고 관리하는 다양한 방법을 사용한다.
• 새로운 kubernetes 클러스터를 처음부터 배포하는 경우 이전 강의에서 수행한 것처럼 모든 인증서를 직접 생성한다.
• 그렇지않으면 kubeadm과 같은 자동 프로비저닝 도구를 사용하는 경우 클러스터를 자동으로 생성 및 구성하도록 도우며, 모든 구성 요소를 노드의 기본 서비스로 배치한다.
• kubeadm으로 브로비저닝 된 클러스터를 살펴보도록 하자.

• /etc/kubernetes/manifests/kube-apiserver.yaml
• kubeadm이 셋업한 환경에서는 kube-apiserver.yaml 파일에 인증서에 대한 모든 정보를 갖고있다.
• 인증서 파일을 식별하고 기록한 뒤 인증서를 가져와 해당 인증서에 대한 자세한 정보를 찾으면 될 것이다.
• 먼저 apiserver.crt 파일로 시작해보자

]$ openssl x509 -in /etc/kubernetes/pki/apiserver.crt -text -noout

• openssl x509 명령어를 실행한 뒤 -in 옵션으로 파일을 입력으로 제공해 인증서를 디코딩하고 세부 사항을 본다.
• Subject 섹션에서 인증서의 이름을 확인할 수 있다.
• 그런 다음 맨 아래 Subject Alternative Name 섹션에서 kube-apiserver가 가지고 있는 대체 이름을 확인할 수 있다. 모든 대체 이름이 있는 지 확인 해보자
• 그 다음 인증서의 Validity 섹션을 확인해 만료 날짜를 식별하고 Issuer 섹션을 확인해 인증서의 발행자를 확인한다.
• Issuer 섹션은 인증서를 발행한 CA여야한다.
• kubeadm은 CN-kubernetes를 인증서를 발행한 CA로 명명한다.
• 다른 인증서에 대한 정보를 식별한느 데에도 동일한 절차로 확인하면 된다.
• 확인해야 할 사항
  • 올바른 이름으로 구성되었는지
  • 올바른 대체 이름으로 구성되었는지
  • 인증서가 올바른 조직에 속해 있는지
  • 올바른 발행자에 의해 발행 되었는지
  • 인증서가 만료되지 않았는지
• 만약 문제가 발생할 시 로그를 확인해야 한다. 
• 서비스가 OS에서 native services로 구성된 경우 운영 체제 로깅 기능을 사용해 서비스 로그를 확인해야 한다.

]$ journalctl -u etcd.service -l

• kubeadm으로 클러스터를 설정한 경우 각 구성 요소는 pod로 배치된다. 따라서 kubectl logs 명령어를 사용해 로그를 확인할 수 있다.

]$ kubectl logs <pod name>

• 때로 kube-apiserver나 etcd 서버와 같은 핵심 구성 요소가 다운되어 kubectl 명령어가 작동하지 않는 경우가 있다. 이 같은 경우 docker 단으로 내려가서 로그를 가져와야 한다.
• docker ps -a 명령을 사용해 모든 컨테이너를 나열하고 docker logs <container id> 명령을 사용해 로그를 확인한다.

---

Certificates API

• 어떻게 인증서를 관리하며 kubernetes 의 인증서 API가 무엇인지 살펴보자
• 지금까지의 설정으로 나는 클러스터의 유일한 관리자 및 사용자이며 나만의 관리자 인증서와 키가 있다.
• 새로운 관리자 B가 팀에 들어왔다고 가정해보자. B는 클러스터에 액세스 해야하고, 자신의 개인 키를 만들고 CSR을 생성해 내게 전송한다.
• 나는 유일한 관리자로서 CSR을 CA 서버로 가져가 CA 서버의 개인키와 루트 인증서를 사용해 서명하고 인증서를 생성한 다음 B에게 전송해야한다.
• B는 이제 클러스터에 액세스할 수 있는 자체 인증서 및 키 페어를 갖게 된다. 인증서에는 유효 기간이 있고 일정 시간이 지난 뒤 만료된다. 만료된 이후에는 CSR을 다시 생성하고 CA에 의해 서명 되어야 다시 사용 가능하다. 결국 인증서 파일을 교체해야한다는 이야기이다.
• CA 서버는 kubernetes 설정에서 어디에 위치해 있을까?
• CA는 실제로 생성한 키 및 인증서 파일의 페어이다. 이 페어의 파일에 액세스 권한이 있는 누구나 kubernetes 환경을 위해 어떤 인증서든 서명할 수 있다.
• 그래서 원하는만큼 많은 사용자를 만들고 원하는 권한을 할당할 수 있다.
• 그래서 파일을 안전한 환경에 저장해야한다. 파일을 완전히 안전한 서버에 배치하면 해당 서버가 CA 서버가 된다.
• 지금까지 우리는 인증서를 kubernetes 마스터 노드 자체에 위치시켰으므로 마스터 노드도 우리의 CA 서버이다.
• kubeadm 도구도 CA 파일의 페어를 생성하고 이를 마스터 노드에 저장한다.
• 지금까지는 수동으로 CSR에 서명했지만 사용자가 증가하고 팀이 성장함에 따라 인증서, 서명 요청을 효과적으로 관리하고 만료되면 인증서를 교체할 수 있는 더 나은 자동화된 방법이 필요하다.
• kubernetes에는 이를 수행할 수 있는 내장된 인증서 API 가 있다.
• Certificates API를 사용하면 이제 API 호출을 통해 직접 kubernetes에 인증서 서명 요청을 보낸다.
• 관리자가 인증서 서명 요청을 받으면 직접 서버에서 서명하는 대신 인증서 서명 요청을 나타내는 kubernetes API 객체를 만든다. 객체가 생성되면 모든 인증서 서명 요청은 클러스터의 관리자에 의해 볼 수 있다.
• 관리자는 요청을 검토하고 kubectl 명령을 사용해 쉽게 승인할 수 있다.
• 이 작업에 대해 과정을 설명하자면
  1. 사용자는 먼저 키를 만든다.
  2. 키에 자신의 이름이 포함된 인증서 서명 요청을 생성한다.
  3. 그 다음 요청을 관리자에게 보낸다.
  4. 관리자는 키를 가져와 인증서 서명 요청 객체를 생성한다.

• 인증서 서명 요청 객체는 다른 kubernetes 객체와 마찬가지로 일반적인 필드를 사용하여 manifest 파일을 사용하여 생성된다. kind: certificate signing request
• spec 섹션에서 사용자가 속해야하는 그룹을 지정하고 계정의 사용 목록을 문자열 목록으로 나열한다.
• request 필드는 사용자가 보낸 인증서 서명 요청을 지정하는 위치인데 base64로 인코딩 해야한다.
• 객체가 생성되면 모든 인증서 서명 요청은 kubectl get csr 명령어로 관리자가 확인 가능한다.

• 그리고 관리자는 kubectl certificate approve 명령어로 요청을 승인할 수 있다.

• 이 인증서는 get csr 명령어를 이용해서 쉽게 확인 가능하고 base64로 디코딩하게 되면 사용자가 요청한 CSR의 원문이 보이게 된다.
• 이 모든 작업을 수행하는 주체는 누구인가? 바로 kube-controllermanager이다.
• 컨트롤러 매니저를 자세히 보면 CSR 승인, CSR 서명 등이라고 불리는 특정 작업을 담당하는 컨트롤러가 있다.

• 누군가 인증서에 서명해야 한다면 CA 서버의 루트 인증서 및 개인 키가 필요하다.