역할 기반 액세스 제어

이 페이지에서는 Kubernetes에서 제공하는 역할 기반 액세스 제어(RBAC) 시스템을 간략하게 설명하고 Google Kubernetes Engine에서 Kubernetes RBAC를 사용하는 방법을 설명합니다.

개요

Kubernetes에는 역할 기반 액세스 제어(RBAC) 메커니즘을 기본 제공하므로 특정 Google Cloud 사용자 또는 사용자 그룹이 클러스터의 Kubernetes 객체 또는 클러스터의 특정 네임스페이스와 상호작용하는 방식을 정의하는 권한 집합을 세밀하고 구체적으로 구성할 수 있습니다.

Kubernetes RBAC는 기본적으로 사용 설정되어 있습니다.

시작하기 전에

이 작업을 준비하려면 다음 단계를 완료하세요.

  • Google Kubernetes Engine API가 사용 설정되었는지 확인합니다.
  • Google Kubernetes Engine API 사용 설정
  • Cloud SDK가 설치되었는지 확인합니다.
  • 기본 프로젝트 ID를 설정합니다.
    gcloud config set project [PROJECT_ID]
  • 영역 클러스터를 사용하는 경우 기본 컴퓨팅 영역을 설정합니다.
    gcloud config set compute/zone [COMPUTE_ZONE]
  • 리전 클러스터를 사용하는 경우 기본 컴퓨팅 리전을 설정합니다.
    gcloud config set compute/region [COMPUTE_REGION]
  • gcloud를 최신 버전으로 업데이트합니다.
    gcloud components update

Identity and Access Management와 상호작용

Cloud Identity and Access Management Kubernetes RBAC를 모두 사용하여 GKE 클러스터에 대한 액세스를 제어할 수 있습니다.

  • Cloud IAM은 Kubernetes로 국한되지 않고 여러 Google Cloud 제품의 ID를 관리하며 주로 Google Cloud 프로젝트 수준에서 작동합니다.

  • Kubernetes RBAC는 Kubernetes의 핵심 구성요소로서 클러스터에 속한 객체 또는 객체 유형에 대한 역할(권한 집합)을 만들고 부여할 수 있습니다.

GKE에서는 Cloud IAM과 Kubernetes RBAC가 서로 연동하여 사용자의 작업 수행을 승인합니다. 사용자는 두 도구 중 한 도구에서만 충분한 권한을 가지고 있으면 됩니다. 기본적으로 Google Cloud 사용자에게는 Kubernetes RBAC RoleBindings가 없으므로 GKE 클러스터를 준비하는 과정에서 이는 중요 부분을 차지합니다.

Google Cloud 계정을 통해 사용자를 승인하려면 먼저 해당 계정으로 인증하도록 클라이언트를 올바르게 구성해야 합니다. 예를 들어 kubectl을 사용하는 경우 승인이 필요한 명령어를 실행하기 전에 Google Cloud를 인증하도록 kubectl 명령어를 구성해야 합니다.

GKE 클러스터 v1.11.x 이하 버전에서 Kubernetes RBAC를 사용하기 위한 기본 요건

GKE v1.11.x 이하를 사용하는 GKE 클러스터에서는 Cloud IAM이 Kubernetes RBAC Role 또는 ClusterRole을 만들 수 있는 권한을 부여하지 못합니다. 그러나 Kubernetes Engine 관리자 Cloud IAM 역할은 사용자에게 자신을 포함한 사용자의 Kubernetes RBAC RoleBinding 또는 ClusterRoleBinding을 만들 수 있는 권한을 부여합니다. 이를 통해 Google Cloud 사용자를 사전 정의된 RBAC Role에 결합할 수 있습니다.

특히 사전 정의된 RBAC 역할인 cluster-admin은 사용자에게 클러스터의 전체 권한을 부여합니다. 따라서 사용자가 RBAC Role과 ClusterRole을 만들 수 있도록 준비하려면 다음 명령어를 실행합니다. 이 때 [USER_ACCOUNT]를 대상 사용자의 Google Cloud 로그인 이메일 주소로 바꿉니다.

kubectl create clusterrolebinding cluster-admin-binding \
  --clusterrole cluster-admin \
  --user [USER_ACCOUNT]

GKE용 Google 그룹스

이전에는 Google Cloud 사용자 계정 또는 Cloud IAM 서비스 계정에만 역할을 부여할 수 있었습니다. GKE용 Google 그룹스(베타)를 사용하면 G Suite Google 그룹의 구성원에게 역할을 부여할 수 있습니다. 이 메커니즘을 채택하면 G Suite 관리자가 Kubernetes 또는 Cloud Console과 전혀 무관한 외부에서 사용자와 그룹을 관리하게 되므로 클러스터 관리자가 사용자 정보를 자세하게 알고 있을 필요가 없습니다. 또 다른 이점은 기존의 사용자 계정 관리 업무와 통합하여 조직을 떠나는 사용자의 액세스를 취소하는 등의 조치를 취할 수 있다는 점입니다.

이 기능을 사용하려면 G Suite Google 그룹스를 구성하고 이 기능이 사용 설정된 클러스터를 만든 후 Google 그룹스에 클러스터 권한 집합을 연결합니다.

RBAC와 함께 사용하도록 Google 그룹스 구성

이 기능을 사용하도록 클러스터를 구성하는 방법 및 Kubernetes RBAC에서 G Suite Google 그룹을 참조하는 구문은 이 항목의 뒷부분에서 설명합니다. 우선 다음 단계를 수행하여 Google 그룹스를 설정해야 합니다.

  1. 도메인에 G Suite Google 그룹을 만들고 이름을 gke-security-groups@[yourdomain.com]으로 지정합니다. 그룹 이름이 정확히 gke-security-groups여야 합니다.
  2. 클러스터에서 서로 다른 권한을 가져야 하는 사용자 또는 그룹을 나타내는 그룹이 아직 없으면 그룹을 만듭니다.
  3. 사용자가 아닌 그룹을 gke-security-groups@[yourdomain.com]에 구성원으로 추가합니다.

GKE는 특정 사용자가 그룹 멤버십에 따라 클러스터의 리소스를 생성, 수정 또는 조회할 수 있는 권한이 있는지 확인하기 위해 사용자가 액세스 권한이 있는 그룹의 구성원인지 그리고 해당 그룹이 도메인의 gke-security-groups 그룹에 속하는지 확인합니다.

G Suite Google 그룹 멤버십에 대한 정보는 잠시 동안 캐시됩니다. 그룹 멤버십의 변경사항이 모든 클러스터에 전파되기까지 몇 분 정도 걸릴 수 있습니다.

GKE용 Google 그룹스를 사용하도록 클러스터 구성

G Suite Google 그룹스 관리자가 그룹을 설정하면 gcloud 명령어를 사용하여 새 클러스터를 만들고 --security-group="gke-security-groups@[yourdomain.com]" 옵션을 자신의 도메인 이름으로 바꿔 추가합니다. 다음은 클러스터 생성 명령어의 예시입니다.

gcloud beta container clusters create my-cluster \
  --security-group="gke-security-groups@[yourdomain.com]"

이제 G Suite Google 그룹스를 참조하는 Role, ClusterRole, RoleBinding, ClusterRoleBinding을 만들 준비가 되었습니다.

권한 정의 및 할당

RBAC 권한을 정의하려면 다음 유형의 Kubernetes 객체를 만듭니다.

  • ClusterRole 또는 Role: 클러스터(ClusterRole) 또는 네임스페이스(Role)의 사용자나 사용자 그룹에 할당할 수 있는 리소스 유형과 작업의 집합을 정의합니다. 사용자나 사용자 그룹을 지정하지는 않습니다.
  • ClusterRoleBinding 또는 RoleBinding: 사용자나 사용자 그룹에 ClusterRole 또는 Role을 할당합니다. ClusterRoleBinding은 ClusterRole과, RoleBinding은 ClusterRole 또는 Role과 연동합니다.

RBAC 권한은 완전히 가산적이며 '거부' 규칙이 없습니다. RBAC 역할 구조를 만들 때는 클러스터 리소스에 대한 액세스 권한을 사용자에게 '부여'하는 방식을 취해야 합니다.

Role 또는 ClusterRole을 사용하여 권한 정의

Role 또는 ClusterRole 객체 내에 권한을 정의합니다. Role은 단일 네임스페이스에 포함된 리소스에 대한 액세스를 정의하고, ClusterRole은 전체 클러스터의 리소스에 대한 액세스를 정의합니다.

Role과 ClusterRole의 구문은 동일합니다. 각각 rules 섹션이 있습니다. 여기에서 관련 네임스페이스, 리소스 유형, 역할에 허용되는 작업을 정의합니다. 예를 들어 다음 Role은 accounting 네임스페이스의 모든 Pod에 대한 읽기 액세스 권한(get, watch, list)을 부여합니다.

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  namespace: accounting
  name: pod-reader
rules:
- apiGroups: [""] # "" indicates the core API group
  resources: ["pods"]
  verbs: ["get", "watch", "list"]

RoleClusterRole 비교

ClusterRole에서 부여하는 권한은 전체 클러스터에 적용되므로 ClusterRole을 사용하면 Role을 사용할 때보다 더욱 다양한 리소스에 대한 액세스를 제어할 수 있습니다. 예를 들면 다음과 같습니다.

  • 노드와 같은 클러스터 범위의 리소스
  • /healthz와 같은 리소스 이외의 엔드포인트
  • 모든 네임스페이스 간의 네임스페이스로 지정된 리소스(예: 네임스페이스에 관계없이 전체 클러스터 간 모든 Pod)

RoleBinding 또는 ClusterRoleBinding을 사용하여 역할 할당

Role 또는 ClusterRole을 만든 후 RoleBinding 또는 ClusterRoleBinding을 만들어 사용자나 사용자 그룹에 할당합니다. 사용자 및 그룹을 subjects라 하며 다음과 같은 유형일 수 있습니다.

주체 유형 kind name
Google Cloud 사용자 계정 User Google Cloud에 등록된 이메일 주소
Kubernetes 서비스 계정 ServiceAccount 클러스터의 Kubernetes ServiceAccount 객체 이름
Cloud IAM 서비스 계정 User 자동으로 생성된 Cloud IAM 서비스 계정 이메일 주소
확인된 도메인의 G Suite Google 그룹 주소(베타) Group 자체적으로 Google 그룹 gke-security-groups@[yourdomain.com]에 속하는 Google 그룹의 이메일 주소

다음 RoleBinding은 사용자, Kubernetes 서비스 계정, Cloud IAM 서비스 계정, Google 그룹에 pod-reader 역할을 부여합니다.

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: pod-reader-binding
  namespace: accounting
subjects:
# Google Cloud user account
- kind: User
  name: janedoe@example.com
# Kubernetes service account
- kind: ServiceAccount
  name: johndoe
# Cloud IAM service account
- kind: User
  name: test-account@test-project-123456.google.com.iam.gserviceaccount.com
# G Suite Google Group
- kind: Group
  name: accounting-group@example.com
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

API 사용 및 예시

Kubernetes API를 사용하여 RBAC에 필요한 Role, ClusterRole, RoleBinding, ClusterRoleBinding 객체를 만드는 방법에 대한 자세한 내용은 Kubernetes 문서의 역할 기반 액세스 제어 승인 사용을 참조하세요.

주의사항

다음 섹션에서는 Kubernetes RBAC를 다룰 때 간과하기 쉬운 상호작용에 대해 설명합니다.

기본 검색 역할

클러스터는 기본 ClusterRole 및 ClusterRoleBinding 집합과 함께 생성됩니다. 유효한 사용자 인증 정보로 수행된 요청은 system:authenticated 그룹에 배치되고, 다른 모든 요청은 system:unauthenticated에 배치됩니다. Kubernetes 버전 1.14가 출시되기 전까지는 system:authenticatedsystem:unauthenticated 모두 기본적으로 system:basic-usersystem:discovery ClusterRole을 부여합니다.

system:basic-user ClusterRole은 사용자가 SelfSubjectAccessReviews를 만들어 클러스터에서 자신의 권한을 테스트하도록 허용합니다. system:discovery 역할은 사용자가 클러스터에 추가된 CustomResourceDefinitions 정보를 표시할 수 있는 검색 API를 읽도록 허용합니다.

Kubernetes 1.14에서는 익명 사용자(system:unauthenticated)에게 system:basic-info-viewer ClusterRole을 대신 적용하므로 /healthz/version API에 대한 읽기 전용 액세스 권한이 부여됩니다.

system:discovery ClusterRole에서 허용되는 API 엔드포인트를 확인하려면 다음 명령어를 실행합니다.

kubectl get clusterroles system:discovery -o yaml

Google Cloud VM 인스턴스의 서비스 계정에 발생한 Forbidden 오류

VM 인스턴스에 userinfo-email 범위가 없으면 이 오류가 발생할 수 있습니다. 예를 들어 VM에 클라우드 플랫폼 범위는 있지만 userinfo-email 범위가 없다고 가정합니다. VM이 액세스 토큰을 가져오면 Google Cloud는 이 토큰을 cloud-platform 범위와 연결합니다. Kubernetes API 서버가 액세스 토큰과 연결된 ID를 Google Cloud에 요청하면 서비스 계정의 이메일이 아닌 서비스 계정의 고유 ID가 수신됩니다.

성공적으로 인증하려면 userinfo-email 범위로 새 VM을 만들거나 고유 ID를 사용하는 새 역할 결합을 만듭니다.

userinfo-email 범위로 새 VM을 만들려면 다음 명령어를 실행합니다.

gcloud compute instances create [INSTANCE_NAME] \
    --service-account [SERVICE_ACCOUNT_EMAIL] \
    --scopes userinfo-email

기존 VM에 서비스 계정의 고유 ID를 사용하는 새 역할 결합을 만들려면 다음 단계를 따르세요.

  1. 서비스 계정의 고유 ID를 확인합니다.

    gcloud iam service-accounts describe [SERVICE_ACCOUNT_EMAIL]
    
  2. 고유 ID를 사용하여 역할 결합을 만듭니다.

    kubectl create clusterrolebinding [CLUSTERROLEBINDING_NAME] \
      --clusterrole cluster-admin \
      --user [UNIQUE_ID]
    

다음 단계

이 페이지가 도움이 되었나요? 평가를 부탁드립니다.

다음에 대한 의견 보내기...

Kubernetes Engine 문서