김삼영 (https://netpple.github.io/)
전효준 (https://hyojun.me)
Kubernetes Authentication Deep Dive
쿠버네티스 인증 이해하기
기술에 대한 깊은 이해를 기반으로, 새로운 인사이트를 얻고 지식을 공유하는 것을 즐기는 동료와 함께 작은 스터디를 시작했습니다.
스터디를 진행하는 동안 함께 작성하고 공유한 자료를 바탕으로 기술 블로그를 운영하고 있습니다.
1. Certificates
2. Kubernetes 인증
인감제도
신청
발급
거래
👤
인감제도
온라인 세상에서 모든 전자거래를 안심하고 사용할 수 있게 해주는 온라인 인감증명서
認 허락 인
證 증명 증
Certificates
① 신원확인 (인증)
② 구매가능 (권한)
신원 확인
👽
?!
신원 보장
👽
☹︎
X
👹
Fishing
안전한 거래를 하기에는 … 야생(위험천지)
PKI
A Public Key Infrastructure (PKI) is a collection of internet technologies
that provides secure communications in a network.
안전한 거래를 위한 …
4 요소
Revocation : 폐지
PKI
암호화 복호화
🔑
키
메시지 암호화
야생(위험천지)
메시지 암호화
야생(위험천지)
특정인만 “암호문"을 해독할 수 있어야 한다
Alice
Bob
Alice
Bob
해독할 수 있는 “키”를 어떻게 전달해야 할까
공개키, 개인키
해독할 수 있는 “키”를 어떻게 전달해야 할까
공개키 개인키
Alice
Bob
공개키로 암호화 하면 개인키로 복호화
공개키 암호화 ⇒ 개인키 소유자만 볼 수 있음
Bob
Alice
개인키 암호화 ⇒ 공개키 소유자들은 다 볼 수 있음
Bob이 보낸 메시지를 Alice만 보려면?
Bob도 Alice의 공개키가 있어야 함
당사자 둘만 보려면? 상대방 공개키를 가지면 됨
Alice는 Bob이 보낸 메시지 인지 어떻게 알지?
이 아저씨도 Alice 공개키 있음
보낸 사람을 어떻게 확인하지?
Private Key 인감도장
Public Key 인감확인 ⇒ 서명 검증
보낸 사람을 어떻게 확인하지? 전자서명 검증
Bob의 개인키로 암호화 ⇒ 전자서명
개인키 암호화가 전자서명인 이유? 개인키(인감)는 소유자만 가지기 때문
Bob의 공개키로 서명을 복호화
보낸 사람을 어떻게 확인하지? 전자서명 검증
Bob의 공개키로 복호화 되면
Bob이 보낸게 맞다 ?
이 아저씨가 Bob 행세를 했다면?
x
x
x
보낸 사람을 어떻게 확인하지? FISHING 가능
Bob의 공개키가 “가짜” 면?
Bob의 공개키인지 어떻게 신뢰? 수사기관에 의뢰
공개키 를 신뢰할 수 있는 기관(CA)에서 보장해 준다면?
인증서
공개키를 어떻게 믿지?
인증서
발급
발급
검증
인증서 발급
확실한 공인된 기관(CA)에서 보증
신청
발급
암호화 통신
CA
Alice
Bob
공개키 신뢰
Bob
검증
인증서 발급
확실한 공인된 기관(CA)에서 보증
신청
발급
암호화 통신
CA
Alice
Bob
공개키 신뢰
Bob
검증
인증서 발급
확실한 공인된 기관(CA)에서 보증
신청
발급
암호화 통신
CA
Alice
Bob
공개키 신뢰
Bob
Bob의 공개키로 확인됨
검증
안심하고�사용
인증서 검증
인증서
CSR, Certificate Signing Request
인증서를 발급 받으려면 CSR을 작성 합니다.
신청
[req]
distinguished_name = req_distinguished_name
req_extensions = v3_req
prompt = no
[req_distinguished_name]
O = system:nodes
CN = system:node:kube-node
[v3_req]
keyUsage = critical, digitalSignature, keyEncipherment
extendedKeyUsage = clientAuth
Bob
인증서 신청
CSR에 공개키를 포함하고 개인키로 서명
[req]
distinguished_name = req_distinguished_name
req_extensions = v3_req
prompt = no
[req_distinguished_name]
O = system:nodes
CN = system:node:kube-node
[v3_req]
keyUsage = critical, digitalSignature, keyEncipherment
extendedKeyUsage = clientAuth
Bob
CSR 작성
CA 서명된 인증서 발급
Bob
인증서 발급
공개키 첨부
Public key
CA�개인키�암호화
인증서 본문
해싱�1-way
CA서명 첨부
CA서명
CA
Bob
인증서 발급
CA 공개키로 복호화
CA�개인키�암호화
CA�공개키
복호화
위변조
판별
Public key
인증서 본문
공개키 첨부
CA서명 첨부
Bob
Alice
CA
검증
인증서 검증
해싱�1-way
CA서명
Bob
Bob’s
CA에서 CSR을 접수받아 처리
인증서 발급 과정
키 생성
CSR 작성 (공개키첨부)
전자서명
인증서발급신청
CSR 검증
인증서 작성
CA 전자서명
작성 ⇒ 서명 ⇒ 검증
신뢰할 수 있는 기관 ⇒ CA에서 보증함
확실한 공인된 기관 ⇒ 믿을 수 있다 !
공개키 보증
CA, Certificate Authority
CA 보증 ⇒ CA 인증서
메이저 브라우저들 CA인증서를 “기본" 탑재
CA 인증서
CA 인증서 ⇒ CA 공개키
Bob의 인증서 검증
CA 인증서
Alice
검증
CA’s
Bob 인증서 ⇒ Bob 공개키
Bob의 공개키 취득
CA 인증서
Alice
검증
Bob’s
CA’s
나눠서 처리합니다
성남시청
동사무소
CA 하나면 너무 바쁨
CA Tier
상위 CA 가 하위 CA를 임명
CA 인증 체인
공개키, 개인키로 쌍방간 암호화 통신
검증
CA
검증
Alice 개인키
Bob 공개키
Bob 개인키
Alice 공개키
드디어 …
통신할 대상이 많다면 ?
CA
검증
검증
검증
검증
검증
검증
검증
?
비효율, 복잡 ~ 키 관리, 인증서 관리 …
Alice 개인키
Bob 공개키
각자 개인키
Bob 공개키
각자 개인키
Bob 공개키
각자 개인키
Bob 공개키
각자 개인키
Bob 공개키
각자 개인키
Bob 공개키
각자 개인키
Bob 공개키
그런데 …
서버 공개키만 제공
CA
보다 심플하게 할 수 있는 방법 없을까?
✔︎ 다수를 상대로 하는 “서버”만 입증
✔︎ 서로 “대칭키”로 통신
Bob 공개키
Bob 공개키
Bob 공개키
Bob 공개키
Bob 공개키
Bob 공개키
Bob 공개키
다수를 상대로 통신 하려면 ?
디피헬만 알고리즘
키교환 알고리즘
초기 색상을 공유 �노랑
각 자 개인색을 정하고�빨강 초록
초기 색상과 섞는다
빨+노 초+노
섞은색을 서로 공유�초+노 (교환) 빨+노
상대방에게 받은 섞은색에 개인색을 섞는다
초+노+빨 == 빨+노+초
EVE는 ALICE와 BOB이 섞어 얻은
색을 알 수 없다
키교환 알고리즘
초기색상
대칭키
TLS 핸드쉐이크
1. Certificates
2. Kubernetes 인증
kube-apiserver ~ 클러스터의 모든 행정 창구
kube-apiserver
kubelet
kube-scheduler
kube-controller-manager
ETCD
kube-proxy
Pod
kubectl
Control-Plane
Client
Worker-node
Client 관점 ~ 믿고 이용해도 되나?
kube-apiserver
?
Client 관점 ~ 믿고 이용해도 되네
쿠버네티시청�API서버
콘트롤플레인1번지
2022.2.27 ~ 2023.2.27� 쿠버네티시장
!
CA가 할당한 고유번호
서명 알고리즘 식별자
발급자 (쿠버네티시티장)
유효기간
소유자
소유자 공개키
디지털 서명
용도
SAN
Apiserver Certificate
Server 관점 얘네들 ~ 믿고 제공해도 되나?
kube-apiserver
?
Kubectl kubelet scheduler
🤔
신분증 ~ 누구인지 알아야 겠음
kube-apiserver
kubelet
kube-scheduler
kube-controller-manager
ETCD
kube-proxy
Pod
kubectl
Control-Plane
Client
Worker-node
!
K8s의 모든 컴포넌트는 “신분증”을 갖고 있음
노드사무소장�큐블렛
워커노드1리
2022.2.27 ~ 2023.2.27� 쿠버네티시장
노드중개사�스케쥴러
콘트롤플레인
2022.2.27 ~ 2023.2.27� 쿠버네티시장
쿠버네티시청�API서버
콘트롤플레인1번지
2022.2.27 ~ 2023.2.27� 쿠버네티시장
콘트롤러매니저
ETCD
OOOOO�KUBEPROXY�워커노드1리
2022.2.27 ~ 2023.2.27� 쿠버네티시장
주민등록증�엔진엑스�워커노드1리
2022.2.27 ~ 2023.2.27� 쿠버네티시장
OOOOO�KUBECTL�H스퀘어
2022.2.27 ~ 2023.2.27� 쿠버네티시장
실제 “신분증”은 이렇게 생겼음
노드사무소장�큐블렛
워커노드1리
2022.2.27 ~ 2023.2.27� 쿠버네티시장
CA가 할당한 고유번호
서명 알고리즘 식별자
발급자 (쿠버네티시티장)
유효기간
소유자 (큐블렛)
소유자 공개키
디지털 서명
용도
Why Mutual?
서버 인증 => TLS 핸드쉐이크
클라이언트 인증 => 인증 + 인가(RBAC)
K8s의 인증서 사용
kube-apiserver 인증 방식
(1) TLS 주로..K8s 컴포넌트 인증
(1) TLS 주로..K8s 컴포넌트 인증
(2) Token
kube-apiserver
Service Account
(2) Token Service Account ?
Service Account
(2) Token Pod to ApiServer 인증
kube-apiserver
kube-controller-manager
ServiceAccounts�Controller
Tokens�Controller
Pod�(client)
kubelet
🗝
🔑
📄
🔒
토큰마운트
토큰발급
📄
🔒
🗝
🔑
SA 키페어
개인키
공개키
(2) Token Pod to Pod 인증
kube-apiserver
Pod�(client)
Pod�(Server)
kubelet
🗝
🔑
📄
🔒
토큰마운트
토큰발급
📄
🔒
토큰검증
📄
🔒
🗝
🔑
SA 키페어
개인키
공개키
(3) Proxy apiserver 앞단에 인증처리를 두고 싶다
kube-apiserver
front-proxy
kubectl
app
app
front-proxy-ca.crt
유저 디비
front-proxy-client.crt
발급
POST / HTTP/1.1
X-Remote-User: User1
X-Remote-Group: master
X-Remote-Extra-Scopre: openid
“유저정보"를 약속된 헤더로 전달
LDAP
IAM
DB
…
optional
kube-apiserver 인증 절차
TLS handshake
Panic Recovery
Authentication
Authorization
Timeout
…
Impersonation
이름: 큐블렛
소속: 노드사무소/워커노드1리
=> 노드 조회 허용
K8s 인증서 발급/갱신 ~ CSR
K8s CSR Signer
K8s CSR Approver
kube-controller-manager�built-in approver for a signer “kubernetes.io/kube-apiserver-kubelet-client”
kubelet 서버 TLS 인증서 제공 방식
END