K07: Cluster Components — 클러스터 핵심 구성 요소 보안
쿠버네티스 클러스터는 여러 핵심 컴포넌트(etcd, Kubelet, API 서버, controller-manager, scheduler)로 이루어져 있습니다. 이들 사이의 통신이 암호화되지 않거나 인증되지 않으면, 공격자는 네트워크를 감청하거나 허위 데이터를 주입해 클러스터 전체를 장악할 수 있습니다. K07은 이 핵심 컴포넌트 간의 통신 보안을 다룹니다.
미션: 암호화되지 않은 컴포넌트 간 통신
많은 운영 환경에서 “내부망이니까 괜찮다"는 이유로 컴포넌트 간 통신에 TLS를 적용하지 않거나, 보안이 허술한 기본 설정을 그대로 사용합니다.
1. 취약한 설정 (kubelet-config.yaml)
# 🚨 위험: 익명 인증 허용 및 암호화되지 않은 통신
anonymousAuth: true
readOnlyPort: 10255 # 🚨 위험: 인증 없이 데이터를 읽을 수 있는 포트 노출분석: readOnlyPort를 통해 인증 없이도 클러스터 내부 정보(Pod 상태 등)를 누구나 볼 수 있습니다. 데이터가 암호화되지 않은 채로 전송되므로 중간자 공격(MITM)에도 취약합니다.
2. 해결책 (설정 개선)
# ✅ 개선된 Kubelet 설정
anonymousAuth: false # 인증되지 않은 접근 차단
readOnlyPort: 0 # 인증되지 않은 읽기 전용 포트 비활성화
authentication:
x509:
clientCAFile: "/etc/kubernetes/pki/ca.crt" # 인증서 기반 인증 사용| 조치 | 효과 |
|---|---|
anonymousAuth: false + x509 인증서 인증 | 모든 통신 주체(client)의 신원을 확인 |
| TLS 강제 | 컴포넌트 간 데이터가 네트워크상에서 평문으로 노출되는 것 방지 |
readOnlyPort: 0 | 공격자가 정보를 수집할 불필요한 포트 자체를 제거 |
readOnlyPort(10255)와 인증서 기반 API인 --kubelet-client-certificate(보통 10250)는 별개입니다. 10255는 애초에 만들어진 목적 자체가 “인증 없는 읽기 전용"이라서, 운영 클러스터에서는 완전히 꺼두는 것(0)이 표준 권장 사항입니다.실습: 공격 → 방어 검증
1) 공격 — 인증 없이 Kubelet API 조회
curl -sk http://<node-ip>:10255/pods
# 인증 없이 노드의 Pod 목록·상세 정보가 그대로 반환됨2) 방어 — 설정 적용 후 재확인
curl -sk http://<node-ip>:10255/pods
# curl: (7) Failed to connect - Connection refused (포트 자체가 닫힘)
curl -sk https://<node-ip>:10250/pods
# 401 Unauthorized — 유효한 클라이언트 인증서 없이는 응답하지 않음포트가 닫히거나(10255), 열려 있어도 인증서 없이는 401로 거부됩니다(10250).
체크리스트
- 모든 노드에서
readOnlyPort가0으로 비활성화되어 있는가 -
anonymousAuth가false로 설정되어 있는가 - Kubelet, etcd, API 서버 간 통신에 TLS가 강제되어 있는가 (
--etcd-certfile,--etcd-keyfile등) - etcd가 자체 클라이언트 인증(mTLS) 없이 평문 포트로 열려 있지 않은가
“클러스터의 뇌와 심장(핵심 컴포넌트)은 반드시 신원 확인과 암호화가 동반되어야 한다"는 것을 배우는 미션입니다. 다음 미션(K08: Cluster to Cloud)에서는 클러스터 내부가 아니라, 그 클러스터가 올라가 있는 클라우드 인프라 자체로 권한이 새어나가는 경로를 다룹니다.