인증은 인증된 사용자 및 서비스 계정에 대해 클러스터에 보다 세분화된 액세스 제어를 제공하기 위해 Kubernetes 역할 기반 액세스 제어(RBAC)와 결합되는 경우가 많습니다. 사용자 식별자 대신 그룹 이름을 사용하는 RBAC 정책을 만드는 것이 좋습니다. RBAC 정책을 그룹에 명시적으로 연결하면 ID 공급업체를 통해 사용자 액세스 권한을 완전히 관리할 수 있으므로 사용자 권한이 변경될 때마다 클러스터를 업데이트할 필요가 없습니다.
보안 그룹의 멤버십에 따라 액세스 제어를 구성하려면 그룹 멤버십 정보를 가져오도록 GKE Identity Service가 설정되어 있는지 확인해야 합니다.
예
인증된 특정 사용자가 클러스터의 포드에 액세스할 수 있도록 하려면 다음 예시와 같이 이러한 리소스에 대한 액세스 권한을 부여하는 ClusterRole을 만듭니다.
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: pod-reader
rules:
- apiGroups: [""]
# The resource type for which access is granted
resources: ["pods"]
# The permissions granted by the ClusterRole
verbs: ["get", "watch", "list"]
그런 후 관련 사용자(여기에서는 us-east1-cluster-admins 보안 그룹의 구성원과 ID u98523-4509823가 있는 사용자)에게 ClusterRole의 권한을 부여하도록 해당 ClusterRoleBinding을 만듭니다.
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: read-pods-admins
subjects:
# Grants anyone in the "us-east1-cluster-admins" group
# read access to Pods in any namespace within this cluster.
- kind: Group
name: gid-us-east1-cluster-admins # Name is case-sensitive
apiGroup: rbac.authorization.k8s.io
# Grants this specific user read access to Pods in any
# namespace within this cluster
- kind: User
name: uid-u98523-4509823
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole
name: pod-reader
apiGroup: rbac.authorization.k8s.io
다음 예시에서 ClusterRoleBinding은 ID가 12345678-BBBb-cCCCC-0000-123456789012인 관련 그룹에 ClusterRole 권한을 부여합니다. 이 설정은 Azure AD 제공업체에만 관련되며 Google Distributed Cloud 클러스터에서 사용할 수 있습니다.
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: pod-reader-binding
subjects:
# Retrieves group information for the group ID mentioned
- kind: Group
name: 12345678-BBBb-cCCCC-0000-123456789012
apiGroup: rbac.authorization.k8s.io
Google Cloud 콘솔에서 클러스터 리소스에 액세스하려는 인증된 사용자는 관련 Kubernetes 권한이 있어야 액세스할 수 있습니다. 이러한 사용자에게 클러스터 관리자와 같은 더 광범위한 권한을 부여하지 않으려면 클러스터의 노드, 영구 볼륨, 포드, 스토리지 클래스를 볼 수 있는 최소 권한이 포함된 커스텀 RBAC 역할을 만들면 됩니다. 클러스터에 ClusterRoleRBAC 리소스, cloud-console-reader를 만들어 이 권한 집합을 정의할 수 있습니다.
cloud-console-reader는 사용자에게 클러스터의 노드, 영구 볼륨, 포드, 스토리지 클래스에 대한 get, list, watch 권한을 부여하여 관련 리소스에 대한 세부정보를 볼 수 있게 합니다.
kubectl
cloud-console-readerClusterRole을 만들고 이를 클러스터에 적용하려면 다음 명령어를 실행합니다.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["이해하기 어려움","hardToUnderstand","thumb-down"],["잘못된 정보 또는 샘플 코드","incorrectInformationOrSampleCode","thumb-down"],["필요한 정보/샘플이 없음","missingTheInformationSamplesINeed","thumb-down"],["번역 문제","translationIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2025-09-04(UTC)"],[],[],null,["# Set up role-based access control (RBAC)\n=======================================\n\nAuthentication is often combined with [Kubernetes role-based access control (RBAC)](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) to provide more finely grained access control to clusters for authenticated users and service accounts. It is recommended to create RBAC policies that use group names instead of user identifiers. By linking your RBAC policies explicitly to groups, you can manage user access privileges entirely with your identity provider, so the cluster doesn't need to be updated every time user privileges change.\nNote that to configure access control based on membership of security groups with OIDC, you must ensure that GKE Identity Service is set up to support getting group membership information from your identity provider.\n\nExample\n-------\n\nIf you want certain authenticated users to have access to the cluster's [Pods](https://kubernetes.io/docs/concepts/workloads/pods/), create a `ClusterRole` that grants access to these resources, as in the following example: \n\n```\napiVersion: rbac.authorization.k8s.io/v1\nkind: ClusterRole\nmetadata:\n name: pod-reader\nrules:\n- apiGroups: [\"\"]\n # The resource type for which access is granted\n resources: [\"pods\"]\n # The permissions granted by the ClusterRole\n verbs: [\"get\", \"watch\", \"list\"]\n```\n\nYou then create a corresponding `ClusterRoleBinding` to grant the permissions in the `ClusterRole` to the relevant users---in this case, members of the `us-east1-cluster-admins` security group and the user with ID `u98523-4509823`: \n\n```\napiVersion: rbac.authorization.k8s.io/v1\nkind: ClusterRoleBinding\nmetadata:\n name: read-pods-admins\nsubjects:\n # Grants anyone in the \"us-east1-cluster-admins\" group\n # read access to Pods in any namespace within this cluster.\n- kind: Group\n name: gid-us-east1-cluster-admins # Name is case-sensitive\n apiGroup: rbac.authorization.k8s.io\n # Grants this specific user read access to Pods in any\n # namespace within this cluster\n- kind: User\n name: uid-u98523-4509823\n apiGroup: rbac.authorization.k8s.io\nroleRef:\n kind: ClusterRole\n name: pod-reader\n apiGroup: rbac.authorization.k8s.io\n```\n| **Note:** If your identity provider returns a group name that contains double backslash characters, then one of the backslash characters should be omitted when you reference the group name in the `ClusterRoleBinding` resource. For example, if you have created a group named `corp\\\\my-group`, reference it in the `ClusterRoleBinding` resource as `corp\\my-group`. This is because the first backslash character is treated as an escape character.\n\nIn the following example, this `ClusterRoleBinding` grants permissions in the `ClusterRole` to the relevant group with ID `12345678-BBBb-cCCCC-0000-123456789012`. Note that this setting is relevant only for Azure AD providers and is available for Google Distributed Cloud clusters. \n\n```\napiVersion: rbac.authorization.k8s.io/v1\nkind: ClusterRoleBinding\nmetadata:\n name: pod-reader-binding\nsubjects:\n # Retrieves group information for the group ID mentioned\n- kind: Group\n name: 12345678-BBBb-cCCCC-0000-123456789012\n apiGroup: rbac.authorization.k8s.io\n```\n\n\u003cbr /\u003e\n\nFor more information about using RBAC, see [Configure role-based access control](/kubernetes-engine/docs/how-to/role-based-access-control) and [Using RBAC Authorization](https://kubernetes.io/docs/reference/access-authn-authz/rbac/).\n\nCreate an RBAC role for Google Cloud console access\n---------------------------------------------------\n\nUsers authenticated using OIDC providers can [log in to clusters from the Google Cloud console](/kubernetes-engine/fleet-management/docs/console) as well as the command line.\n\nAuthenticated users who want to access a cluster's resources in the Google Cloud console\nneed to have the relevant Kubernetes permissions to do so. If you don't want to grant those users more extensive permissions, such as those of a cluster admin, you can create a custom RBAC role that includes the minimum permissions to view the cluster's nodes, persistent volumes, pods, and storage classes. You can define this set of\npermissions by creating a `ClusterRole` [RBAC](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#user-facing-roles) resource,\n`cloud-console-reader`, in the cluster.\n\n`cloud-console-reader` grants its users the `get`, `list`, and `watch`\npermissions on the cluster's nodes, persistent volumes, pods and storage classes,\nwhich allow them to see details about these resources. \n\n### kubectl\n\nTo create the `cloud-console-reader` `ClusterRole` and apply it to the cluster, run the\nfollowing command: \n\n cat \u003c\u003cEOF \u003e cloud-console-reader.yaml\n kind: ClusterRole\n apiVersion: rbac.authorization.k8s.io/v1\n metadata:\n name: cloud-console-reader\n rules:\n - apiGroups: [\"\"]\n resources: [\"nodes\", \"persistentvolumes\", \"pods\"]\n verbs: [\"get\", \"list\", \"watch\"]\n - apiGroups: [\"storage.k8s.io\"]\n resources: [\"storageclasses\"]\n verbs: [\"get\", \"list\", \"watch\"]\n EOF\n kubectl apply -f cloud-console-reader.yaml\n\nYou can then grant this `ClusterRole` to users when setting up your permission policies, as described in the previous section. Note that users also need [IAM permissions](/kubernetes-engine/fleet-management/docs/console#required_roles) to view clusters in the Google Cloud console."]]