Kubernetes 클러스터 보안을 위한 필수 RBAC 모범 사례

쿠버네티스는 컨테이너 오케스트레이션의 사실상 표준이 되어 조직이 전례 없는 효율성으로 애플리케이션을 배포하고 확장할 수 있도록 지원합니다. 그러나 큰 힘에는 큰 책임이 따르며, 특히 보안에 있어서는 더욱 그렇습니다. 쿠버네티스에서 가장 중요한 보안 메커니즘 중 하나는 역할 기반 액세스 제어(RBAC)로, 관리자가 클러스터 내에서 누가 무엇을 할 수 있는지 정확하게 정의할 수 있게 해줍니다.

이 글에서는 쿠버네티스 RBAC의 기본 개념을 살펴보고 프로덕션 환경을 보호하기 위한 필수적인 모범 사례를 설명합니다. 최소 권한 원칙을 시행하는 방법을 탐구하고, 잠재적인 보안 취약점을 최소화하기 위해 역할(Role) 및 클러스터 역할(ClusterRole)의 생성, 바인딩 및 세심한 관리를 안내합니다. 이러한 전략을 이해하고 적용함으로써 쿠버네티스 클러스터의 보안 상태를 크게 향상시키고 소중한 애플리케이션과 데이터를 보호할 수 있습니다.

쿠버네티스 RBAC 기본 사항 이해

쿠버네티스의 RBAC는 개별 사용자 또는 서비스 계정의 역할을 기반으로 쿠버네티스 리소스에 대한 액세스를 규제하는 권한 부여 메커니즘입니다. 이는 승인된 엔티티만이 특정 리소스에 대해 특정 작업을 수행할 수 있도록 보장하는 중요한 방어 계층입니다.

RBAC는 본질적으로 네 가지 주요 쿠버네티스 객체 유형에 의존합니다.

Role: Role은 특정 네임스페이스 내에 적용되는 권한 집합입니다. 이는 어떤 리소스(예: pods, deployments, services, secrets)에 대해 어떤 작업(예: get, list, create, update, delete와 같은 동사)을 수행할 수 있는지 정의합니다. 예를 들어, Role은 development 네임스페이스에서 pods 및 deployments를 읽을 수 있는 권한을 부여할 수 있습니다.
ClusterRole: Role과 유사하지만, ClusterRole은 클러스터 전체 또는 네임스페이스가 없는 리소스(예: nodes, persistentvolumes)에 적용되는 권한을 정의합니다. ClusterRole은 또한 모든 네임스페이스에 걸쳐 네임스페이스가 있는 리소스에 대한 권한을 정의할 수 있습니다. 예를 들어, ClusterRole은 클러스터에서 모든 nodes의 목록을 가져올 수 있습니다.
RoleBinding: RoleBinding은 Role(또는 네임스페이스에 적용되는 ClusterRole)에 정의된 권한을 사용자, 그룹 또는 서비스 계정에 부여합니다. 항상 특정 네임스페이스 내에서 작동합니다.
ClusterRoleBinding: ClusterRoleBinding은 ClusterRole에 정의된 권한을 사용자, 그룹 또는 서비스 계정에 부여하며, 해당 권한을 전체 클러스터에 적용합니다.

이러한 객체들을 함께 사용하면 관리자는 강력하고 세분화된 액세스 제어 시스템을 구축할 수 있습니다. 사용자 또는 애플리케이션(서비스 계정으로 표현됨)이 작업을 수행하려고 할 때, 쿠버네티스는 기존 RoleBindings 및 ClusterRoleBindings를 평가하여 요청된 작업이 허용되는지 여부를 결정합니다.

RBAC를 사용한 최소 권한 원칙 구현

정보 보안의 핵심 원칙은 최소 권한 원칙(PoLP)입니다. 이 원칙은 사용자, 프로그램 또는 프로세스가 작업을 수행하는 데 필요한 최소한의 권한 집합만 부여되어야 한다고 규정합니다. 쿠버네티스에서는 PoLP를 준수하는 것이 보안에 매우 중요합니다. 지나치게 허용적인 역할은 계정 하나가 손상되었을 때 의도한 것보다 훨씬 더 광범위한 액세스 권한을 부여할 수 있으므로 일반적인 공격 경로입니다.

세분화된 권한 정의

RBAC 정책을 작성할 때 필요한 정확한 작업과 리소스를 고려하십시오.

동사(Verbs): *(모든 동사)를 부여하는 대신, 필요한 정확한 작업(get, list, watch, create, update, delete, patch, exec)을 지정하십시오.
리소스(Resources): 리소스(pods, deployments, secrets, configmaps)에 대해 구체적으로 지정하십시오. 절대적으로 필요한 경우가 아니라면, 잘 정당화된 관리 역할을 제외하고는 리소스에 대한 * 액세스 부여를 피하십시오.
리소스 이름(Resource Names): secrets와 같이 매우 민감한 리소스의 경우, 리소스 유형 내에서 특정 resourceNames에 대한 액세스를 제한할 수도 있습니다.
API 그룹(API Groups): 대부분의 쿠버네티스 리소스는 API 그룹에 속합니다(예: apps, rbac.authorization.k8s.io, 핵심 리소스의 경우 ""). 범위를 더 좁히기 위해 올바른 API 그룹을 지정하십시오.

네임스페이스 범위 지정

대부분의 애플리케이션 및 개발 팀의 경우, 권한은 특정 네임스페이스로 제한되어야 합니다. 이 분리는 한 애플리케이션 또는 팀의 환경에서 발생한 침해가 자동으로 클러스터 전체 액세스로 이어지지 않도록 보장합니다. 가능하면 항상 ClusterRole 및 ClusterRoleBinding보다 Role 및 RoleBinding을 선호하십시오.

실제 RBAC 구현: 예제

RBAC 정책 생성 및 바인딩에 대한 몇 가지 실제 예제를 살펴보겠습니다.

예제 1: 특정 네임스페이스에 대한 개발자 액세스

개발자가 전용 네임스페이스인 dev-team-a에서 배포를 관리하고 로그를 볼 수 있어야 한다고 가정해 보겠습니다. 개발자는 다른 네임스페이스나 클러스터 전체 리소스에 액세스할 수 없어야 합니다.

먼저, dev-team-a 네임스페이스에서 개발자를 위한 Role을 정의합니다.

# dev-role.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: dev-team-a
  name: dev-deployer
rules:
- apiGroups: ["apps"] # Deployments용
  resources: ["deployments", "replicasets"]
  verbs: ["get", "list", "watch", "create", "update", "delete", "patch"]
- apiGroups: ["core"] # Pods 및 Pod 로그용
  resources: ["pods", "pods/log"]
  verbs: ["get", "list", "watch"]

이 역할을 적용합니다.

kubectl apply -f dev-role.yaml

다음으로, 이 Role을 dev-team-a 네임스페이스 내의 특정 사용자(예: 외부 ID 공급자를 통한 [email protected]) 또는 서비스 계정에 바인딩합니다.

# dev-role-binding.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  namespace: dev-team-a
  name: john-dev-deployer-binding
subjects:
- kind: User
  name: [email protected] # 이름은 대소문자를 구분합니다
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: dev-deployer
  apiGroup: rbac.authorization.k8s.io

이 바인딩을 적용합니다.

kubectl apply -f dev-role-binding.yaml

이제 [email protected]은 dev-team-a 네임스페이스 내에서만 배포를 관리하고 로그를 볼 수 있습니다. 예를 들어, kube-system에서 비밀 정보를 생성하거나 모든 노드의 목록을 가져올 수 없습니다.

예제 2: 비밀 정보에 액세스하는 애플리케이션 서비스 계정

ServiceAccount로 실행되는 애플리케이션이 자체 네임스페이스의 특정 비밀 정보를 읽어야 합니다.

먼저 서비스 계정이 있는지 확인하거나 생성합니다.

# app-sa.yaml
apiVersion: v1
kind: ServiceAccount
metadata:
  namespace: my-app-namespace
  name: my-app-service-account

이 서비스 계정을 적용합니다.

kubectl apply -f app-sa.yaml

다음으로, 특정 비밀 정보를 읽을 수 있도록 허용하는 Role을 정의합니다.

# secret-reader-role.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: my-app-namespace
  name: secret-reader
rules:
- apiGroups: ["core"]
  resources: ["secrets"]
  resourceNames: ["my-app-db-credentials"]
  verbs: ["get"]

이 역할을 적용합니다.

kubectl apply -f secret-reader-role.yaml

마지막으로, 이 Role을 my-app-service-account에 바인딩합니다.

# app-secret-reader-binding.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  namespace: my-app-namespace
  name: my-app-secret-reader-binding
subjects:
- kind: ServiceAccount
  name: my-app-service-account
  namespace: my-app-namespace
roleRef:
  kind: Role
  name: secret-reader
  apiGroup: rbac.authorization.k8s.io

이 바인딩을 적용합니다.

kubectl apply -f app-secret-reader-binding.yaml

애플리케이션은 이제 지정된 비밀 정보만 읽을 수 있으며 다른 것은 읽을 수 없습니다.

예제 3: 클러스터 관리자 역할 (주의 요함)

클러스터 전체 관리자 역할은 매우 신중하게 부여해야 합니다. 다음은 모니터링 도구에 필요할 수 있는 모든 노드를 나열하는 ClusterRole의 예입니다.

# node-viewer-clusterrole.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: node-viewer
rules:
- apiGroups: ["core"]
  resources: ["nodes"]
  verbs: ["get", "list", "watch"]

이 ClusterRole을 적용합니다.

kubectl apply -f node-viewer-clusterrole.yaml

그런 다음 ClusterRoleBinding을 사용하여 모니터링 서비스 계정에 바인딩합니다.

# monitoring-node-viewer-binding.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: monitoring-node-viewer-binding
subjects:
- kind: ServiceAccount
  name: monitoring-sa
  namespace: monitoring
roleRef:
  kind: ClusterRole
  name: node-viewer
  apiGroup: rbac.authorization.k8s.io

이 바인딩을 적용합니다.

kubectl apply -f monitoring-node-viewer-binding.yaml

경고: 실제 클러스터 관리자 및 특정 인프라 서비스 계정의 경우를 제외하고, 인간 사용자를 위한 ClusterRole 및 ClusterRoleBinding 사용 시 극히 주의하십시오.

필수 RBAC 모범 사례

이러한 모범 사례를 따르면 클러스터의 보안 상태가 크게 향상됩니다.

최소 권한 원칙(PoLP) 시행:
- 필요한 최소한의 권한만 부여하십시오. 모든 권한을 신중하게 검토하십시오.
- 가능하면 resources 및 verbs에 대해 와일드카드(*) 사용을 피하십시오. 사용되는 경우, 정당화하고 가능한 한 좁게 범위를 지정하도록 노력하십시오.
- 역할에서 resourceNames를 사용하여 민감한 리소스(예: secrets)에 대한 액세스를 제한하십시오.
분리를 위한 네임스페이스 사용:
- 애플리케이션과 팀을 별도의 네임스페이스로 구성하십시오.
- 이러한 네임스페이스 내에서 권한을 부여하기 위해 기본적으로 Role 및 RoleBinding을 사용하십시오.
ClusterRoles보다 Roles 선호:
- 권한이 진정으로 클러스터 전체에 필요할 때만 (nodes 관리, 사용자 정의 리소스 정의, 특정 모니터링 에이전트 등) ClusterRole 및 ClusterRoleBinding을 사용하십시오.
- 대부분의 애플리케이션별 권한은 네임스페이스화되어야 합니다.
RBAC 정책 정기 감사 및 검토:
- RBAC 정책은 시간이 지남에 따라 달라질 수 있습니다. 누가 어떤 액세스 권한을 가지고 있는지 주기적으로 검토하십시오.
- kubectl auth can-i와 같은 도구를 사용하여 특정 사용자/서비스 계정에 대한 권한을 테스트하십시오.
```bash
'[email protected]'이 'dev-team-a'에서 pod를 가져올 수 있는지 확인

kubectl auth can-i get pods --namespace=dev-team-a [email protected]

'monitoring-sa'가 노드를 나열할 수 있는지 확인 (클러스터 전체)

kubectl auth can-i list nodes --as=system:serviceaccount:monitoring:monitoring-sa
```
* 포괄적인 RBAC 감사를 위해 타사 도구나 사용자 지정 스크립트를 고려하십시오.
관리자 역할 분리:
- 개발자 또는 애플리케이션 서비스 계정에 cluster-admin 권한을 절대 부여하지 마십시오.
- 필요한 승격된 권한만 있는 특정 관리자 ClusterRoles(cluster-reader, node-reader 등)를 생성하십시오.
애플리케이션을 위한 서비스 계정 활용:
- 클러스터 내에서 실행되는 애플리케이션은 쿠버네티스 API와 상호 작용하기 위해 ServiceAccounts를 사용해야 합니다.
- 각 애플리케이션 또는 마이크로서비스는 이상적으로는 최소한의 권한을 가진 자체 전용 ServiceAccount를 가져야 합니다.
- API 액세스가 필요하지 않은 pod의 경우 automountServiceAccountToken을 false로 설정하고, 필요한 경우에만 true로 설정하여 공격 표면을 줄이십시오.
외부 ID 관리와 통합:
- 인간 사용자의 경우, 인증 및 그룹 관리를 위해 쿠버네티스를 외부 ID 공급자(예: OIDC, LDAP, Active Directory)와 통합하십시오.
- 관리를 더 쉽게 하기 위해 외부 그룹을 쿠버네티스 RoleBindings 또는 ClusterRoleBindings에 매핑하십시오.
GitOps를 사용한 RBAC 관리 자동화:
- RBAC 정책을 코드로 취급하십시오. 버전 제어된 리포지토리(Git)에 저장하십시오.
- GitOps 원칙을 사용하여 RBAC 구성을 관리하고 배포하여 일관성, 추적 가능성 및 쉬운 롤백을 보장하십시오.
감사 로그를 통한 RBAC 이벤트 모니터링:
- 쿠버네티스 감사 로깅을 활성화하고 구성하여 누가 언제 어떤 작업을 수행했는지 등 API 요청을 추적하십시오.
- RBAC와 관련된 무단 액세스 시도 또는 의심스러운 활동을 감지하기 위해 감사 로그를 정기적으로 검토하십시오.
쿠버네티스 정기 업데이트:
- RBAC 개선 사항을 포함한 보안 패치 및 개선 사항의 이점을 얻으려면 쿠버네티스 버전을 최신 상태로 유지하십시오.

일반적인 함정 및 피하는 방법

지나치게 허용적인 와일드카드: apiGroups: ["*"], resources: ["*"], 또는 verbs: ["*"]를 부여하는 것은 주요 보안 위험입니다. 항상 명시적으로 지정하십시오.
기본 cluster-admin 사용: 일상적인 작업에 system:masters 그룹 또는 cluster-admin ClusterRole을 절대 사용하지 말고, 관리자가 아닌 사용자에게 할당하지 마십시오. 이것은 전체 클러스터에 대한 백도어입니다.
automountServiceAccountToken 무시: 기본적으로 모든 pod에는 서비스 계정 토큰이 마운트됩니다. pod가 Kube API와 상호 작용할 필요가 없다면, pod 사양 또는 서비스 계정 정의에서 automountServiceAccountToken: false를 설정하여 공격 표면을 줄이십시오.
감사 부족: 정기적인 검토 없이는 클러스터 요구 사항이 발전함에 따라 RBAC 정책이 오래되거나 지나치게 허용적이 될 수 있습니다. 검토 프로세스를 구현하십시오.
Role과 ClusterRole 혼동: 범위를 잘못 이해하면 네임스페이스 액세스만 의도했던 경우 클러스터 전체 액세스를 부여하게 될 수 있습니다.

결론

쿠버네티스 클러스터를 보호하는 것은 지속적인 여정이며, RBAC는 보안 무기 체계에서 없어서는 안 될 도구입니다. 최소 권한 원칙을 성실하게 적용하고, 네임스페이스를 사용하여 액세스를 분리하고, 역할과 바인딩을 신중하게 정의하며, 엄격한 감사 프로세스를 유지함으로써 강력한 보안 기반을 구축할 수 있습니다. RBAC는 "한 번 설정하면 잊어버리는" 솔루션이 아니라, 클러스터와 애플리케이션이 발전함에 따라 지속적인 주의와 적응이 필요하다는 것을 기억하십시오. 이러한 모범 사례를 채택하여 쿠버네티스 환경이 무단 액세스 및 잠재적 위협에 대해 탄력적으로 유지되도록 하십시오.

Kubernetes 클러스터 보안을 위한 필수 RBAC 모범 사례

쿠버네티스 RBAC 기본 사항 이해

RBAC를 사용한 최소 권한 원칙 구현

세분화된 권한 정의

네임스페이스 범위 지정

실제 RBAC 구현: 예제

예제 1: 특정 네임스페이스에 대한 개발자 액세스

예제 2: 비밀 정보에 액세스하는 애플리케이션 서비스 계정

예제 3: 클러스터 관리자 역할 (주의 요함)

필수 RBAC 모범 사례

'[email protected]'이 'dev-team-a'에서 pod를 가져올 수 있는지 확인

'monitoring-sa'가 노드를 나열할 수 있는지 확인 (클러스터 전체)

일반적인 함정 및 피하는 방법

결론