配置身份和安全

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

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

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

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

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

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

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

  1. 转到身份和访问权限页面

    身份配置文件页面

  2. 点击将配置文件应用于集群。

    将配置文件应用到现有用户集群

  3. 从配置文件下拉列表中选择要应用的身份配置文件。

  4. 从集群下拉列表中选择要应用身份配置文件的集群。

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

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

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

查看用户集群身份配置

下载用户集群登录配置文件

下载用户集群登录配置

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

通过文件指定 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 isolated 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 专用模式管理中心界面获取登录配置。或者，您可以通过执行以下命令来创建登录配置文件：

actl auth create-login-config --kubeconfig=USER_CLUSTER_KUBECONFIG \
  --output=user-cluster-anthos-config.yaml

将 user-cluster-anthos-config.yaml 分发给用户集群的用户。

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

actl auth login --login-config=user-cluster-anthos-config.yaml \
  --cluster=USER_CLUSTER_NAME --kubeconfig=./user-cluster-oidc-kubeconfig

将 USER_CLUSTER_NAME 替换为管理控制台中显示的用户集群的名称。--kubeconfig=user-cluster-oidc-kubeconfig 是输出 Kubeconfig 文件名。

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

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

使用 Google 单点登录进行身份验证

请注意，Google 单点登录在隔离模式下不可用，本部分仅用于演示和测试。如果要使用 Google 单点登录，则集群和浏览器都必须能够与 Google 的单点登录服务器通信。Google 的单点登录服务器不需要与用户集群联系。

  1. 登录 Google Cloud Console 并选择有效的项目。
  2. 访问“API 和服务 > OAuth 同意屏幕”部分。
  3. 创建一个新的 OAuth 同意屏幕。此信息通常向用户显示。
    1. 将应用首页设置为管理员网址。
  4. 在 API 和服务 > 凭据部分中执行以下操作：
    1. 点击创建凭据。
    2. 创建一个新的 OAuth 客户端 ID。
    3. 将应用类型设置为 Web 应用。
    4. 选择一个相关的名称
    5. 对于 JavaScript 来源，请设置 https://anthos.example.com（假设 https://anthos.example.com 是 Management Center 的域名）。
    6. 对于已获授权的重定向 URI，请设置：
      • https://anthos.example.com/_gcp_anthos_oidc_callback
      • http://localhost:9879/callback
  5. 将 ClientID 和客户端密钥复制到 AdminUI 配置。
  6. 将 OIDC 提供方网址设置为 https://accounts.google.com。。
  7. 将Username Claim设置为email，并将Scopes设置为 openid email。
  8. 将“额外的参数”设置为 prompt=consent,access_type=offline。否则，您无法使用 Kubernetes API 服务器登录。
  9. 添加要授予 Platform Admin 权限的用户电子邮件的初始列表（用英文逗号分隔）。
  10. 点击 Save。

Google 单点登录

审核日志记录

为 Anthos 专用模式启用了 Kubernetes 审核，并提供在平台上检查管理访问权限和操作的方法。

目前，无法为参数（如保留时间、刷新频率或区块大小）自定义审核日志。审核级别为 Metadata，它记录请求元数据（请求用户、时间戳、资源、动词），但不记录请求或响应正文。

默认情况下，Anthos 不公开模式下会启用审核日志记录。如需了解访问审核日志的详细步骤，请参阅日志记录和监控。