K09: Authentication — 인증 강화
쿠버네티스 클러스터의 ‘출입문’을 지키는 가장 기본은 “누가 접속하려고 하는가?“를 확실히 확인하는 것입니다. K09는 클러스터에 대한 무분별한 익명 접근이나 취약한 서비스 계정 토큰 관리를 차단하고, 강력한 인증 체계를 구축하는 법을 다룹니다.
미션: 비인증 접근(anonymous access) 차단
설정이 미흡한 클러스터는 ‘익명 사용자’의 접근을 허용해, 공격자가 별도의 계정 없이도 API 서버에 질의를 던져 정보를 수집하게 만듭니다.
1. 취약한 설정 (API 서버 실행 옵션)
# kube-apiserver 실행 옵션
# 🚨 위험: 익명 인증 활성화
--anonymous-auth=true분석: anonymous-auth가 true면, 공격자는 인증 토큰 없이도 system:anonymous 사용자 권한으로 클러스터 내부 정보를 조회할 수 있습니다. 정찰(reconnaissance) 단계의 공격을 매우 쉽게 만듭니다.
2. 해결책 (인증 정책 강화)
# ✅ 개선: API 서버 옵션 수정
--anonymous-auth=false # 익명 접근 원천 차단
# 추가로 서비스 계정 토큰을 영구적으로 발급하지 않도록 설정
# (Kubernetes v1.22+ 에서는 Bound Service Account Tokens 사용 권장)| 조치 | 효과 |
|---|---|
anonymous-auth=false | 모든 API 요청에 유효한 인증 토큰·인증서 요구 |
| Bound Service Account Token (TokenRequest API) | 토큰 수명을 제한, 무분별한 영구 Secret 기반 토큰 지양 |
system:anonymous가 아무 권한도 없다고 안심해서는 안 됩니다. 기본 ClusterRoleBinding 중 일부(예: 오래된 클러스터의 system:discovery, system:basic-user가 system:unauthenticated 그룹에 바인딩된 경우)가 익명 사용자에게도 일부 조회 권한을 열어줄 수 있습니다. anonymous-auth=false와 별개로 kubectl get clusterrolebindings -o json | jq '.items[] | select(.subjects[]?.name=="system:anonymous" or .subjects[]?.name=="system:unauthenticated")'로 실제 노출 범위를 점검해야 합니다.실습: 공격 → 방어 검증
1) 공격 — 익명 인증으로 API 직접 호출
curl -sk https://<api-server>:6443/api/v1/pods
# 인증 없이 클러스터 내 Pod 목록이 즉시 반환됨2) 방어 — anonymous-auth=false 적용 후 재확인
curl -sk https://<api-server>:6443/api/v1/pods
# {
# "kind": "Status",
# "status": "Failure",
# "message": "Unauthorized",
# "code": 401
# }동일한 요청이 401 Unauthorized로 거부됩니다. 클러스터가 요청자의 신원을 먼저 확인하려 시도하는 것입니다.
체크리스트
-
kube-apiserver의--anonymous-auth가false인가 -
system:anonymous/system:unauthenticated에 바인딩된 ClusterRoleBinding이 남아있지 않은가 - 서비스 계정 토큰이 무기한 Secret 방식이 아니라 Bound(TokenRequest API) 방식으로 발급되는가
- 사람 사용자의 인증에 정적 토큰 대신 OIDC 같은 중앙화된 인증을 쓰는가
“누구인지 증명하지 못한 자는 클러스터의 문턱도 넘을 수 없다"는 보안의 가장 기본 원칙을 구현하는 미션입니다. 마지막 미션(K10: Logging & Monitoring)에서는 인증을 통과한 이후의 모든 행위를 어떻게 기록하고 추적할지를 다룹니다.