목차
쿠버네티스 클러스터를 운영하다 보면 cluster-admin 권한의 편리함에 빠지기 쉽습니다. 하지만 이는 단 하나의 실수나 계정 탈취만으로 클러스터 전체를 위험에 빠뜨릴 수 있는 지름길입니다.
이 가이드에서는 ‘cluster-admin 남용을 없애고 네임스페이스와 역할 기반으로 최소 권한 운영’을 목표로, 쿠버네티스의 네임스페이스 격리와 역할 기반 접근 제어(RBAC)를 통해 보안 폭발 반경을 최소화하는 방법을 단계별로 알아봅니다.
1. 네임스페이스, 격리의 첫걸음: 설계 원칙
네임스페이스는 쿠버네티스 리소스를 논리적으로 격리하는 가장 기본적인 단위입니다. 효과적인 격리를 위해 다음 원칙을 반드시 따르세요.
- 용도별 분리: 테넌트, 업무 영역, 애플리케이션 수명 주기(개발/스테이징/운영)에 따라 네임스페이스를 분리하세요. 네임스페이스 간 교차 접근은 기본적으로 거부하는 것을 원칙으로 삼아야 합니다. 클러스터 전체에 영향을 미치는 권한은 예외적인 경우에만 사용하고, 네임스페이스 단위의 권한 위임을 우선해야 합니다.
- 기본 서비스 계정 토큰 비활성화: 보안 강화를 위해 기본 서비스 계정(ServiceAccount)의 API 토큰이 자동으로 마운트되지 않도록 설정하세요 (
automountServiceAccountToken: false). 꼭 필요한 워크로드에만 전용 서비스 계정을 만들어 토큰을 명시적으로 마운트하는 것이 안전합니다. - 네트워크 정책(Network Policy) 적용: 파드 간 통신은 기본적으로 모두 차단(Default Deny)하는 것에서 시작하세요. 필요한 트래픽만 명시적으로 허용하는 정책을 적용하여 네트워크 통신 범위를 최소화해야 합니다. 사용 중인 CNI(Container Network Interface)가 네트워크 정책을 지원하는지 확인은 필수입니다. 자세한 내용은 네트워크 정책 공식 문서를 참고하세요.
- 리소스 쿼터(Resource Quota) 설정: 특정 네임스페이스가 클러스터의 모든 리소스를 독점하지 않도록 리소스 쿼터와 리밋 레인지를 설정하세요. 이를 통해 자원 경쟁으로 인한 '시끄러운 이웃(Noisy Neighbor)' 문제를 방지할 수 있습니다. 관련 내용은 Resource Quotas 문서에서 확인할 수 있습니다.
2. RBAC 최소 권한 부여: Role과 ClusterRole 현명하게 사용하기
쿠버네티스 RBAC는 Role, ClusterRole, RoleBinding, ClusterRoleBinding 네 가지 객체로 구성되며, 권한은 오직 ‘허용(allow)’ 규칙만 누적됩니다. 따라서 권한을 최소한으로 부여하는 것이 매우 중요합니다.
RBAC 핵심 원칙: "네임스페이스에 부여할 수 있다면 반드시 RoleBinding으로!"
- Role: 특정 네임스페이스 내의 리소스에 대한 권한을 정의합니다. (예:
default네임스페이스의 Pod 목록 조회) - ClusterRole: 클러스터 전역 리소스(예: Node)나 모든 네임스페이스에 걸친 권한을 정의합니다.
- RoleBinding: Role을 특정 사용자나 그룹에 연결하여 네임스페이스 내에서 권한을 부여합니다.
- ClusterRoleBinding: ClusterRole을 클러스터 전체 범위에서 사용자나 그룹에 연결합니다.
ClusterRole과 ClusterRoleBinding은 클러스터 노드, 스토리지 관리 등 꼭 필요한 경우가 아니면 사용을 자제해야 합니다. 또한, 권한을 정의할 때 와일드카드(*) 사용은 피하는 것이 좋습니다.
Role vs. ClusterRole: 한눈에 비교하기
| 항목 | Role | ClusterRole | Namespace | Project/Folder(플랫폼) |
|---|---|---|---|---|
| 대상 | 단일 네임스페이스 | 클러스터 전체 또는 모든 네임스페이스 | 논리적 격리 경계 | 상위 조직 경계 |
| 위험도 | 낮음 | 높음 (오남용 시 클러스터 전체에 영향) | 라벨, 쿼터에 의존 | 플랫폼 구성에 의존 |
| 예외 사용 | 특정 팀/애플리케이션 | 노드/스토리지/CRD 관리 | 테넌트 경계 | 멀티 클러스터 정책 |
| 검증 | RoleBinding | (가급적 지양) ClusterRoleBinding | Quota/NetworkPolicy | Org Policy/폴더 정책 |
3. 서비스 계정 및 Secret 관리: 자동화와 보안 강화
워크로드에 부여되는 권한은 서비스 계정(ServiceAccount)을 통해 관리됩니다. 다음 절차에 따라 보안을 강화하세요.
- 기본 SA 토큰 자동 마운트 해제: 위에서 언급한 것처럼
automountServiceAccountToken: false를 기본으로 설정합니다. - 전용 SA 발급: 각 워크로드에 필요한 최소한의 기능만을 위한 전용 서비스 계정을 생성합니다.
- 최소 Role 바인딩: 생성된 서비스 계정에 꼭 필요한 권한만 담긴 Role을 RoleBinding으로 연결합니다.
- Secret 관리 강화: Secret은 민감 정보를 안전하게 관리하기 위한 쿠버네티스의 핵심 객체입니다. 따라서 Secret은 etcd에 저장 시 암호화하고, 정기적인 키 회전 및 감사 로깅을 활성화해야 합니다.
4. 네임스페이스 격리 완성하기: RBAC, 네트워크 정책, 리소스 쿼터 3종 세트
진정한 멀티테넌시 환경을 구축하려면 RBAC만으로는 부족합니다. RBAC, 네트워크 정책, 리소스 쿼터 3종 세트를 함께 적용해야 비용 효율과 보안 격리를 모두 달성할 수 있습니다.
격리 강도에 따른 구성 비교
| 구성 | 기본 차단 | 운영 난이도 | 비고 |
|---|---|---|---|
| RBAC만 | API 권한만 제한 | 낮음 | 네트워크는 모든 통신이 허용된 상태 |
| RBAC + NetworkPolicy | L3/L4 통신 제한 | 중간 | CNI 플러그인의 지원 필요 |
| + ResourceQuota | 자원 경쟁 제한 | 중간 | 예산 및 용량 통제 가능 |
5. 지속적인 보안 유지: 감사, 경고, 그리고 계정 관리
권한 설정은 일회성 작업이 아닙니다. 지속적인 관리가 필요합니다.
감사 및 경고 자동화
kube-apiserver의 감사 로깅을 활성화하여 모든 API 요청을 기록하고 분석해야 합니다. 예를 들어, "ClusterRoleBinding 생성/수정"이나 "system:masters 그룹에 사용자 추가"와 같은 민감한 이벤트가 발생하면 즉시 경고 알림을 받도록 자동화하는 것이 중요합니다. GKE 환경에서는 이를 Cloud Audit Logs와 연동할 수 있습니다. (Auditing 문서 참고)
퇴직자 및 봇 계정 권한 회수
사용하지 않는 계정은 보안 위협이 됩니다. 정기적으로 RBAC 설정을 점검하여 퇴직자 계정이나 만료된 봇(CI/CD) 계정에 연결된 RoleBinding을 제거해야 합니다. 특히, 삭제된 사용자와 동일한 이름의 사용자가 생성될 경우 과거 권한이 상속될 수 있으므로, 사용자 기반이 아닌 그룹 기반으로 권한을 관리하는 것이 더 안전합니다.
6. 정책 자동화: Gatekeeper와 Kyverno로 RBAC 규칙 강제하기
사람의 실수를 방지하고 정책을 일관되게 적용하기 위해 정책 기반 관리 도구(Policy as Code)를 활용하세요. Gatekeeper나 Kyverno를 사용하면 다음과 같은 규칙을 클러스터 전체에 강제할 수 있습니다.
- "모든 RoleBinding은 특정 네임스페이스 내에서만 허용"
- "Role/ClusterRole에서 와일드카드(
*) 동사 사용 금지" - "기본 서비스 계정 토큰 자동 마운트 금지"
실전 운영 체크리스트
- 권한 인벤토리화: 현재 부여된 모든 RoleBinding과 ClusterRoleBinding 목록을 주기적으로 검토합니다.
- 과다 권한 제거:
cluster-admin이나 불필요하게 넓은 권한을 가진 계정을 찾아 권한을 축소합니다. - 리소스 쿼터 적용: 모든 네임스페이스에 적절한 리소스 쿼터를 설정합니다.
- SA 키 회전: 서비스 계정의 토큰(Secret)을 정기적으로 회전시킵니다.
- 퇴직자/봇 계정 회수: 비활성 계정의 권한을 즉시 회수합니다.
- 감사 알림 튜닝: 중요한 보안 이벤트에 대한 알림이 제대로 동작하는지 확인하고 최적화합니다.
개념적 위험 점수 계산:
권한_위험점수 = (ClusterRole 개수 × 가중치) + (권한 범위) − (감사 빈도)
자주 묻는 질문 (FAQ)
Q1. Role과 ClusterRole 중 무엇을 선택해야 하나요?
A. 네임스페이스 내 리소스 접근은 Role과 RoleBinding을 사용하세요. 노드, PV 등 클러스터 전역 리소스나 모든 네임스페이스에 공통으로 필요한 권한만 예외적으로 ClusterRole을 사용해야 합니다. 권한은 누적되므로 항상 가장 좁은 범위에서 시작하는 것이 안전합니다. (Using RBAC Authorization 참고)
Q2. 여러 클러스터에 걸쳐 권한을 위임하려면 어떻게 해야 하나요?
A. 각 클러스터에 동일한 Role 템플릿을 배포하고, 플랫폼 레벨(예: Google Cloud의 조직/폴더 정책)에서 표준화하는 것이 좋습니다. GitOps와 정책 컨트롤러를 활용하여 일관성을 유지하고, 클러스터 범위의 바인딩은 최소화하세요. (GKE RBAC 권장사항 참고)
Q3. 네임스페이스만으로 격리가 충분한가요?
A. 아니요. 네임스페이스는 API 권한 격리의 시작점일 뿐입니다. 실제 워크로드 격리를 완성하려면 네트워크 정책(NetworkPolicy)으로 네트워크 트래픽을 제어하고, 리소스 쿼터(ResourceQuota)로 자원 경쟁을 방지해야 합니다. 이 세 가지가 함께 적용되어야 실질적인 격리 효과를 볼 수 있습니다.
Q4. RBAC 변경 사항에 대한 롤백 전략은 무엇인가요?
A. GitOps를 통해 RBAC 설정을 코드로 관리하는 것이 가장 좋습니다. 모든 변경 사항이 Git 커밋으로 기록되므로 문제 발생 시 이전 리비전으로 즉시 롤백할 수 있습니다. 또한, 변경 사항이 적용될 때 감사 로그를 모니터링하여 예상치 못한 동작을 신속하게 파악해야 합니다. (GKE 감사 로깅 정보 참고)
Q5. 네트워크 정책은 기본적으로 모든 트래픽을 차단하나요?
A. 아니요. 쿠버네티스는 기본적으로 모든 파드 간 통신을 허용합니다. 특정 파드가 네트워크 정책에 의해 ‘선택(select)’될 때부터 격리가 적용됩니다. 따라서 각 네임스페이스에 인그레스(Ingress)와 이그레스(Egress)를 모두 차단하는 기본 거부(Default Deny) 정책을 먼저 적용하고, 필요한 통신만 허용 목록에 추가하는 방식을 권장합니다.
더 읽어보기 (내부 링크)
참고 자료 (공식 문서)
면책 조항: 본 글은 일반적인 보안 가이드이며, 각 환경의 규정, 위험 평가, 감사 요구사항에 따라 세부 설정과 검증 절차가 달라질 수 있습니다. 운영 환경에 적용하기 전 충분한 테스트와 검토를 권장합니다.
