안녕하세요! 쿠버네티스 클러스터를 운영하고 계신가요? 그렇다면 '보안'은 절대 놓칠 수 없는 가장 중요한 주제일 겁니다. 특히 여러 사용자와 워크로드가 공존하는 환경에서, 누가 무엇을 할 수 있는지 통제하는 RBAC(역할 기반 접근 제어) 는 보안의 핵심 중 핵심이라고 할 수 있죠. 🚀
하지만 RBAC 설정, 혹시 "대충 cluster-admin 주면 되겠지?" 하고 넘어가진 않으셨나요? 잘못된 RBAC 설정은 해커에게 클러스터 전체를 내어주는 지름길이 될 수 있습니다.
오늘은 클러스터 운영자를 위해, 안전하고 효율적인 RBAC 설계를 위한 핵심 원칙과 모범 사례(Best Practices), 그리고 우리가 무심코 넘어가기 쉬운 권한 상승 위험까지 샅샅이 파헤쳐 보겠습니다!
1. 기본 원칙: 이것만은 꼭 지키세요! 🙏
안전한 RBAC 설계는 몇 가지 기본 원칙에서 시작됩니다. 복잡해 보여도 이 원칙들만 잘 지키면 보안 수준을 크게 높일 수 있습니다.
최소 권한의 원칙 (Least Privilege)
가장 중요하고 기본적인 원칙입니다. 사용자든, 서비스 어카운트(Service Account)든, 자신의 역할을 수행하는 데 필요한 최소한의 권한만 부여해야 합니다. 열쇠 꾸러미 전체를 주는 대신, 필요한 방의 열쇠 하나만 주는 것과 같습니다.
- ✅ 네임스페이스(Namespace) 단위로 권한을 부여하세요. 클러스터 전체에 적용되는 ClusterRoleBinding 대신, 특정 네임스페이스 내에서만 유효한 RoleBinding을 사용하세요. 이렇게 하면 특정 사용자의 활동 범위를 명확하게 제한할 수 있습니다.
- ❌ 와일드카드(*) 권한은 피하세요. resources: ["*"] 와 같은 설정은 정말 위험합니다. 현재 클러스터에 있는 모든 리소스는 물론, 미래에 추가될 새로운 CRD(Custom Resource Definition)에 대한 권한까지 자동으로 부여하기 때문입니다.
- 👨✈️ cluster-admin 역할은 신중하게 사용하세요. 클러스터 관리자라고 해서 평상시 모든 작업을 cluster-admin 계정으로 하는 것은 위험합니다. 실수로 중요한 리소스를 수정하거나 삭제할 수 있기 때문이죠. 낮은 권한의 계정을 사용하고, 필요할 때만 impersonate(가장) 기능을 사용하는 것이 안전합니다.
- 🚫 system:masters 그룹에 사용자를 추가하지 마세요! 이 그룹의 멤버는 모든 RBAC 권한 검사를 우회하는 슈퍼유저가 됩니다. 한번 부여된 권한은 RoleBinding을 제거해도 회수할 수 없으니 절대 사용하면 안 됩니다.
특권 토큰(Privileged Token) 배포 최소화
강력한 권한을 가진 서비스 어카운트 토큰이 파드에 마운트되는 것은 보안 사고의 시작점이 될 수 있습니다.
- 강력한 권한이 필요한 파드는 특정 노드에서만 실행하세요. Taints나 NodeAffinity 등을 사용해 중요한 파드가 신뢰할 수 없는 다른 파드와 함께 실행되지 않도록 격리하세요.
- 서비스 어카운트 토큰 자동 마운트를 비활성화하세요. 파드 스펙에 automountServiceAccountToken: false를 설정하면 불필요한 토큰 마운트를 막을 수 있습니다. 토큰이 꼭 필요한 워크로드에만 수동으로 마운트하는 것이 좋습니다.
주기적인 검토
RBAC 설정은 한 번으로 끝나는 것이 아닙니다. 정기적으로 불필요한 권한이 있는지, 삭제된 사용자의 권한이 남아있는지 검토해야 합니다. 공격자가 삭제된 사용자와 동일한 이름의 계정을 생성하면, 이전 사용자의 모든 권한을 상속받을 수 있기 때문입니다.
2. 나도 모르게 권한 상승? 꼭 알아야 할 위험 포인트 🚨
"이 정도 권한은 괜찮겠지?"라고 생각했던 설정이 심각한 권한 상승(Privilege Escalation)으로 이어질 수 있습니다. 아래 항목들은 특히 주의 깊게 살펴보셔야 합니다.
Secret list, watch 권한의 함정
get 권한이 Secret의 내용을 읽는다는 건 모두가 압니다. 하지만 list와 watch 권한 역시 Secret의 내용을 모두 노출시킬 수 있다는 사실을 아셨나요? kubectl get secrets -A -o yaml 명령을 실행하면 모든 Secret의 내용(data 필드)이 그대로 출력됩니다.
워크로드 생성(create) 권한의 막강함
파드(Pod)나 디플로이먼트(Deployment) 같은 워크로드를 생성할 수 있는 권한은 생각보다 훨씬 강력합니다.
- 해당 네임스페이스의 모든 Secret, ConfigMap을 파드에 마운트해서 내용을 탈취할 수 있습니다.
- 해당 네임스페이스의 어떤 서비스 어카운트로도 파드를 실행시켜 그 서비스 어카운트의 권한을 획득할 수 있습니다.
- 만약 privileged: true 설정이 가능하다면, 노드(Host)의 권한을 탈취하는 것도 가능합니다.
PersistentVolume 생성 권한
사용자가 PersistentVolume을 직접 생성할 수 있다면, hostPath 볼륨을 만들어 노드의 파일 시스템에 접근할 수 있습니다. 이는 컨테이너 탈출 및 노드 장악으로 이어지는 매우 심각한 보안 문제입니다.
위험한 동사(Verb) 4형제: escalate, bind, impersonate, proxy
- escalate: 자신이 가진 권한보다 더 높은 권한을 가진 Role을 만들 수 있게 해주는, 이름 그대로 '권한 상승' 동사입니다.
- bind: 자신이 가지지 않은 권한이 포함된 Role을 다른 사용자에게 바인딩할 수 있게 해줍니다. 즉, 다른 사람에게 나보다 더 큰 권한을 줄 수 있습니다.
- impersonate: 다른 사용자를 '가장'하여 그 사용자의 모든 권한을 획득할 수 있습니다.
- nodes/proxy: 노드의 프록시 하위 리소스에 접근 권한이 있다면, Kubelet API를 직접 호출하여 해당 노드의 모든 파드에서 명령을 실행할 수 있습니다. 이는 RBAC 검사와 감사 로그를 모두 우회합니다.
그 외 위험 요소들
- CSR 생성/승인: 새로운 클라이언트 인증서를 만들어 클러스터에 대한 추가 접근 권한을 얻을 수 있습니다.
- serviceaccounts/token 생성: 기존 서비스 어카운트의 토큰을 요청하여 해당 계정의 권한을 획득할 수 있습니다.
- Admission Webhook 제어: 클러스터에 생성되는 모든 오브젝트를 읽거나 변조할 수 있는 막강한 권한입니다.
- 네임스페이스 patch 권한: 네임스페이스의 레이블을 수정하여 Pod Security Admission 정책을 우회하거나 NetworkPolicy 규칙을 변경할 수 있습니다.
3. 서비스 거부(DoS) 공격의 위험 😫
사용자가 클러스터에 오브젝트를 생성할 권한이 있다면, 의도적이든 아니든 엄청나게 크거나 많은 수의 오브젝트를 생성하여 etcd를 마비시킬 수 있습니다. 이는 클러스터 전체의 장애로 이어지는 서비스 거부 공격이 될 수 있습니다.
✅ 해결책: ResourceQuotas를 사용하여 사용자가 네임스페이스 내에서 생성할 수 있는 오브젝트의 수와 크기를 제한하세요.
마무리하며
쿠버네티스 RBAC는 강력한 만큼 복잡하고, 작은 실수가 큰 보안 사고로 이어질 수 있습니다. 오늘 살펴본 Best Practices를 바탕으로 여러분의 클러스터 RBAC 설정을 다시 한번 점검해 보세요.
'최소 권한의 원칙' 을 항상 기억하고, 위험한 권한이 불필요하게 부여되지 않았는지 주기적으로 검토하는 습관이 안전한 클러스터를 만드는 첫걸음입니다.
'클라우드 > 쿠버네티스 보안' 카테고리의 다른 글
| 🛡️ 쿠버네티스 보안의 새로운 표준: Pod Security Admission (PSA) 완벽 가이드 (0) | 2025.12.12 |
|---|---|
| 🤔 allowPrivilegeEscalation: false - 쓰기만 하면 정말 안전할까? (privileged: true와 완벽 비교) (0) | 2025.10.07 |
| 👩💻 Kubernetes 보안의 핵심: Pod Security Standards 완벽 정복하기 (0) | 2025.10.07 |
| 헷갈리는 보안 개념, Security Policy vs. Security Context 완벽 정리! 🧐 (0) | 2025.10.07 |
| 파드 보안 표준(Pod Security Standards), 왜 필요할까요? 🤔 (0) | 2025.10.06 |
