게시: 2026년 3월 4일
KENSAI의 클라우드 보안 연구팀은 12,000개의 프로덕션 Kubernetes 클러스터를 유럽 전역 기업을 대상으로 분석한 결과, 58%가 측면 이동 및 cluster-admin으로의 권한 상승을 허용할 만큼 심각한 RBAC(역할 기반 접근 제어) 설정 오류를 포함하고 있는 것으로 나타났습니다. 가장 위험한 5가지 패턴 — 와일드카드 권한, 기본 서비스 계정 남용, 과도한 ClusterRoleBinding, 파드 생성 권한을 통한 네임스페이스 탈출, 특권 파드에서의 토큰 마운팅 — 은 대다수의 배포 환경에 존재합니다. 대부분의 조직은 초기 설정 이후 RBAC 정책을 감사하지 않습니다.
⚡ 스캔된 클러스터의 58%에서는 공격자가 파드 하나만 침해해도 RBAC 설정 오류만으로 몇 분 안에 완전한 cluster-admin 권한까지 상승할 수 있습니다.
가장 만연한 설정 오류: 클러스터의 23%에는 와일드카드(*) 동사 또는 리소스가 설정된 커스텀 ClusterRole이 있습니다. 팀들은 cluster-admin 역할을 시작점으로 복사한 뒤 범위를 좁히는 것을 잊어버립니다. 이러한 역할에 바인딩된 서비스 계정을 가진 파드 하나만 있어도 모든 네임스페이스의 모든 리소스 — 시크릿, configmap, 노드, API 서버 자체 — 에 대한 무제한 접근 권한을 갖습니다.
# 위험: 와일드카드 ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: devops-tools
rules:
- apiGroups: ["*"]
resources: ["*"]
verbs: ["*"] # ← 완전한 cluster-admin과 동일한 권한
모든 Kubernetes 네임스페이스에는 default 서비스 계정이 있으며, 명시적으로 비활성화하지 않는 한 파드에 자동으로 마운트됩니다. 클러스터의 41%에서는해당 네임스페이스 중 최소 하나 이상에서 기본 서비스 계정에 상승된 권한이 부여되어 있습니다 — 흔히 운영자가 디버깅 중 빠르게 kubectl create rolebinding 명령을 실행한 뒤 정리하지 않았기 때문입니다. 해당 네임스페이스의 파드에서 RCE 권한을 획득한 공격자는 즉시 이러한 권한을 상속받습니다.
클러스터의 34%에는 커스텀 ClusterRoleBinding이 10개를 초과해 존재하며, 모든 네임스페이스에 걸쳐 권한을 부여하는 바인딩입니다. 다수가 예를 들어 system:authenticated 또는 system:serviceaccounts와 같은 그룹에 광범위한 역할을 바인딩하는데, 이는 사실상 클러스터의 모든 인증된 사용자 또는 모든 서비스 계정에 상승된 접근 권한을 부여하는 것입니다.
다음 권한을 가진 사용자는 create pods 어떤 네임스페이스에서든 호스트 파일시스템을 마운트하거나, 특권 컨테이너를 실행하거나, 해당 네임스페이스의 아무 서비스 계정으로든 파드를 생성할 수 있습니다. 클러스터의 29%에서는개발자가 Pod Security Standards 적용 없이 파드 생성 권한을 가지고 있어, 하위 노드로의 손쉬운 컨테이너 탈출이 가능합니다.
Kubernetes는 기본적으로 서비스 계정 토큰을 파드에 마운트합니다. 이것이 특권 파드 스펙이나 호스트 네트워크 접근과 결합되면, 공격자는 토큰을 탈취해 API 서버에 인증할 수 있으며 클러스터 외부에서도 접근이 가능합니다. 스캔된 클러스터 중 12%만이 automountServiceAccountToken: false 설정을 API 접근이 필요 없는 워크로드에 적용하고 있습니다.
get secrets 권한이 모든 네임스페이스에 걸쳐 부여되어 있었고, 공격자는 4분 만에 데이터베이스 자격 증명, API 키, TLS 인증서를 추출했습니다.
분석된 프로덕션 Kubernetes 클러스터의 절반 이상이 침해된 파드에서 cluster-admin 수준 접근으로의 권한 상승을 가능하게 하는 RBAC 설정 오류를 최소 하나 이상 포함하고 있습니다.
설정 오류가 있는 클러스터를 대상으로 한 침투 테스트에서, 최초 파드 침해부터 완전한 cluster-admin 접근까지 걸린 평균 시간은 3.2분이었습니다. 자동화 도구인 peirates 및 kubeletctl는 이를 간단하게 만듭니다.
와일드카드 읽기 권한을 가진 클러스터는 평균 847개의 Kubernetes 시크릿을 노출했으며, 여기에는 모든 네임스페이스에 걸친 데이터베이스 자격 증명, API 키, TLS 인증서, 클라우드 공급자 IAM 토큰이 포함됩니다.
대다수 조직은 클러스터 프로비저닝 시 RBAC를 한 번 구성한 뒤 다시는 검토하지 않습니다. 팀이 디버깅, CI/CD 파이프라인, 모니터링을 위해 권한을 추가하면서 롤 바인딩이 수개월에 걸쳐 누적되지만, 이를 제거하는 경우는 없습니다.
KENSAI의 Kubernetes 보안 모듈은 이제 자동화된 RBAC 분석을 제공하며, 클러스터 내 모든 서비스 계정, 역할, 바인딩을 매핑해 권한 상승 경로를 식별합니다. 이 스캐너는 권한 체인의 시각적 그래프를 생성하고, 침해된 워크로드에서 cluster-admin까지의 최단 경로를 강조 표시합니다.
모든 워크로드는 자체 전용 서비스 계정을 가져야 하며, 이 계정에는 실제로 필요한 권한만부여되어야 합니다. 네임스페이스 범위의 Role로 충분한 경우 ClusterRole 바인딩을 피하십시오. API 접근이 필요 없는 파드에는 automountServiceAccountToken: false를 사용하십시오 — 이는 대다수의 애플리케이션 워크로드에 해당합니다.
Kubernetes Pod Security Standards(PSS)를 restricted 수준으로 적용하면 파드가 root로 실행되거나, 호스트 경로를 마운트하거나, 특권 모드를 사용하는 것을 방지할 수 있습니다. Pod Security Admission을 사용해 네임스페이스 수준에서 이를 적용하십시오. 이렇게 하면 RBAC 권한이 지나치게 광범위하더라도 컨테이너 탈출 경로가 제거됩니다.
정기적으로 분기별 RBAC 감사를실시하십시오. 모든 ClusterRoleBinding을 검토하고, 퇴사한 팀원이나 폐기된 서비스에서 남은 오래된 바인딩을 식별하며, 어떤 서비스 계정도 필요 이상의 권한을 갖지 않도록 검증하십시오. KENSAI는 지속적인 드리프트 탐지로 이를 자동화할 수 있습니다.
kubectl get clusterroles -o json | jq '.items[] | select(.rules[]?.verbs[]? == "*")'automountServiceAccountToken: false 설정restricted PSS 적용kubectl get clusterrolebindings -o wide 광범위한 그룹에 바인딩된 항목 표시kensai scan --k8s-rbac 명령을 실행하면 60초 이내에 완전한 RBAC 위험 평가를 받을 수 있습니다. 리포트에는 권한 상승 그래프, 발견 사항별 구체적인 해결 단계, 해당 지침의 적용을 받는 조직을 위한 NIS2 컴플라이언스 매핑이 포함됩니다.
*) 동사 및 리소스를 커스텀 ClusterRole에서 제거system:authenticated 또는 system:serviceaccountsautomountServiceAccountToken: false 설정restricted 수준으로 Pod Security Standards 적용