DEEP DIVE REPORT

Kubernetes RBAC 취약점 - 클라우드 네이티브 보안 위협 심층 분석

SecurityDesk
2026.04.20 조회 7

서론: 클라우드 네이티브 시대의 RBAC 중요성

클라우드 네이티브 애플리케이션이 급증함에 따라 Kubernetes는 사실상의 표준 컨테이너 오케스트레이션 플랫폼으로 자리 잡았습니다. Kubernetes RBAC는 사용자와 서비스 계정의 권한을 세밀하게 제어하는 주요 보안 메커니즘으로, 최소 권한 원칙(Least Privilege)을 실현하는 데 필수적입니다.

그러나 복잡한 RBAC 규칙, 기본 제공 권한의 과도한 할당, 그리고 지속적인 구성 변경은 보안 관리자에게 큰 과제가 되고 있습니다. 다양한 보안 보고서에서 기업 Kubernetes 클러스터의 상당수에서 과도한 RBAC 권한이 식별되고 있습니다.

본론 1: RBAC 권한 상승 취약점

1.1 고위험 권한 집합

Kubernetes RBAC에는 권한 상승으로 이어질 수 있는 여러 고위험 권한이 존재합니다:

a) Secrets 조회 권한

rules:
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get", "list", "watch"]

- 위험도: Critical
- 영향: listwatch 권한도 실질적으로 모든 시크릿의 내용을 노출
- 공격 시나리오: 공격자가 데이터베이스 자격 증명, API 키, TLS 인증서 탈취

b) 워크로드 생성 권한

rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["create"]

- 위험도: High
- 영향: 네임스페이스 내의 다른 리소스(Secrets, ConfigMaps, PV)에 암시적 접근
- 공격 시나리오: 특권 Pod 생성 → 노드 파일 시스템 접근 → 권한 상승

c) PersistentVolume 생성 권한

rules:
- apiGroups: [""]
  resources: ["persistentvolumes"]
  verbs: ["create"]

- 위험도: High
- 영향: hostPath 볼륨 생성 가능 → 노드 파일 시스템 무제한 접근
- 공격 시나리오: 호스트의 Kubelet 자격 증명 탈취, 다른 컨테이너 데이터 접근

d) nodes/proxy 하위 리소스 접근

rules:
- apiGroups: [""]
  resources: ["nodes/proxy"]
  verbs: ["get"]

- 위험도: Critical
- 영향: Kubelet API에 대한 접근 → 모든 Pod에서 명령 실행
- 특이사항: get 권한만으로도 명령 실행 가능 (읽기 전용이 아님)

e) escalate 동사

rules:
- apiGroups: ["rbac.authorization.k8s.io"]
  resources: ["clusterroles"]
  verbs: ["escalate"]

- 위험도: Critical
- 영향: 사용자가 현재 갖고 있지 않은 더 높은 권한으로 ClusterRole 생성 가능
- 설명: RBAC의 권한 상승 방어 메커니즘 우회

f) bind 동사

rules:
- apiGroups: ["rbac.authorization.k8s.io"]
  resources: ["clusterrolebindings", "rolebindings"]
  verbs: ["bind"]

- 위험도: Critical
- 영향: 사용자가 가지고 있지 않은 권한으로 바인딩 생성 가능
- 설명: 권한 상승 방어 우회, 임의 Role에의 접근 허용

g) impersonate 동사

rules:
- apiGroups: ["authentication.k8s.io"]
  resources: ["users", "groups", "serviceaccounts"]
  verbs: ["impersonate"]

- 위험도: High
- 영향: 다른 사용자나 서비스 계정의 권한으로 작업 수행 가능

1.2 최근 발견된 Kubernetes 보안 취약점

Kubernetes 클러스터 보안에 영향을 미치는 최근 취약점들입니다:

CVE-2024-7646 (High)

  • 컴포넌트: ingress-nginx
  • 취약점: Ingress 객체 생성 권한을 가진 공격자가 주입 검증을 우회하여 ingress-nginx 컨트롤러의 자격 증명 탈취 가능
  • 영향: 기본 구성에서 해당 자격 증명은 클러스터 내 모든 시크릿에 접근 가능
  • CWE: CWE-20 (Improper Input Validation)
  • 완화: ingress-nginx를 최신 버전으로 업그레이드
  • 상세 정보: NVD - CVE-2024-7646

CVE-2024-9486 (Medium)

  • 컴포넌트: Kubernetes Image Builder
  • 버전 영향: v0.1.37 이하
  • 취약점: 이미지 빌드 과정에서 기본 자격 증명이 활성화되어 있음
  • 영향: Proxmox provider로 생성된 VM 이미지는 기본 자격 증명을 통해 접근 가능, root 접근 획득
  • CWE: CWE-798 (Use of Hard-coded Credentials)
  • 완화: v0.1.38 이상으로 업그레이드
  • 상세 정보: NVD - CVE-2024-9486

CVE-2024-10220 (Medium)

  • 컴포넌트: kubelet
  • 버전 영향: 1.28.11 이하, 1.29.0-1.29.6, 1.30.0-1.30.2
  • 취약점: 특수하게 조작된 gitRepo 볼륨을 통한 임의 명령 실행 가능
  • 영향: 노드 수준에서 코드 실행 및 권한 상승
  • CWE: CWE-22 (Improper Limitation of a Pathname to a Restricted Directory 'Path Traversal')
  • 완화: 해당 버전으로 패치 적용, gitRepo 볼륨 사용 제한
  • 상세 정보: NVD - CVE-2024-10220

본론 2: 실제 공격 패턴 분석

2.1 권한 상승 공격 시나리오

시나리오 1: Pod 생성을 통한 권한 상승

1. 공격자: pod/create 권한만 가짐
2. 악의적 Pod 생성:
   apiVersion: v1
   kind: Pod
   metadata:
     name: attacker-pod
   spec:
     containers:
     - name: attacker
       image: ubuntu
       command: ["/bin/sh", "-c", "sleep infinity"]
       volumeMounts:
       - name: host-root
         mountPath: /host
         readOnly: true
     volumes:
     - name: host-root
       hostPath:
         path: /
         type: Directory
     serviceAccountName: privileged-sa
3. 서비스 계정 권한 탈취
4. 클러스터 admin 권한 획득

완화 조치:
- Pod Security Admission으로 권한 제한
- RoleBinding 대신 ClusterRoleBinding 제한
- 네임스페이스 단위 리소스 격리

시나리오 2: Secrets 조회를 통한 자격 증명 탈취

1. 공격자: secrets/list 권한 획득
2. 명령 실행:
   kubectl get secrets -A -o yaml
3. 모든 시크릿 내용 탈취 (base64 디코딩 필요 없음)
4. 탈취 정보:
   - 데이터베이스 비밀번호
   - API 키 및 토큰
   - TLS 인증서
   - 서비스 계정 토큰

완화 조치:
- secrets 리소스에 대한 접근 제한
- 외부 시크릿 관리 솔루션 사용 (Vault, AWS Secrets Manager)
- 시크릿 암호화 (Encryption at Rest)

시나리오 3: escalate 권한을 통한 admin 탈취

1. 공격자: clusterrole/escalate 권한 획득
2. 권한 상승 공격:
   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRole
   metadata:
     name: escalated-role
   rules:
   - apiGroups: ["*"]
     resources: ["*"]
     verbs: ["*"]
3. 자신에게 바인딩:
   kubectl create clusterrolebinding escalated-binding \
     --clusterrole=escalated-role \
     --user=attacker
4. 클러스터 전체 제어 권한 획득

완화 조치:
- escalate 권한 엄격히 제한
- admin 계정만 cluster-admin 사용
- 권한 변경 감시 및 알림

2.2 인증 우회 공격

system:masters 그룹 우회

# 공격자가 system:masters 그룹에 추가되면 RBAC 검사가 완전히 우회됨
kubectl create clusterrolebinding attacker-admin \
  --clusterrole=cluster-admin \
  --group=system:masters

- 위험: 모든 RBAC 권한 검사 우회, 권한 취소 불가
- 완화: system:masters 그룹 멤버십 엄격한 감사

2.3 다중 테넌트 환경의 위험

다중 테넌트 클러스터에서 RBAC 오용은 심각한 데이터 유출로 이어질 수 있습니다:

  • 문제: 네임스페이스 내 경계가 약함
  • 공격: 한 네임스페이스의 사용자가 다른 네임스페이스의 리소스 접근
  • 완화: 네임스페이스 분리 강화, NetworkPolicy 사용

본론 3: 완화 조치 및 대응 전략

3.1 RBAC 보안 베스트 프랙티스

최소 권한 원칙 적용

# ❌ 안 좋은 예: 와일드카드 사용
rules:
- apiGroups: ["*"]
  resources: ["*"]
  verbs: ["*"]

# ✅ 좋은 예: 구체적 권한 지정
rules:
- apiGroups: ["apps"]
  resources: ["deployments"]
  verbs: ["get", "list", "watch", "create", "update"]
  resourceNames: ["my-app"]

네임스페이스 단위 권한 부여

# RoleBinding 사용 (권장)
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: developer-binding
  namespace: production
subjects:
- kind: User
  name: developer
roleRef:
  kind: Role
  name: developer-role
  apiGroup: rbac.authorization.k8s.io

Service Account 토큰 자동 마운트 비활성화

apiVersion: v1
kind: Pod
metadata:
  name: secure-pod
spec:
  automountServiceAccountToken: false
  serviceAccountName: limited-sa

3.2 RBAC 감사 및 모니터링

주기적 권한 검토

# 과도한 권한 확인
kubectl get rolebindings,clusterrolebindings --all-namespaces -o json | \
  jq '.items[] | select(.subjects[]?.kind=="Group" and .subjects[]?.name=="system:masters")'

# cluster-admin 바인딩 확인
kubectl get clusterrolebindings -o json | \
  jq '.items[] | select(.roleRef.name=="cluster-admin")'

권한 변경 감시

# AuditPolicy 설정
apiVersion: audit.k8s.io/v1
kind: Policy
rules:
- level: Metadata
  resources:
  - group: "rbac.authorization.k8s.io"
    resources: ["roles", "rolebindings", "clusterroles", "clusterrolebindings"]

RBAC 보안 스캐너 활용

  • kube-hunter: RBAC 취약점 자동 발견
  • kube-bench: CIS 벤치마크 준수 확인
  • rbac-lookup: 권한 관계 시각화

3.3 네임스페이스 격리 강화

NetworkPolicy 적용

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all
  namespace: production
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress

Pod Security Standard

# 네임스페이스 레벨 정책 적용
apiVersion: v1
kind: Namespace
metadata:
  name: production
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/warn: restricted

3.4 외부 보안 솔루션 활용

시크릿 관리

  • HashiCorp Vault: 중앙 집중식 시크릿 관리
  • AWS Secrets Manager: AWS 네이티브 통합
  • Azure Key Vault: Azure 환경용

권한 관리 자동화

  • OPA (Open Policy Agent): 선언적 정책 강화
  • Kyverno: 쿠버네티스 네이티브 정책 관리
  • Gatekeeper: OPA 기반 입학 컨트롤러

결론

Kubernetes RBAC은 강력한 보안 도구이지만, 잘못된 구성과 과도한 권한 부여는 심각한 보안 위협을 초래할 수 있습니다. 최근 발견된 CVE들과 알려진 권한 상승 패턴들은 RBAC 구성의 중요성을 강조합니다.

대응 방안

즉시 대응 (24시간 이내)

  • [ ] cluster-admin 권한을 가진 모든 사용자와 그룹 확인
  • [ ] system:masters 그룹 멤버십 감사
  • [ ] 와일드카드 권한(*) 사용 여부 검사
  • [ ] 고위험 권한(escalate, bind, impersonate) 소유자 확인

단기 대응 (72시간 이내)

  • [ ] RBAC 보안 스캐너(kube-hunter, kube-bench) 실행
  • [ ] AuditPolicy 구성 및 로깅 활성화
  • [ ] Service Account 토큰 자동 마운트 비활성화
  • [ ] 네임스페이스별 Pod Security Standard 적용

장기 대응 (1주 이내)

  • [ ] OPA/Kyverno로 RBAC 정책 자동화
  • [ ] 외부 시크릿 관리 솔루션 도입
  • [ ] RBAC 권한 검토 프로세스 수립
  • [ ] 보안 훈련 및 모의 해킹 테스트 실시

참고자료


본 콘텐츠는 AI 기술로 생성된 분석 리포트를 포함하고 있습니다. 내용 중 사실과 다르거나 보완이 필요한 정보를 발견하시면 댓글을 통해 소중한 의견 부탁드립니다. 여러분의 피드백은 더 정확한 보안 정보 공유에 큰 도움이 됩니다.

댓글 (0)

댓글을 작성하려면 로그인이 필요합니다.

로그인

아직 댓글이 없습니다.

첫 번째 댓글을 작성해보세요!

IT 도구 서랍

→ Unix: 2025-01-15T09:30:00
→ 날짜: 1736934600

→ ASCII: ABC
→ 문자: 65 66 67

ASCII 코드표 — 클릭하면 입력란에 추가

DecHex약어설명
DecHex문자
DecHex문자

→ 유니코드: 홍길동
→ 문자: \ud64d\uae38\ub3d9