본문으로 건너뛰기
K07: Cluster Components — 클러스터 핵심 구성 요소 보안

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).

체크리스트

  • 모든 노드에서 readOnlyPort0으로 비활성화되어 있는가
  • anonymousAuthfalse로 설정되어 있는가
  • Kubelet, etcd, API 서버 간 통신에 TLS가 강제되어 있는가 (--etcd-certfile, --etcd-keyfile 등)
  • etcd가 자체 클라이언트 인증(mTLS) 없이 평문 포트로 열려 있지 않은가

“클러스터의 뇌와 심장(핵심 컴포넌트)은 반드시 신원 확인과 암호화가 동반되어야 한다"는 것을 배우는 미션입니다. 다음 미션(K08: Cluster to Cloud)에서는 클러스터 내부가 아니라, 그 클러스터가 올라가 있는 클라우드 인프라 자체로 권한이 새어나가는 경로를 다룹니다.