[47] cluster_ca_certificate

                ┌──────────────┐
                │  EKS API     │
                │  Server      │
                └─────┬────────┘
                      │ TLS (CA 검증)
        ┌─────────────┼─────────────┐
        │             │             │
   kubectl       Terraform       CI/CD
   (client)       (client)       (client)

                      │
                      │ kubelet TLS + IAM
                      ▼
               Worker Nodes
                      │
                      │ Pod 실행
                      ▼
                    Pods

 

[1]

cluster_ca_certificate =? 

TLS 인증서 검증용 CA(루트 인증기관)

: 이 API 서버가 진짜 EKS 클러스터가 맞는지 검증하는 신뢰 루트 키

 

-

 

[2]

왜 CA가 필요하냐

Terraform / Kubectl / Client가 클러스터 접속할 때

Client → https → EKS API Server

TLS Handshake 발생

1. 서버가 인증서 제시

2. 클라이언트가 CA로 검증

3. 신뢰되면 통신

 

-

 

CA 없으면

- MITM 공격 가능

- FAKE API 서버 접속 위험

-> 그래서 provider에 CA를 넣어줌

 

-

 

[3]

인증 2단계 구조

클러스터 접속은 항상 두 단계

 

1. TLS 인증 (서버 신뢰 검증)

- 지금 말하는 CA

- "이 서버가 진짜인지"

 

2. 사용자 인증 (접속 권한)

- token / aws-iam-authenticator

- "너 누구냐"

 

host  = endpoint
token = auth.token
ca    = certificate

이 세 개가 합쳐져야 접속됨

 

-

 

[4]

Node가 인증받는거 아닌지

* 둘 다 인증하지만, 목적이 다르다

 

A : Controle Plane <-> Client 인증

대상 : kubectl / Terraform / ArgoCD / CI,CD

-> 이 때 CA 필요

 

B : Control Plane <-> Node 인증

1. Node 부팅

2. Kubelet 실행

3. EKS API 접속

4. IAM + bootstrap token 인증

5. Node object 등록

-> CA + Kubelet client cert + IAM이 결합된 구조

노드도 TLS 쓴다

 

-

 

[5]

CA는 어디서 온 건지

EKS 클러스터 생성 시 AWS가 자동 생성

- 클러스터 전용 CA

- etcd + API서버 TLS에 사용

- kubeconfig에도 포함

Terraform data soruce가 그걸 조회하는 것

 

 

-

 

[6]

실무에서 자주 보이는 에러 (CA 잘못될 시)

x509: certificate signed by unknown authority

- endpoint는 맞는데

- 신뢰 루트가 없어서 접속 거부

 

 

-

 

[7]

cluster_ca_certificate =  API 서버 TLS 검증용 루트 인증서

클라이언트(provider/kubectl)이 서버 신뢰 검증할 때 사용

노드도 별도로 TLS/IAM 인증 수행함

 

CA : 여권 발급국 인감

API 서버 인증서 = 여권

Token : 입국 비자

Node : 짱기 체류자 등록증