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"]
然后创建相应的 ClusterRoleBinding,以将 ClusterRole 中的权限授予相关用户(在本例中,为 us-east1-cluster-admins 安全群组的成员和 ID 为 u98523-4509823 的用户):
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 将 ClusterRole 中的权限授予 ID 为 12345678-BBBb-cCCCC-0000-123456789012 的相关群组。请注意,此设置仅与 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
[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["很难理解","hardToUnderstand","thumb-down"],["信息或示例代码不正确","incorrectInformationOrSampleCode","thumb-down"],["没有我需要的信息/示例","missingTheInformationSamplesINeed","thumb-down"],["翻译问题","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["最后更新时间 (UTC):2025-07-31。"],[],[],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."]]