为 Anthos Identity Service 设置用户访问权限

本文档适用于已按照为舰队级 GKE Identity Service 配置集群或使用 OIDC 为 GKE Identity Service 配置集群中的说明为 GKE Identity Service 配置集群的集群管理员。本文档介绍如何为组织的开发者和其他集群用户设置（和限制）对已配置集群的访问权限。

设置用户登录权限

配置集群后，您需要生成登录配置文件并将其分发给集群用户。此文件允许用户使用所选的提供商从命令行登录集群，如使用 GKE Identity Service 访问集群中所述。

在仅使用 OIDC 提供商时，用户还可以在没有登录文件的情况下从 Google Cloud 控制台登录集群，如使用 Google Cloud 控制台中的集群所述。

生成登录配置

控制台

（仅限舰队级设置）

复制显示的 gcloud 命令并运行该命令来生成此文件。

gcloud

如果您使用 gcloud CLI 配置了集群，或者需要再次生成该文件，请运行以下命令来生成该文件：

gcloud anthos create-login-config --kubeconfig=KUBECONFIG

其中，KUBECONFIG 是集群的 kubeconfig 文件的路径。如果 kubeconfig 中有多个上下文，则会使用当前上下文。运行该命令之前，您可能需要将当前上下文重置为正确的集群。

您可以在 Google Cloud CLI 参考指南中查看此命令的完整参考文档的详细信息，包括其他可选参数。

登录配置文件的默认名称为 kubectl-anthos-config.yaml，这是 Google Cloud CLI 使用该文件登录时的名称。如果您想将其更改为非默认名称，请参阅下面的分发登录配置中的相关部分。

如需排查与用户访问权限相关的问题，请参阅排查用户访问权限问题。

分发登录配置

以下是分发配置文件的一些方法：

将文件托管在可访问的网址。用户可以在运行 gcloud anthos auth login 时使用 --login-config 标志指定此位置，从而允许 Google Cloud CLI 获取该文件。

考虑将文件托管在安全主机上。如需详细了解如何使用 PEM 证书进行安全 HTTPS 访问，请参阅 gcloud CLI 的 --login-config-cert 标志。
手动为每个用户提供文件，并提供将文件保存到本地机器的位置信息（Google Cloud CLI 应能在特定于操作系统的默认位置找到该文件）。如果文件具有非默认名称或位置，则在对集群运行命令时，用户必须使用 --login-config 标志来指定配置文件位置。有关用户如何保存文件的说明，请参阅使用 GKE Identity Service 访问集群。
使用内部工具将身份验证配置文件推送到每个用户的机器上。Google Cloud CLI 会在以下位置找到该文件，具体取决于用户操作系统：
Linux
```
$HOME/.config/google/anthos/kubectl-anthos-config.yaml
```
macOS
```
$HOME/Library/Preferences/google/anthos/kubectl-anthos-config.yaml
```
Windows
```
%APPDATA%\google\anthos\kubectl-anthos-config.yaml
```

通过备用身份验证流程设置用户登录访问权限

您可以使用备用身份验证流程来设置用户登录访问权限，而不是将配置文件分发给所有用户。用户可以使用完全限定域名 (FQDN) 直接在 GKE Identity Service 服务器上进行身份验证。对于 SAML 提供方，只有通过此备用身份验证流程才支持用户登录访问权限。

与用户共享 FQDN

集群管理员可以与用户共享其 GKE Identity Service 服务器的 FQDN，而不是共享配置文件。用户可以使用此 FQDN 登录集群。GKE Identity Service 服务器网址采用以下格式之一提供：

https://CLUSTER-SERVER-NAME.com
CLUSTER-SERVER-NAME.com

使用受信任的 SNI 证书实现用户登录访问权限

SNI 证书利用公司设备上已有的受信任证书来简化集群访问权限。管理员会在创建集群时使用此证书。作为用户，您需要使用管理员提供的 FQDN 登录集群。或者，您也可以使用安全的 kubeconfig 文件，在身份验证成功后，令牌会存储在该文件中。

在运行以下命令之前，请确保完成了用户登录活动的设备信任 GKE Identity Service 服务器使用的证书。

gcloud anthos auth login --server APISERVER_URL --kubeconfig OUTPUT_FILE

替换以下内容：

APISERVER_URL：GKE Identity Service 服务器的 FQDN。
OUTPUT_FILE：如果 kubeconfig 文件位于默认位置之外的其他位置，请使用此标志。如果省略此标志，则身份验证令牌会添加到默认位置的 kubeconfig 文件中。例如：--kubeconfig /path/to/custom.kubeconfig。

使用集群 CA 颁发的证书实现用户登录访问权限

作为用户，如果您未在集群级层使用受信任的 SNI 证书，则身份服务使用的证书由集群的证书授权机构 (CA) 颁发。管理员会将此 CA 证书分发给用户。使用集群的 CA 证书运行以下命令来登录集群：

gcloud anthos auth login --server APISERVER_URL --kubeconfig OUTPUT_FILE --login-config-cert CLUSTER_CA_CERTIFICATE

设置基于角色的访问权限控制 (RBAC)

身份验证通常与 Kubernetes 基于角色的访问权限控制 (RBAC) 结合使用，从而为经过身份验证的用户和服务账号提供针对集群的更精细的访问权限控制。我们建议您尽可能创建使用群组名称（而不是用户标识符）的 RBAC 政策。通过将 RBAC 政策明确关联到群组，您可以完全通过身份提供商管理用户访问权限，这样在用户权限更改时就不需要更新集群。请注意，如需使用 OIDC 根据安全群组的成员资格配置访问权限控制，您必须确保 GKE Identity Service 已设置为支持从身份提供商获取群组成员资格信息。

例如，如果您希望某些经过身份验证的用户有权访问集群的 Pod，请创建一个 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"]

然后创建相应的 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 Virtual for Bare Metal 集群。

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

如需详细了解如何使用 RBAC，请参阅配置基于角色的访问控制和使用 RBAC 授权。

创建 RBAC 角色以提供 Google Cloud 控制台访问权限

使用 OIDC 提供商进行身份验证的用户可以从 Google Cloud 控制台以及命令行登录集群。

想要在 Google Cloud 控制台中访问集群资源并且经过身份验证的用户需要具备相关的 Kubernetes 权限。如果您不想向这些用户授予更广泛的权限（例如集群管理员的权限），则可以创建一个包含查看集群节点、永久性卷、pod 和存储类别的最低权限的自定义 RBAC 角色。您可以通过在集群中创建 ClusterRole RBAC 资源 cloud-console-reader 来定义这组权限。

cloud-console-reader 会向用户授予针对集群的节点、永久性卷、pod 和存储类别的 get、list 和 watch 权限，从而允许他们查看这些资源的详细信息。

kubectl

要创建 cloud-console-reader ClusterRole 并将其应用于集群，请运行以下命令：

cat <<EOF > cloud-console-reader.yaml
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: cloud-console-reader
rules:
- apiGroups: [""]
  resources: ["nodes", "persistentvolumes", "pods"]
  verbs: ["get", "list", "watch"]
- apiGroups: ["storage.k8s.io"]
  resources: ["storageclasses"]
  verbs: ["get", "list", "watch"]
EOF
kubectl apply -f cloud-console-reader.yaml

然后，您可以在设置权限政策时向用户授予此 ClusterRole，如上一部分所述。请注意，用户还需要 IAM 权限才能在 Google Cloud 控制台中查看集群。