在用户集群上配置 OIDC 身份验证

本页面适用于平台管理员。

本页面介绍如何在用户集群上启用 OpenID Connect (OIDC) 身份验证以及如何设置基于角色的访问权限控制 (RBAC)。如需详细了解如何使用 OIDC 进行身份验证，请参阅在裸机上的 Anthos 集群中使用 OIDC 进行身份管理。

在用户集群上启用 OIDC 身份验证

您可以在用户集群创建期间或在现有用户集群上启用 OIDC 身份验证。设置 OIDC 身份验证的前提条件是，要应用于集群的身份配置文件已存在。请参阅创建身份配置文件。

在集群创建期间设置身份配置文件

如需了解如何使用 Anthos Management Center Console 创建用户集群，请参阅创建用户集群。在集群配置页面上，从 AIS 配置下拉列表中选择用于创建用户集群的身份配置文件。这些身份配置文件将应用于用户集群。

在集群创建期间应用身份配置文件

在现有用户集群上设置身份配置文件

转到身份和访问权限页面
点击将配置文件应用于集群。
从配置文件下拉列表中选择要应用的身份配置文件。
从集群下拉列表中选择要应用身份配置文件的集群。

查看已应用到用户集群的身份配置文件

您可以从身份和访问权限页面查看应用于用户集群的身份配置文件。

选择集群标签页，找到要查看的用户集群，然后点击该用户集群的查看配置详细信息。

查看用户集群身份配置

下载用户集群登录配置

在查看配置详情滑动页面上，点击下载登录配置。

通过文件指定 OIDC 配置

创建一个包含以下内容的文件。将此文件另存为 user-cluster-oidc-config.yaml：

spec:
  authentication:
  - name: CONFIGURATION_NAME
    oidc:
      clientID: CLIENT_ID
      clientSecret: CLIENT_SECRET
      # The URI to redirect users going through the OAuth flow using cloud
      # console.
      # This is a required parameter not supported by Anthos private mode, so
      # a dummy value is required.
      cloudConsoleRedirectURI: http://cloud.console.not.enabled
      extraParams: EXTRA_PARAMS
      issuerURI: ISSUER_URI
      # The redirect URL that kubectl uses for authorization.
      kubectlRedirectURI: http://localhost:9879/callback
      scopes: SCOPES
      userClaim: USER_CLAIM
      groupsClaim: GROUPS_CLAIM
      certificateAuthorityData: CERT_AUTHORITY_DATA

请替换以下内容：

CONFIGURATION_NAME：要创建的 OIDC 配置的名称。
CLIENT_ID：向 OpenID 提供方发出身份验证请求的客户端应用的 ID。
CLIENT_SECRET：客户端应用的密钥。
EXTRA_PARAMS：要发送到 OpenID 提供方的额外键值对参数（以英文逗号分隔）。
ISSUER_URI：向您的 OpenID 发送授权请求的网址。
SCOPES：要发送到 OpenID 提供方的其他范围（以英文逗号分隔）。
USER_CLAIM：用作用户名的 JWT 声明。您可以选择其他声明，例如电子邮件或名称，具体取决于 OpenID 提供方。不过，电子邮件以外的声明会以颁发者网址作为前缀，以防止命名冲突。
GROUPS_CLAIM：包含用户群组信息的 OIDC ID 令牌中的声明名称。
CERT_AUTHORITY_DATA：OIDC 提供方的可选 base64 编码的 PEM 编码证书。如果不需要，请将其移除。要创建字符串，请将证书（包括标头）进行 base64 编码。将生成的字符串作为单独的一行添加到 certificateAuthorityData 中。

使用所需配置修改文件后，运行以下命令：

kubectl patch --kubeconfig=USER_CLUSTER_KUBECONFIG clientconfig default -n kube-public \
  --type=merge --patch "$(cat OIDC_CONFIG)"

请替换以下内容：

USER_CLUSTER_KUBECONFIG：用户集群 Kubeconfig 文件的路径。
OIDC_CONFIG：您创建的配置文件的路径。

在用户集群上设置 RBAC

本部分介绍如何设置 RBAC 以授予对各个命名空间的访问权限。如需了解更深入的信息，请参阅 Kubernetes RBAC 文档。

假设有两个命名空间，即 workload-a 和 workload-b。其目标是使命名空间 workload-a 中的资源可供用户 alice@example.com 读写，workload-b 可供用户 bob@example.com 写入。alice@example.com 无法访问 workload-b，bob@example.com 无法访问 workload-a。

在用户集群中创建命名空间：

kubectl --kubeconfig=USER_CLUSTER_KUBECONFIG create namespace workload-a
kubectl --kubeconfig=USER_CLUSTER_KUBECONFIG create namespace workload-b

要限制对每个命名空间的访问，必须定义每个命名空间的权限。在 Kubernetes 中，这可以通过创建角色来实现。

kubectl --kubeconfig=USER_CLUSTER_KUBECONFIG apply -f - <<EOF
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: workload-a
  name: a-full-access
rules:
- apiGroups: [""] # Indicates the core API group.
  resources: ["*"] # This is a wildcard representing all resource types.
  verbs: ["get", "watch", "list", "create", "update", "patch", "delete"]
EOF

为 foo-full-access 定义的 verbs 定义了此角色可以在命名空间中执行的所有操作。

kubectl --kubeconfig=USER_CLUSTER_KUBECONFIG apply -f - <<EOF
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: workload-b
  name: b-read-access
rules:
- apiGroups: [""] # Indicates the core API group.
  resources: ["*"] # This is a wildcard representing all resource types.
  verbs: ["get", "watch", "list"]
EOF

对于 b-read-access，定义的动词仅允许角色查询资源。

要向用户授予权限，必须创建 RoleBinding。RoleBinding 可以包括个人用户和群组。本示例展示的是个人用户。

kubectl --kubeconfig=USER_CLUSTER_KUBECONFIG apply -f - <<EOF
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: a-full-access-users
  namespace: workload-a
subjects:
# You can specify more than one subject
- kind: User
  # Using the userClaim 'email' in this example.
  # If the user prefix is 'prefix-', then prefix the username with the user
  # user prefix.
  name: prefix-alice@example.com # Replace this with an actual user.
  apiGroup: rbac.authorization.k8s.io
roleRef:
  # "roleRef" specifies the binding to a Role / ClusterRole
  kind: Role # This must be Role or ClusterRole.
  name: a-full-access # This must match the name of the Role you wish to bind.
  apiGroup: rbac.authorization.k8s.io
EOF

上述 RoleBinding (a-full-access-users) 会授予用户 alice@example.com 在 a-full-access 角色中定义的权限。这意味着用户 alice@example.com 能够读取和写入 workload-a 命名空间中的资源。

kubectl --kubeconfig=USER_CLUSTER_KUBECONFIG apply -f - <<EOF
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: b-read-access-users
  namespace: workload-b
subjects:
# You can specify more than one subject
- kind: User
  # Using the userClaim 'email' in this example.
  # If the user prefix is 'prefix-', then prefix the username with the user
  # user prefix.
  name: bob@example.com # Replace this with an actual user.
  apiGroup: rbac.authorization.k8s.io
roleRef:
  # "roleRef" specifies the binding to a Role / ClusterRole
  kind: Role # This must be Role or ClusterRole.
  name: b-read-access # This must match the name of the Role you wish to bind.
  apiGroup: rbac.authorization.k8s.io
EOF

此 RoleBinding (b-read-access-users) 授予用户 bob@example.com 在 b-read-access 角色中定义的权限。因此，用户 bob@example.com 只能读取 workload-b 命名空间中的资源。

使用 OIDC 提供方登录

作为用户集群的管理员，获取供用户集群的所有用户用来登录的登录配置文件：请参阅下载用户集群登录配置文件，从 Anthos Management Center 获取登录配置。或者，您可以通过执行以下命令来创建登录配置文件：

actl auth create-login-config --kubeconfig=USER_CLUSTER_KUBECONFIG \
  --output=USER_CLUSTER_NAME-actl-auth-login-config.yaml

将 USER_CLUSTER_NAME-actl-auth-login-config.yaml 分发给用户集群的用户。

向 OIDC 提供方进行身份验证，然后按照命令行中的说明操作：

actl auth login --login-config=USER_CLUSTER_NAME-actl-auth-login-config.yaml \
  --cluster=USER_CLUSTER_NAME --kubeconfig=./USER_CLUSTER_NAME-cluster-oidc-kubeconfig \
  --preferred-auth="CONFIGURATION_NAME"

将 USER_CLUSTER_NAME 替换为管理控制台中显示的用户集群的名称。--kubeconfig=USER_CLUSTER_NAME-cluster-oidc-kubeconfig 是输出 Kubeconfig 文件名。将 CONFIGURATION_NAME 替换为要进行身份验证的身份个人资料名称。打开 USER_CLUSTER_NAME-actl-auth-login-config.yaml 以查看个人资料名称。

使用带有 kubectl 的新 Kubeconfig，如下所示：

kubectl --kubeconfig=./USER_CLUSTER_NAME-cluster-oidc-kubeconfig get pods -A

后续步骤

详细了解如何查看审核日志。