Kubernetes 펜테스트 방법론: 공격자 관점에서 본 클러스터 보안
Source: Dev.to
개요
2026년 현재, 쿠버네티스는 인프라스트럭처의 사실상 표준이 되었으며 공격자들의 기법도 더욱 정교해졌습니다. “대시보드가 모두에게 공개됨”과 같은 단순 실수는 이제 드물고, 대신 다음과 같은 취약점을 악용하는 공격이 증가하고 있습니다:
- RBAC 복잡성
- 단기 토큰 남용
- 공급망 취약점
이 문서는 현대적인 쿠버네티스 침투 테스트 방법론을 세 단계로 나누어 설명합니다:
- RBAC 잘못 구성 – 바인드된 토큰을 통한 권한 상승
- 원격 공격 – 외부 침입 경로와 공급망 위협
- 내부자 위협 – 컨테이너 탈출 및 클라우드 메타데이터 공격
1. RBAC 구성 오류 – 권한의 함정
Kubernetes v1.24부터는 시크릿 기반 영구 서비스 계정 토큰이 자동으로 생성되지 않습니다. **바인드된 서비스 계정 토큰(프로젝션 볼륨)**이 이제 기본값이 되었습니다. 이는 보안을 강화하지만, “pod‑creation” 권한은 여전히 위험합니다.
공격 시나리오: 단명 토큰을 이용한 권한 상승
공격자는 권한이 부여된 ServiceAccount를 마운트한 pod를 생성한 뒤, pod 내부에서 TokenRequest API를 호출해 지속성을 위한 토큰을 획득합니다.
주요 점검 항목
| 권한 / 아티팩트 | 확인 내용 |
|---|---|
create pods/ephemeralcontainers | 사용자가 권한 상승을 위해 특권 pod를 생성할 수 있는가? |
impersonate | 사용자가 다른 사용자 또는 그룹을 가장할 권한이 있는가? |
bind / escalate (Roles) | 사용자가 자신의 권한을 높이기 위해 RoleBinding을 생성할 수 있는가? |
| 레거시 시크릿 잔여물 | 만료되지 않는 정적 ServiceAccount 토큰 시크릿이 여전히 존재하는가? |
2. 원격 공격 – 외부 침입
블랙박스 테스트에서 공격자는 API‑서버 구성 오류를 넘어 개발 도구와 공급 체인에 존재하는 취약점을 노립니다.
주요 공격 벡터
| 구성 요소 | 일반적인 구성 오류 |
|---|---|
| API Server (port 6443) | system:anonymous에 권한이 부여되어 있음 – 테스트 환경에서 흔히 발생합니다. |
| Kubelet API (port 10250) | --anonymous-auth=true가 활성화되어 run을 통한 임의 코드 실행이 가능함. |
| 주변 도구 | ArgoCD, Prometheus, Kubernetes Dashboard 등 관리 인터페이스가 인터넷에 노출됨. |
| 공급 체인 | kubeconfig 파일이나 CI/CD 자격 증명이 공개 저장소에 유출됨. |
Source: …
3. 내부 위협 – 내부에서 발생하는 위협
공격자가 회색‑박스 테스트 중에 웹‑앱 RCE 등으로 pod 내부에 foothold를 얻으면, 다음 목표는 node escape입니다.
내부 정찰 체크리스트
| 지표 | 왜 중요한가 |
|---|---|
특권 컨테이너 (privileged: true 또는 CAP_SYS_ADMIN) | 호스트 디바이스에 대한 전체 접근 권한을 부여합니다. |
컨테이너 소켓 마운트 (/var/run/docker.sock 또는 /run/containerd/containerd.sock) | 공격자가 호스트에서 임의의 컨테이너를 실행할 수 있게 합니다. |
| 커널 / 런타임 취약점 | 호스트 OS 커널이나 컨테이너 런타임(예: runc)의 악용 가능한 버그. |
| 클라우드 메타데이터 서비스 (AWS IMDSv2, GCP 메타데이터) | 접근 가능하면, 공격자는 노드의 IAM 역할이나 서비스‑계정 자격 증명을 탈취할 수 있습니다. |
Summary – The Importance of Modern Defense
2026년에는 공격자들이 더 이상 단순한 포트 스캔에 의존하지 않으며, Kubernetes 내부(RBAC, 토큰, admission controller)에 능숙합니다. 방어자는 계층화된 접근 방식을 채택해야 합니다:
- Validating Admission Policy (VAP) – 권한이 높은 파드 생성을 차단하고, 토큰‑요청 남용을 금지하며, 최소 권한 RBAC를 적용합니다.
- Continuous Auditing – 레거시 시크릿, 노출된 엔드포인트, 잘못 구성된 kubelet을 정기적으로 스캔합니다.
- Supply‑Chain Hygiene –
kubeconfig자격 증명을 주기적으로 교체하고, 공개 저장소에서 누출을 검사하며, 시크릿 관리 정책을 강제합니다. - Runtime Hardening – 익명 접근을 비활성화하고, 소켓 마운트를 제한하며, 호스트 OS 및 런타임을 최신 상태로 패치합니다.
이러한 제어들을 통합함으로써 팀은 변화하는 위협 환경에 앞서 나가고, 외부 및 내부 공격 모두에 대해 Kubernetes 클러스터를 탄력적으로 유지할 수 있습니다.
쿠버네티스 보안 모범 사례
포드 보안
- Privileged Pods: CEL(Common Expression Language)를 통한 네이티브 정책 관리로 특권 포드에 대한 보안 제약을 적용합니다.
최소 권한
ServiceAccount에 최소한의 필요한 권한만 부여합니다.- 포드 사양에서
automountServiceAccountToken: false를 기본값으로 설정합니다:
apiVersion: v1
kind: Pod
metadata:
name: example-pod
spec:
automountServiceAccountToken: false
# ... other pod spec fields ...런타임 보안
- 실시간으로 비정상적인 시스템 콜 및 프로세스 실행을 모니터링하고 감지하기 위해 Tetragon 또는 Falco와 같은 eBPF 기반 도구를 배포합니다.
지속적인 보안 프로세스
- 쿠버네티스 보안을 일회성 설정 작업이 아니라 지속적인 프로세스로 다룹니다.
- 강력한 보안 태세를 유지하고 클러스터를 보호하기 위해 정기적인 침투 테스트와 구성 감사를 수행합니다.