승인 역할 구성

승인 역할

Anthos 비공개 모드에는 사전 설정된 승인 역할 4개가 제공됩니다.

역할 이름 Kubernetes ClusterRole 이름(관리자 클러스터) 권한
인프라 운영자 cluster-admin 모든 리소스에 대한 전체 읽기 및 쓰기 액세스 권한
인프라 운영자(읽기 전용) 보기 역할, 역할 결합, 보안 비밀을 제외한 관리 센터의 대부분의 항목에 대한 읽기 전용 액세스 권한

사용자는 현재 Grafana에 대한 쓰기 액세스 권한을 통해 대시보드를 수정할 수 있습니다.

플랫폼 관리자 anthos-platform-admin
  • 사용자 클러스터, Anthos 기능 관리, Anthos Identity Service, Anthos Config Management에 대한 읽기 및 쓰기 액세스 권한
  • 머신에 대한 읽기 및 삭제 액세스 권한
  • 부트스트랩 서비스에 대한 읽기 전용 액세스 권한
플랫폼 관리자

(읽기 전용)

anthos-platform-admin-read-only 플랫폼 관리자가 볼 수 있는 모든 항목에 대한 읽기 전용 액세스 권한

사용자는 현재 Grafana에 대한 쓰기 액세스 권한을 통해 대시보드를 수정할 수 있습니다.

ADMIN_KUBECONFIG에 대한 액세스 권한이 있는 모든 사용자는 Kubernetes API 서버에 대한 모든 작업을 허용하는 Kubernetes system:master 그룹의 구성원으로 인증됩니다. 예를 들어 다음을 실행하여 모든 보안 비밀을 나열할 수 있습니다.

kubectl get secrets --all-namespaces --kubeconfig=${ADMIN_KUBECONFIG}

ADMIN_KUBECONFIG를 사용한 액세스는 일반 사용자 이름 admin으로 인증되므로 명령어를 실행하는 사람을 추적하기가 어렵습니다. 따라서 ADMIN_KUBECONFIG를 안전한 장소에 보관하고 필요한 경우에만(예: 초기 플랫폼 연산자 역할 결합을 설정할 때나 OIDC 오류에서 복구할 때) 사용하세요.

중요: 사용자 및 그룹에 system: 프리픽스가 붙어있지 않은지 확인하세요. system: 프리픽스는 Kubernetes 시스템용으로 예약되어 있습니다.

웹 콘솔 및 측정항목 액세스

Anthos 비공개 모드는 이러한 역할 4개에 결합된 모든 사용자를 관리 센터 및 측정항목(Grafana) 액세스 허용 목록에 자동으로 동기화합니다.

읽기 전용 액세스 권한이 있는 역할이 관리 센터에서 쓰기 작업을 수행하려고 하면 거부됩니다.

역할 바인딩

웹 콘솔에서 OIDC를 설정할 때 플랫폼 관리자 역할에 binding된 초기 사용자를 설정할 수 있습니다. 초기 플랫폼 관리자 사용자에 대해 로그인된 kubeconfig에는 다른 사용자를 플랫폼 관리자 역할에 binding하기 위한 2가지 접근 방법이 있습니다.

이 접근 방법은 그룹 중 하나를 사전 설정된 역할에 binding하여 해당 그룹의 모든 구성원에게 사전 설정된 역할과 동일한 액세스 권한을 부여합니다.

시작하기 전에 다음 항목을 확인하세요.

  • 그룹이 시작된 OIDC 제공업체를 확인합니다.
  • 'OIDC 프로필' 탭의 '그룹 클레임' 필드는 OIDC 제공업체 측의 그룹 멤버십 정보를 포함하는 클레임 이름과 동일해야 합니다. Anthos 비공개 모드는 여기에 기본값 groups를 지정하지만, OIDC 제공업체에 다른 값이 포함된 경우, 'OIDC 프로필' 탭에서 이를 설정했는지 확인해야 합니다.
  • 'OIDC 프로필' 탭에서 '그룹 프리픽스'를 기록해 둡니다. 모든 그룹 이름 앞에 그룹 프리픽스를 포함해야 합니다. 예를 들어 그룹 프리픽스로 gid-가 사용되고 OIDC 제공업체에 'admin-group' 그룹이 있으면 gid-admin-group을 사용해야 합니다. - 구분 기호는 그룹 프리픽스의 일부이며, 시스템이 구분 기호를 추가하지 않습니다.

관리 센터 UI에서 액세스 관리 탭을 사용하여 그룹을 기준으로 역할 바인딩을 관리할 수 있습니다. 클러스터 만들기 중 ID 프로필 적용

현재 로그인된 계정보다 많은 권한을 갖는 역할로 binding을 업데이트하거나 추가할 수 없습니다. 예를 들어 플랫폼 관리자로 로그인되어 있으면 그룹을 인프라 운영자 역할에 binding할 수 없습니다.

또는 다음 명령어를 실행하여 그룹을 기준으로 역할 바인딩을 만듭니다. group=에 전달되는 값은 그룹 프리픽스가 추가된 OIDC 제공업체의 그룹 이름과 동일해야 합니다.

kubectl create clusterrolebinding anthos-platform-admin-group-binding \
--kubeconfig=${ADMIN_OIDC_KUBECONFIG} --clusterrole=anthos-platform-admin \
--group=gid-anthos-platform-admin-group

이제 OIDC 제공업체의 anthos-platform-admin-group에 추가된 모든 사용자에게 플랫폼 관리자 권한이 있습니다.

마찬가지로 다음 명령어를 사용하여 그룹을 플랫폼 관리자(읽기 전용) 역할에 binding할 수 있습니다.

kubectl create clusterrolebinding anthos-platform-admin-read-only-group-binding \
  --kubeconfig=${ADMIN_OIDC_KUBECONFIG} --clusterrole=anthos-platform-admin-read-only \
  --group=gid-anthos-platform-admin-read-only-group

권한 에스컬레이션을 방지하기 위해 플랫폼 관리자는 그룹을 인프라 운영자 또는 인프라 운영자(읽기 전용) 역할에 binding할 수 없습니다. 인프라 운영자의 첫 번째 그룹을 초기화하려면 ADMIN-KUBECONFIG가 필요합니다.

kubectl create clusterrolebinding anthos-platform-operator-group-binding \
  --kubeconfig=${ADMIN_KUBECONFIG} --clusterrole=cluster-admin --group=gid-anthos-platform-operator-group

그런 후 로그인된 인프라 운영자 계정에 KUBECONFIG를 사용하여 다른 그룹을 모든 역할에 binding할 수 있습니다.

# Bind a group to Infrastructure Operator (Read Only):
kubectl create clusterrolebinding anthos-platform-operator-read-only-binding \
  --clusterrole=view --group=gid-anthos-platform-operator-read-only-group --kubeconfig=${ADMIN_OIDC_KUBECONFIG}

접근 방법 II: 사용자를 기준으로 역할 바인딩 만들기

사용자 역할을 기준으로 역할 결합을 만들 수도 있습니다. 역할 결합을 만드는 명령어는 그룹을 사용하는 것과 비슷합니다. --group을 --user로 바꿔야 합니다.

또한 OIDC 프로필의 사용자 프리픽스를 모든 사용자 이름에 추가해야 합니다. 예를 들어 OIDC 제공업체가 사용자 프리픽스 uid-를 갖도록 설정되었고 joedoe@example.com을 역할에 binding하려면 uid-joedoe@example.com을 사용합니다.

또한 액세스 관리 탭을 사용하여 사용자에 대한 역할 바인딩을 관리할 수 있습니다.

다음은 charlie@example.com에 대한 역할 바인딩을 만들고 플랫폼 관리자 권한을 부여하는 샘플 명령어입니다.

kubectl create clusterrolebinding charlie-platform-admin-binding \
  --clusterrole=anthos-platform-admin --user=uid-charlie@example.com --kubeconfig=${ADMIN_OIDC_KUBECONFIG}

하나의 역할 바인딩을 삭제하여 사용자의 액세스 권한을 삭제하려면 해당 binding을 삭제하는 대신 기존 binding을 업데이트할 수 있습니다(예: charlie@example.com의 플랫폼 관리자 취소).

kubectl patch clusterrolebinding charlie-platform-admin-binding \
  -p '{"subjects":[]}' --kubeconfig=${ADMIN_OIDC_KUBECONFIG}

인프라 운영자에게 ClusterRoleBinding을 삭제하도록 요청할 수도 있습니다.

권장사항: Kubernetes는 액세스 권한이 적은 사용자가 더 많은 액세스 권한을 가진 사용자의 binding을 삭제하지 못하도록 하므로 ClusterRoleBinding에 대한 삭제 권한이 플랫폼 관리자에게 부여되지 않습니다. 해당 그룹에서 사용자를 삭제할 수 있으므로 OIDC 공급자의 그룹을 사용하여 사용자를 관리하는 것이 좋습니다.

참고

  • 자세한 내용은 공식 설명서의 역할 기반 액세스 제어(RBAC)에서 확인할 수 있습니다.
  • 사용자 클러스터에는 사전 설정된 승인 역할이 설정되지 않았습니다. 각 사용자 클러스터 액세스의 Kubernetes API 서버 액세스는 kubeconfig가 있는 모든 사용자에게 공개됩니다.
  • 플랫폼 관리자는 플랫폼 관리자가 더 높은 권한이 있는 사용자의 역할 결합을 삭제하지 못하도록 역할 결합을 삭제할 수 없습니다. 사용자의 액세스 권한을 취소하려면 사용자를 빈 제목 목록에 binding하는 역할 바인딩을 업데이트하면 됩니다. 액세스 관리 UI의 삭제 작업은 또한 동일한 이유로 인해 binding을 삭제하는 대신 역할 바인딩을 빈 제목 목록으로 업데이트합니다.
  • ClusterRoleBinding의 이름은 고유해야 합니다. 같은 이름의 클러스터 역할 바인딩이 여러 개 있으면 마지막으로 적용하거나 만든 항목만 적용됩니다.

각 사전 설정된 역할에 대한 Kubernetes 리소스 액세스 권한

이 섹션에서는 각 사전 설정된 역할에 대한 모든 Kubernetes 리소스 액세스 권한의 세부정보를 제공합니다.

인프라 운영자

인프라 운영자는 모든 리소스에 대해 모든 동사를 수행할 수 있는 Kubernetes 기본 제공 cluster-admin 역할에 해당합니다.

인프라 운영자(읽기 전용)

인프라 운영자(읽기 전용)는 Role, ClusterRole, RoleBinding, ClusterRoleBinding, Secret을 제외하고 모든 리소스를 읽을 수 있는 k8s 기본 제공 view 역할에 해당합니다.

사용자 클러스터 kubeconfig와 같은 많은 유용한 정보가 Secrets로 저장되기 때문에 인프라 운영자(읽기 전용)가 완전히 작동하지 않습니다.

플랫폼 관리자

플랫폼 관리자는 다음과 같은 액세스 권한을 가질 수 있습니다.

리소스 동사
namespaces get, list, watch, create, update
pods get, list, watch
services get, list, watch
events get, list, watch
configmaps get, list, watch
deployments get, list, watch
daemonsets get, list, watch
replicasets get, list, watch
statefulsets get, list, watch
jobs get, list, watch
cronjobs get, list, watch
memberships.managementcenter.anthos.cloud.google.com get, list, watch, create, update, delete
onpremuserclusters.managementcenter.anthos.cloud.google.com get, list, watch, create, update, delete
clusters.baremetal.cluster.gke.io get, list, watch, create
nodepools.baremetal.cluster.gke.io get, list, watch, create
clusters.cluster.x-k8s.io get, list, watch
machines.baremetal.cluster.gke.io get, list, watch
inventorymachines.baremetal.cluster.gke.io get, list, watch
addresspools.managementcenter.anthos.cloud.google.com get, list, watch
bootstrapservicebindings.managementcenter.anthos.cloud.google.com get, list, watch, create, update, delete
bootstrapservices.managementcenter.anthos.cloud.google.com get, list, watch
bootstrapservicebindingitems.managementcenter.anthos.cloud.google.com get, list, watch
adminoperators.managementcenter.anthos.cloud.google.com get, list, watch
clientconfigs.authentication.gke.io get, list, watch, create, update, delete
configmanagementbindings.managementcenter.anthos.cloud.google.com get, list, watch, create, update, delete
configmanagementfeaturespecs.managementcenter.anthos.cloud.google.com get, list, watch, create, update, delete
configmanagementbindingitems.managementcenter.anthos.cloud.google.com get, list, watch, create, update, delete
servicemeshbindings.managementcenter.anthos.cloud.google.com get, list, watch, create, update, delete
servicemeshfeaturespecs.managementcenter.anthos.cloud.google.com get, list, watch, create, update, delete
servicemeshbindingitems.managementcenter.anthos.cloud.google.com get, list, watch, create, update, delete
identityservicebindings.managementcenter.anthos.cloud.google.com get, list, watch, create, update, delete
identityservicefeaturespecs.managementcenter.anthos.cloud.google.com get, list, watch, create, update, delete
identityservicebindingitems.managementcenter.anthos.cloud.google.com get, list, watch, create, update, delete
updatablecomponents.managementcenter.anthos.cloud.google.com get, list, watch
domainidpmappings.managementcenter.anthos.cloud.google.com get, list, watch, create, update, delete
domainidpmappings.managementcenter.anthos.cloud.google.com get, list, watch, create, update, delete
logmons.addons.gke.io get, list, watch, create, update, delete
clusterrolebindings.rbac.authorization.k8s.io get, list, watch, create, update

플랫폼 관리자는 또한 사용자 클러스터에 cluster-admin 역할로 인증된 사용자가 kubeconfig를 얻을 수 있도록 secrets에 대한 읽기 액세스 권한을 갖습니다.

플랫폼 관리자는 또한 Logmon 구성을 위해 kube-system에서 logmon 라벨로 secrets 및 configmaps를 읽고 쓸 수 있습니다.

플랫폼 관리자(읽기 전용)

플랫폼 관리자(읽기 전용)는 다음을 제외하고 플랫폼 관리자와 동일한 액세스 권한을 갖습니다.

  • 모든 쓰기 관련 동사(create, update, delete)는 부여되지 않습니다.
  • 사용자 클러스터에 대한 액세스를 위해 플랫폼 관리자(읽기 전용)는 사용자 클러스터에서 view 역할로 인증된 kubeconfig만 읽을 수 있습니다.