本文档中介绍的产品 Anthos Clusters on AWS（上一代）现已进入维护模式。所有新安装都必须使用当前世代产品 Anthos clusters on AWS。

向 OpenID Connect (OIDC) 进行身份验证

了解如何配置 Anthos clusters on AWS (GKE on AWS)，以使用 OpenID Connect (OIDC) 对用户集群进行身份验证。本主题介绍了使用任何 OpenID 提供方配置 Anthos clusters on AWS (GKE on AWS) 的过程。

如需将使用 OIDC 身份验证的集群升级到 Kubernetes 1.21，请参阅升级到 1.21。

如需大致了解 Anthos clusters on AWS 身份验证流程，请参阅身份验证。

概览

Anthos clusters on AWS 支持将 OIDC 用作与用户集群的 Kubernetes API 服务器进行交互的身份验证机制之一。借助 OIDC，您可以按照组织中创建、启用和停用用户帐号的标准程序来管理对 Kubernetes 集群的访问权限。

准备工作

本主题假定您熟悉以下身份验证和 OpenID 概念：
每个开发者的本地机器都必须安装 Google Cloud CLI。
不支持无头系统。要进行身份验证，您必须在运行 gcloud CLI 的本地机器上打开浏览器。然后，浏览器会提示您授权您的用户帐号。
如需通过 Google Cloud Console 进行身份验证，您要配置进行 OIDC 身份验证的每个集群都必须向 Google Cloud 注册。

角色

本主题涉及三个角色：

组织管理员：此角色选择 OpenID 提供方，并向提供方注册客户端应用。
集群管理员：此角色创建一个或多个用户集群，并为使用这些集群的开发者创建身份验证配置文件。
开发者：此角色在一个或多个集群上运行工作负载，并使用 OIDC 进行身份验证。

选择 OpenID 提供方

本部分面向组织管理员。

您可以选择使用任何 OpenID 提供方。如需查看经过认证的提供方列表，请参阅 OpenID 认证。

创建重定向网址

本部分面向组织管理员。

OpenID 提供商使用重定向网址返回 ID 令牌。您必须为 gcloud CLI 和 Google Cloud 控制台创建重定向网址。

设置 gcloud CLI 重定向网址

配置 OpenID 提供方时，将您的 CLI 重定向网址指定为 http://localhost:PORT/callback。

将 PORT 替换为大于 1024 的端口号。

设置 Google Cloud 控制台重定向网址

Google Cloud 控制台的重定向网址为：

https://console.cloud.google.com/kubernetes/oidc

配置 OIDC 提供商时，请将 https://console.cloud.google.com/kubernetes/oidc 指定为其中一个重定向网址。

向 OpenID 提供方注册您的客户端应用

本部分面向组织管理员。

您需要先向 OpenID 提供商注册 Google Cloud CLI 和 Google Cloud 控制台，您的开发者才能将这两个客户端用于您的 OpenID 提供商。注册包括以下步骤：

了解提供方的颁发者 URI。gcloud CLI 或 Google Cloud 控制台会向此 URI 发送身份验证请求。
使用 gcloud CLI 的重定向网址（包括端口号）配置您的提供方。
使用 Google Cloud 控制台的重定向网址 https://console.cloud.google.com/kubernetes/oidc 配置您的提供方。
创建一个客户端 ID，供提供方用于标识 Google Cloud CLI 和 Google Cloud 控制台。
创建一个客户端密钥，供 gcloud CLI 和 Google Cloud 控制台用于向 OpenID 提供方进行身份验证。
创建一个自定义范围，供 gcloud CLI 或 Google Cloud 控制台用于请求用户的安全群组。
创建自定义声明名称，供提供方用于返回用户的安全组。

配置集群

本部分面向集群管理员。

如需配置 OIDC 身份验证，您需要使用集群的身份验证详细信息来配置用户集群的 AWSCluster 资源。AWSCluster 中的详细信息用于为 Google Cloud 控制台和适用于 Anthos 的身份验证插件配置 OIDC。配置包括以下 OIDC 信息：

authentication:
  awsIAM:
    adminIdentityARNs:
      - AWS_IAM_ARN
  oidc:
  -   certificateAuthorityData: CERTIFICATE_STRING
      clientID: CLIENT_ID
      clientSecret: CLIENT_SECRET
      extraParams:  EXTRA_PARAMS
      groupsClaim:  GROUPS_CLAIM
      groupPrefix:  GROUP_PREFIX
      issuerURI:  ISSUER_URI
      kubectlRedirectURI:  KUBECTL_REDIRECT_URI
      scopes:  SCOPES
      userClaim:  USER_CLAIM
      userPrefix:  USER_PREFIX

身份验证字段

下表介绍了 authentication.awsIAM.adminIdentityARNs 对象的字段。

下表介绍了 oidc 对象的字段。

字段	必填	说明	格式
adminIdentityARNs	是（如果配置 OIDC）。	被 Anthos clusters on AWS 授予集群管理员访问权限的 AWS IAM 身份（用户或角色）的 Amazon 资源名称 (ARN)。示例：`arn:aws:iam::123456789012:group/Developers`	字符串

字段	必填	说明	格式
certificateAuthorityData	否	OIDC 提供方的 base64 编码的 PEM 编码证书。要创建字符串，请将证书（包括标头）进行 base64 编码。将生成的字符串作为单独的一行添加到 `certificateAuthorityData` 中。示例：`certificateAuthorityData: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tC...k1JSUN2RENDQWFT==`	字符串
clientID	是	向 OpenID 提供方发出身份验证请求的客户端应用的 ID。	字符串
clientSecret	否	OIDC 客户端应用和 OIDC 提供方之间的共享密钥令牌。	字符串
extraParams	否	要发送到 OpenID 提供方的其他键值对参数。如果您要向群组授权，请传入 `resource=token-groups-claim`。如果您的授权服务器提示是否同意，则对于使用 Microsoft Azure 和 Okta 进行的身份验证，请将 `extraParams` 设置为 `prompt=consent`。对于 Cloud Identity，请将 `extraParams` 设置为 `prompt=consent,access_type=offline`。	英文逗号分隔列表
groupsClaim	否	提供方用于返回安全组的 JWT 声明。	字符串
groupPrefix	否	附加到群组声明前面的前缀，以防止与现有名称冲突。例如，如果您有两个名为 `foobar` 的组，添加前缀 `gid-`，则结果组为 `gid-foobar`。	字符串
issuerURI	是	用于向 OpenID 发送授权请求的网址，例如 `https://example.com/adfs`。Kubernetes API 服务器使用此网址来发现用于验证令牌的公钥。URI 必须使用 HTTPS。	网址字符串
kubectlRedirectURI	是	用于授权的重定向网址“kubectl”。	网址字符串
scopes	是	要发送到 OpenID 提供方的其他范围。Microsoft Azure 和 Okta 需要 `offline_access` 范围。	英文逗号分隔列表
userClaim	否	用作用户名的 JWT 声明。您可以选择其他声明，例如电子邮件或名称，具体取决于 OpenID 提供方。不过，电子邮件以外的声明会以颁发者网址作为前缀，以防止命名冲突。	字符串
userPrefix	否	附加到用户名声明前面的前缀，以防止与现有名称冲突。	字符串

示例：向用户和群组授权

许多提供方在令牌中对用户标识属性（例如电子邮件和用户 ID）进行编码。但是，对于身份验证政策来说，这些属性具有潜在的风险：

用户 ID 可能会导致政策难以阅读和审核。
使用电子邮件地址可能会产生可用性风险（如果用户更改了主电子邮件地址）和安全风险（如果可以重新分配电子邮件地址）。

我们建议使用群组政策，而不是分配用户 ID，因为群组政策可以是永久性的且更易于审核。

假设您的提供方创建了包含以下字段的身份令牌：

{
  'iss': 'https://server.example.com'
  'sub': 'u98523-4509823'
  'groupList': ['developers@example.corp', 'us-east1-cluster-admins@example.corp']
  ...
}

根据此令牌格式，您可以按如下方式填充配置文件的 oidc 规范：

issuerURL: 'https://server.example.com'
username: 'sub'
usernamePrefix: 'uid-'
group: 'groupList'
groupPrefix: 'gid-'
extraParams: 'resource=token-groups-claim'
...

创建用户集群后，您可以使用 Kubernetes 基于角色的访问权限控制 (RBAC) 向经过身份验证的用户授予具有特权的访问权限。

在以下示例中，您可以创建一个 ClusterRole，向其用户授予对集群 Secret 的只读权限，并创建 ClusterRoleBinding 资源以将角色绑定到经过身份验证的群组。

定义 ClusterRole。将以下 YAML 复制到名为 secret-reader-role.yaml 的文件中。

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: secret-reader
rules:
- apiGroups: [""]
  # The resource type for which access is granted
  resources: ["secrets"]
  # The permissions granted by the ClusterRole
  verbs: ["get", "watch", "list"]

定义 ClusterRoleBinding。将以下 YAML 复制到名为 secret-reader-admins.yaml 的文件中。

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: read-secrets-admins
subjects:
  # Allows anyone in the "us-east1-cluster-admins" group to
  # read Secrets in any namespace within this cluster.
- kind: Group
  name: gid-us-east1-cluster-admins # Name is case sensitive
  apiGroup: rbac.authorization.k8s.io
  # Allows this specific user to read Secrets in any
  # namespace within this cluster
- kind: User
  name: uid-u98523-4509823
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: secret-reader
  apiGroup: rbac.authorization.k8s.io

使用 kubectl 将 secret-reader-role.yaml 和 secret-reader-admins.yaml 应用于您的集群。
```
env HTTPS_PROXY=http://localhost:8118 \
  kubectl apply -f secret-reader-role.yaml && \
  kubectl apply -f secret-reader-admins.yaml
```
在 read-secrets-admins 中获授予访问权限的用户现在可以读取集群中的 Secret。

创建登录配置

本部分面向集群管理员。

创建用户集群后，您需要使用 gcloud anthos create-login-config 为集群生成配置文件。

在 anthos-aws 目录中，使用 anthos-gke 将上下文切换到用户集群。
```
cd anthos-aws
env HTTPS_PROXY=http://localhost:8118 \
  anthos-gke aws clusters get-credentials CLUSTER_NAME
```
将 CLUSTER_NAME 替换为用户集群名称。
使用 gcloud anthos 创建配置。
```
gcloud anthos create-login-config --kubeconfig usercluster-kubeconfig
```
将 usercluster-kubeconfig 替换为用户集群的 kubeconfig 文件的路径。在 Linux 和 macOS 上，此文件默认位于 ~/.kube/config。

此命令会生成一个文件 (kubectl-anthos-config.yaml)，其中包含您的开发者将用于通过 gcloud CLI 向集群进行身份验证的配置信息。您不应修改此文件。

如需详细了解 kubectl-anthos-config.yaml 的内容，请参阅附录。

将配置文件分发给需要向用户集群进行身份验证的用户。您可以通过以下方式分发配置：

将文件放在默认目录中。
安全地分发文件。
在 HTTPS 服务器上托管文件。

登录配置默认目录

用于存储每个操作系统的配置文件的默认位置如下所示：

Linux: $HOME/.config/google/anthos/kubectl-anthos-config.yaml，其中 $HOME 是用户的主目录。
macOS: $HOME/Library/Preferences/google/anthos/kubectl-anthos-config.yaml，其中 $HOME 是用户的主目录。
Windows: %APPDATA%/google/anthos/kubectl-anthos-config.yaml，其中 %APPDATA% 是用户的应用数据目录。

分发登录配置后，您的开发者就可以配置 gcloud CLI 来访问集群了。

升级到 Kubernetes 1.21 后修改集群

将集群升级到 Kubernetes 1.21 后，您需要配置 Anthos Identity Service 并从集群的配置中移除 OIDC 信息。如需更新配置，请执行以下步骤：

按照升级集群中的步骤操作。
在 anthos-aws 目录中，使用 anthos-gke 将上下文切换到用户集群。
```
cd anthos-aws
env HTTPS_PROXY=http://localhost:8118 \
  anthos-gke aws clusters get-credentials CLUSTER_NAME
```
将 CLUSTER_NAME 替换为用户集群名称。
在文本编辑器中打开包含 AWSCluster 的清单。使文件保持打开状态，并使用 oidc 对象的值按照为 Anthos Identity Service 配置集群中的步骤执行操作。
在 anthos-aws 目录中，使用 anthos-gke 将上下文切换到管理服务。
```
cd anthos-aws
anthos-gke aws management get-credentials
```
注意：anthos-gke 会使用您在运行 aws configure 时指定的凭据。
在文本编辑器中打开创建 AWSCluster 的 YAML 文件。如果您没有初始 YAML 文件，则可以使用 kubectl edit。
修改 YAML
如果您按照创建用户集群中的说明操作，则 YAML 文件名为 cluster-0.yaml。在文本编辑器中打开此文件。
kubectl 修改
如需使用 kubectl edit 修改 AWSCluster，请运行以下命令：
```
env HTTPS_PROXY=http://localhost:8118 \
  kubectl edit awscluster cluster-name
```
将 cluster-name 替换为您的 AWSCluster。例如，要修改默认集群 cluster-0，请运行以下命令：
```
env HTTPS_PROXY=http://localhost:8118 \
  kubectl edit awscluster cluster-0
```
从集群的清单中删除 oidc 对象。
保存文件。如果您使用 kubectl edit，kubectl 会自动应用更改。如果您要修改 YAML 文件，请使用以下命令将其应用于您的管理服务：
```
env HTTPS_PROXY=http://localhost:8118 \
  kubectl apply -f cluster-0.yaml
```
然后，管理服务会更新您的 AWSCluster。

配置 gcloud 以访问您的集群

本部分面向开发者或集群管理员。

前提条件

如需完成此部分，您必须完成以下步骤：

登录配置。

包含 anthos-auth 组件的 gcloud CLI 的更新版本。

gcloud components update
gcloud components install anthos-auth

通过运行以下命令来验证 gcloud CLI 是否已成功安装，该命令应提供有关所需参数和可用选项的详细信息作为响应。
```
gcloud anthos auth
```

向您的集群进行身份验证

您可以通过以下方式向集群进行身份验证：

在本地机器上使用 gcloud CLI。
在使用 SSH 隧道的远程机器上使用 gcloud CLI。
在 Google Cloud Console 中使用 Connect。

gcloud 本地

使用 gcloud anthos auth login，通过您的登录配置向集群进行身份验证。

如果您已将登录配置放在默认位置中，并配置集群名称，则可以在没有指定选项的情况下使用 gcloud anthos auth login。您还可以使用可选参数来配置集群、用户和其他身份验证详细信息。

默认

gcloud anthos auth login --cluster CLUSTER_NAME

将 CLUSTER_NAME 替换为完全限定的集群名称。例如，projects/my-gcp-project/locations/global/memberships/cluster-0-0123456a。

可选参数

gcloud anthos auth login 支持以下可选参数：

gcloud anthos auth login --cluster CLUSTER_NAME \
--user USERNAME --login-config ANTHOS_CONFIG_YAML \
--login-config-cert LOGIN_CONFIG_CERT_PEM \
--kubeconfig=KUBECONFIG --dry-run

下表介绍了这些参数。

参数	说明
`cluster`	需要向其进行身份验证的集群的名称。默认值为“kubectl-anthos-config.yaml”中的集群。
`user`	`kubeconfig` 中的凭据的用户名。默认值为 `{cluster-name}-anthos-default-user`。
`login-config`	集群管理员为开发者生成的配置文件的路径，或者托管该文件的网址。默认值为 `kubectl-anthos-config.yaml`。
`login-config-cert`	如果使用 `login-config` 的网址，则为用于建立 HTTPS 连接的 CA 证书文件的路径。
`kubeconfig`	包含令牌的 kubeconfig 文件的路径。默认值为 $HOME/.kube/config`。
dry-run	测试您的命令行选项，而无需更改配置或集群。

gcloud anthos login 命令会启动一个浏览器，要求用户使用其企业凭据登录，执行 OIDC 凭据交换，并获取相关令牌。然后，gcloud CLI 会将令牌写入 kubeconfig 文件。kubectl 使用此文件向用户集群进行身份验证。

如需验证身份验证是否成功，请使用您的 kubeconfig 文件运行任意 kubectl 命令：

env HTTPS_PROXY=http://localhost:8118 \
  kubectl get nodes --kubeconfig my.kubeconfig

gcloud 隧道

如果要从远程机器向用户集群进行身份验证，您可以使用 SSH 隧道执行身份验证。要使用隧道，您的身份验证配置文件必须位于远程机器上，并且您必须能够从本地机器访问 OpenID 提供方。

在本地机器上，运行以下命令：

ssh USERNAME@REMOTE_MACHINE -L LOCAL_PORT:localhost:REMOTE_PORT

替换以下内容：

将 USERNAME 替换为对远程机器具有 SSH 访问权限的用户。
将 REMOTE_MACHINE 替换为远程机器的主机名或 IP 地址。
LOCAL_PORT 是本地机器上的可用端口，供 ssh 用于通过隧道连接到远程机器。
REMOTE_PORT 是您为 OIDC 重定向网址配置的端口。端口号是身份验证配置文件的 kubectlRedirectURI 字段的一部分。

在 SSH Shell 中，运行以下命令以启动身份验证：

gcloud anthos auth login --login-config AUTH_CONFIG_FILE

将 AUTH_CONFIG_FILE 替换为远程计算机上身份验证配置文件的路径。gcloud CLI 在远程机器上运行网络服务器。

在本地机器上的浏览器中，转到 http://localhost:LOCAL_PORT/login 并完成 OIDC 登录流程。

现在，远程计算机上的 kubeconfig 文件包含用于访问用户集群的令牌。

在 SSH Shell 中，验证您是否有权访问用户集群：

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get nodes

控制台

您可以向 Google Cloud 控制台进行身份验证，从 Google Cloud 控制台中的 Kubernetes 集群页面启动身份验证流程：

打开 Google Cloud 控制台：

访问 Kubernetes 集群页面
在列表中找到 Anthos clusters on AWS，然后点击登录。
选择使用为集群配置的身份提供商服务执行身份验证，然后点击登录。

系统会将您重定向到您的身份提供方，您可能需要登录或同意 Google Cloud 控制台访问您的帐号。然后，您会被重定向回 Google Cloud 控制台中的 Kubernetes 集群页面。

更新 OIDC 配置

如需更新集群上的 OIDC 配置，请使用 kubectl edit 命令。

env HTTPS_PROXY=http://localhost:8118 \
  kubectl edit clientconfigs -n kube-public default

kubectl 工具会在默认编辑器中加载 ClientConfig 资源。要更新配置，请保存文件。kubectl 工具会更新集群上的 ClientConfig 资源。

如需了解 ClientConfig 资源的内容，请参阅以下部分。

附录：登录配置示例

示例 kubectl-anthos-config.yaml 如下：提供本示例是为了便于理解其内容。您应始终使用 gcloud anthos create-login-config 生成该文件。

apiVersion: authentication.gke.io/v2alpha1
kind: ClientConfig
metadata:
 name: default
 namespace: kube-public
spec:
  authentication:
  - name: oidc
    oidc:
      clientID: CLIENT_CONFIG
      clientSecret: CLIENT_SECRET
      extraParams: resource=k8s-group-claim,domain_hint=consumers
      certificateAuthorityData:   CERTIFICATE_STRING
      issuerURI: https://adfs.contoso.com/adfs
      kubectlRedirectURI: http://redirect.kubectl.com/
      scopes: allatclaim,group
      userClaim: "sub"
      groupsClaim: "groups"
    proxy: PROXY_URL #Optional
  certificateAuthorityData: CERTIFICATE_AUTHORITY_DATA
  name: projects/my-project/locations/global/membership/cluster-0
  server: https://192.168.0.1:PORT
  preferredAuthentication: oidc

如需了解字段内容的说明，请参阅身份验证字段。

后续步骤

在 Anthos clusters on AWS 上部署您的第一个工作负载。

向 OpenID Connect (OIDC) 进行身份验证

概览

准备工作

角色

选择 OpenID 提供方

创建重定向网址

设置 gcloud CLI 重定向网址

设置 Google Cloud 控制台重定向网址

向 OpenID 提供方注册您的客户端应用

配置集群

身份验证字段

示例：向用户和群组授权

创建登录配置

分发登录配置

登录配置默认目录

升级到 Kubernetes 1.21 后修改集群

修改 YAML

kubectl 修改

配置 gcloud 以访问您的集群

前提条件

向您的集群进行身份验证

gcloud 本地

默认

可选参数

gcloud 隧道

控制台

更新 OIDC 配置

附录：登录配置示例

后续步骤