참고
TLS in Kubernetes
NOTE
쿠버네티스에서 TLS를 어떻게 사용하고 있는가? (크게 서버와 클라이언트로 나뉜다)
Server Certification for servers ⇒ K8s내 다른 컴포넌트끼리 통신하는 방법
•
API Server
◦
https service를 노출하므로, 클라이언트들과 모든 통신을 암호화하기 위해 필요
•
etcd
◦
정보를 저장하기 때문에 필요
•
kubelet
◦
worker 노드를 관리하기 때문에 필요
Clients Ceritification for clients ⇒ service/k8s에 접근하는 사람(admin, 스케쥴러)
•
Admin(사용자)
◦
서버를 인증하기 위해서 필요로 한다.
•
schduler
◦
kube-api-server 입장에서는 clinet로서, client certification을 이용해서 id를 증명해야함
◦
kube-conroller-manager, kube-proxy도 동일
인증서는 어떻게 만드는가?
NOTE
인증서는 기본적으로 CA(인증기관)이 필요하며 인증서와 키가 필요하다. 우리는 Openssl을 사용해서 만들어본다.
# 개인키 생성
openssl | genrsa -out ca.key 2048
# 인증서 서명요청 (CSR) 생성
openssl | req -new -key ca.key -subj "/CN=KUBERNETES-CA" -out ca.csr
# x509를 커맨드로 CSR에 서명추가
openssl | x509 -req -in ca.csr -signkey ca.key -out ca.crt
Bash
복사
CA 인증서를 만드는 방법.
# 개인키 생성
openssl genrsa -out admin.key 2048
# 인증서 서명요청 생성 (유저 구분을위해 OU=system:masters 추가)
openssl req -new -key admin.key -subj \
"/CN=kube-admin/OU=system:masters" -out admin.csr
# ca.crt가 추가된다.
openssl x509 -req -in admin.csr –CA ca.crt -CAkey ca.key -out admin.crt
Bash
복사
Client(유저) 인증서를 만드는 방법
•
X.509는 PKI 기술 중에서 가장 널리 알려진 표준 포맷
•
서버측 인증서는 클라이언트와 다르게 여러 특이점이 존재한다.
◦
etcd ⇒ 멤버(etcd는 여러 노드로 구성됨)간 통신을 보호하기 위해 peer 인증서를 사용한다.
◦
kublet ⇒ 각 워커노드의 kubelet에 대한 별도의 인증서가 생성된다.
curl https://kube-apiserver:6443/api/v1/pods \
--key admin.key --cert admin.crt
--cacert ca.crt
Bash
복사
apiVersion: v1
kind: Config
clusters:
- cluster:
certificate-authority: ca.crt
server: https://kube-apiserver:6443
name: kubernetes
users:
- name: kubernetes-admin
user:
client-certificate: admin.crt
client-key: admin.key
YAML
복사
클러스터 생성
•
위에서 생성한 인증서들로 무엇을 할 수 있는가?
◦
admin인증서로는 curl명령어로 username/password 대신 인증서를 사용할 수 있다.
◦
다른 방법으로는, kube-config에 작성해놓는다.
인증서를 어떻게 조회하는가?
NOTE
인증서에 문제가 있을 때(health check) 뭘 확인해야할까?
Hardway ⇒ 스스로 커맨드를 통해 config 및 certification을 작성해서 뛰운다.
tool ⇒ kubedam을 통해 클러스터 자동생성
/etc/kubernetes/pki 인증서 모음 (파일이름 확인하는걸 잘해보자)
# openssl x509 -in [인증서 파일 경로] [옵션]
# X.509 인증서를 읽기위해 사용하는 명령어
openssl x509 -in /etc/kubernetes/pki/apiserver.crt -text
crictl ps -a
crictl logs [컨테이너 ID]
Bash
복사
•
kubedam으로 쿠버네티스를 설치했다면 대부분의 인증서는 /etc/kubernetes/pki에 저장된다.
Certificates API
NOTE
부서에 새로운 직원이 올때, 그 사람은 클러스터에 어떻게 접근해야 하는가?
.png&blockId=0379405d-1db0-4972-bf42-bfd7140f2f42)
관리자는 유일하므로, 신규직원은 관리자에게 인증서를 발급받는다. (유효기간이 존재함)
•
CA서버는 인증서 키 파일을 저장하는 곳이며, 마스터 노드가 대표적이다.
◦
그런데 관리하는 인증서가 많아진다면 매번 많은 작업이 요구된다.
◦
그래서 K8s는 자체적인 Certificated API를 제공한다
•
관리자가 master node(CA 서버)에 요청하는 대신, CSR이라는 K8s API Object를 생성한다.
•
Object가 생성되면, 모든 CSR은 cluster의 admin에 보이게된다.
◦
그러면 CSR은 k8s cmd를 통해 평가되고, 승인된다.
◦
인증서는 유저와 공유된다.
apiVersion: certificates.k8s.io/v1
kind: CertificateSigningRequest
metadata:
name: akshay
spec:
groups:
- system:authenticated
request: <Paste the base64 encoded value of the CSR file>
signerName: kubernetes.io/kube-apiserver-client
usages:
- client auth
YAML
복사
akshay 이름의 증명서
# csr 오브젝트 확인
kubectl get csr
# 승인과 거부
kubectl certificate approve akshay
kubectl certificate deny agent-smith
Bash
복사
•
과정을 정리하면
1.
새로운 유저가 키를 생성한다.
2.
csr을 새로운 유저의 키를 이용해서 생성한다.
3.
CSR을 관리자에게 보낸다,
4.
관리자는 CSR Object를 만든다. (key는 base64명령어를 통해 확인하고 복붙)
5.
CSR Object를 조회하고, 승인 요청을 확인한다.
6.
증명서는 yaml파일로도 확인가능