This site will be decommissioned on December 31st 2024. After that date content will be available at techdocs.broadcom.com.

 

配置身份管理

本主题介绍了如何在具有独立管理集群的 Tanzu Kubernetes Grid (TKG) 中启用和配置身份管理。

关于启用和配置身份管理

您可以通过配置 LDAPS 或 OIDC 身份提供程序，在管理集群部署期间或之后启用身份管理。启用身份管理后创建的任何工作负载集群都将自动配置为使用与管理集群相同的身份提供程序。要追溯配置具有新启用身份管理的现有工作负载集群，请按照工作负载集群上启用身份管理操作。

启用和配置身份管理包括以下步骤。如果要使用标准的非管理员 kubeconfig 文件访问管理和工作负载集群，在完成本主题中的步骤后，还必须按照配置 RBAC 中的说明配置基于角色的访问控制 (RBAC)。

（推荐）在管理集群部署期间启用和配置身份管理：

  1. 获取身份提供程序详细信息。
  2. 使用获取的详细信息在 Tanzu Kubernetes Grid 中配置 LDAPS 或 OIDC。
  3. 创建管理集群后，确认身份验证服务正常运行并完成其配置。

有关说明，请参见下面的（推荐）在管理集群部署期间启用和配置身份管理。

在管理集群部署期间启用和配置身份管理：

  1. 获取身份提供程序详细信息。
  2. 为管理集群生成 Pinniped 附加密钥。
  3. 确认身份验证服务正常运行并完成其配置。
  4. 如果管理集群管理任何工作负载集群，请为启用身份管理之前创建的每个工作负载集群生成 Pinniped 附加密钥。

有关说明，请参见下面的在现有部署中启用和配置身份管理。

（推荐）在管理集群部署期间启用和配置身份管理

本节介绍了如何在管理集群部署期间启用和配置身份管理。

获取身份提供程序详细信息

您必须先具有身份提供程序，然后才能启用身份管理。Tanzu Kubernetes Grid 支持 LDAPS 和 OIDC 身份提供程序。

  • 要使用您公司的内部 LDAPS 服务器作为身份提供程序，请从 LDAP 管理员那里获取 LDAPS 信息。
  • 要使用 OIDC 作为身份提供程序，您必须拥有支持 OpenID Connect 标准的身份提供程序的帐户，例如 Okta。

例如：在 Okta 中注册 Tanzu Kubernetes Grid 应用程序

要将 Okta 用作 OIDC 提供程序，必须在 Okta 中创建一个帐户，并使用您的帐户向 Tanzu Kubernetes Grid 注册应用程序：

  1. 如果没有，请创建一个 Okta 帐户。
  2. 单击管理员 (Admin) 按钮以转到管理员门户。
  3. 转到“应用程序”，然后单击添加应用程序 (Add Application)。
  4. 单击创建新应用 (Create New App)。
  5. 对于平台，选择 Web；对于 登录方法，选择 OpenID Connect，然后单击创建 (Create)。
  6. 为应用程序命名。
  7. 输入占位符登录重定向 URI。例如，输入http://localhost:8080/callback。部署管理集群后，将使用实际 URL 更新此 URL。
  8. 单击保存 (Save)。
  9. 在应用程序的常规 (General) 选项卡中，复制并保存客户端 ID 和客户端密钥。部署管理集群时，您将需要这些凭据。
  10. 在分配 (Assignments) 选项卡中，为应用程序分配人员和组。分配给应用程序的人员和组将是可以访问管理集群和用于部署的工作负载集群的用户。

在 Tanzu Kubernetes Grid 中配置 LDAPS 或 OIDC 设置

使用上述获取的详细信息在 Tanzu Kubernetes Grid 中配置 LDAPS 或 OIDC：

  • 如果要使用安装程序界面部署管理集群，请在身份管理部分中配置 LDAPS 或 OIDC。有关说明，请参见使用安装程序界面配置部署管理集群中的配置身份管理。

  • 如果要从配置文件部署管理集群，请在配置文件中设置 LDAP_* 或 OIDC_* 变量。

    例如：

    LDAP：

    IDENTITY_MANAGEMENT_TYPE: ldap
LDAP_BIND_DN: ""
LDAP_BIND_PASSWORD: ""
LDAP_GROUP_SEARCH_BASE_DN: dc=example,dc=com
LDAP_GROUP_SEARCH_FILTER: (objectClass=posixGroup)
LDAP_GROUP_SEARCH_GROUP_ATTRIBUTE: memberUid
LDAP_GROUP_SEARCH_NAME_ATTRIBUTE: cn
LDAP_GROUP_SEARCH_USER_ATTRIBUTE: uid
LDAP_HOST: ldaps.example.com:636
LDAP_ROOT_CA_DATA_B64: ""
LDAP_USER_SEARCH_BASE_DN: ou=people,dc=example,dc=com
LDAP_USER_SEARCH_FILTER: (objectClass=posixAccount)
LDAP_USER_SEARCH_NAME_ATTRIBUTE: uid
LDAP_USER_SEARCH_USERNAME: uid

    OIDC：

    IDENTITY_MANAGEMENT_TYPE: oidc
OIDC_IDENTITY_PROVIDER_CLIENT_ID: 0oa2i[...]NKst4x7
OIDC_IDENTITY_PROVIDER_CLIENT_SECRET: 331!b70[...]60c_a10-72b4
OIDC_IDENTITY_PROVIDER_GROUPS_CLAIM: groups
OIDC_IDENTITY_PROVIDER_ISSUER_URL: https://dev-[...].okta.com
OIDC_IDENTITY_PROVIDER_SCOPES: openid,groups,email
OIDC_IDENTITY_PROVIDER_USERNAME_CLAIM: email

    有关如何准备管理集群配置文件的说明，请参见创建管理集群配置文件。

注意

每次 Dex TLS 证书过期（默认为 90 天）时，都必须手动轮换 Dex Pod。您可以使用 CERT_DURATION 延长证书持续时间。要重新启动 Dex Pod，请运行 kubectl rollout restart deployments/dex -n tanzu-system-auth。

完成身份管理的配置

部署管理集群后，请按照以下各节中所述的过程完成身份管理的配置：

  1. 将 kubectl 连接到管理集群。
  2. 通过检查身份验证服务的状态，确认其是否运行正常：
  3. OIDC：为 OIDC 提供程序提供回调 URI。
  4. 要支持使用标准的非管理员 kubeconfig 文件访问管理集群，则为管理集群配置 RBAC。

将 kubectl 连接到管理集群

要配置身份管理，您必须获取并使用管理集群的 admin 上下文：

  1. 获取管理集群的 admin 上下文。本主题中的过程使用名为 id-mgmt-test 的管理集群。

    tanzu mc kubeconfig get id-mgmt-test --admin

    如果您的管理集群命名为 id-mgmt-test，您应该会看到确认信息 Credentials of workload cluster 'id-mgmt-test' have been saved. You can now access the cluster by running 'kubectl config use-context id-mgmt-test-admin@id-mgmt-test'。通过集群的 admin 上下文，您可以完全访问集群，而无需通过 IDP 进行身份验证。

  2. 将 kubectl 设置为管理集群的 admin 上下文：

    kubectl config use-context id-mgmt-test-admin@id-mgmt-test

检查 OIDC 身份管理服务的状态

Tanzu Kubernetes Grid 使用 Pinniped 将集群与 OIDC 身份服务集成。启用 OIDC 时，Tanzu Kubernetes Grid 会在 pinniped-supervisor 命名空间中创建 pinniped-supervisor 服务，并在 pinniped-concierge 命名空间中创建 pinniped-concierge。按照以下步骤检查 Pinniped 服务的状态，并记下公开该服务的 EXTERNAL-IP 地址。

  1. 获取有关管理集群中运行的服务的信息。身份管理服务在 pinniped-supervisor 命名空间中运行：

    kubectl get services -n pinniped-supervisor

    您可能会在输出中看到以下条目：

    vSphere with NSX Advanced Load Balancer (ALB)：

    NAME                          TYPE           CLUSTER-IP     EXTERNAL-IP    PORT(S)          AGE
service/pinniped-supervisor   LoadBalancer   100.70.70.12   20.52.230.18   5556:31234/TCP   84m

    Amazon Web Services (AWS)：

    NAME                          TYPE           CLUSTER-IP     EXTERNAL-IP                              PORT(S)         AGE
service/pinniped-supervisor   LoadBalancer   100.69.13.66   ab1[...]71.eu-west-1.elb.amazonaws.com   443:30865/TCP   56m

    Azure：

    NAME                          TYPE           CLUSTER-IP       EXTERNAL-IP      PORT(S)         AGE
service/pinniped-supervisor   LoadBalancer   100.69.169.220   20.54.226.44     443:30451/TCP   84m

    没有 NSX ALB 的 vSphere：

    NAME                          TYPE       CLUSTER-IP     EXTERNAL-IP   PORT(S)          AGE
service/pinniped-supervisor   NodePort   100.70.70.12   <none>        5556:31234/TCP   84m

  2. 请注意以下信息：

    • vSphere with NSX ALB、AWS 和 Azure：记下 pinniped-supervisor 服务的外部地址，如 EXTERNAL-IP 下所列。
    • 没有 NSX ALB 的 vSphere：记下正在运行 pinniped-supervisor 服务的端口。在上面的示例中，此端口为 31234。

  3. 检查管理集群中的所有服务是否正在运行。

    kubectl get pods -A

    Pinniped 服务可能需要几分钟才能启动并运行。例如，在 AWS 和 Azure 部署中，该服务必须等待 LoadBalancer IP 地址准备就绪。等待看到 pinniped-post-deploy-job 已完成，然后再继续执行后续步骤。

    NAMESPACE             NAME                                   READY  STATUS      RESTARTS  AGE
[...]
pinniped-supervisor   pinniped-post-deploy-job-hq8fc         0/1    Completed   0         85m
注意

您能够运行 kubectl get pods，因为您正在对管理集群使用 admin 上下文。尝试连接到具有常规上下文的管理集群的用户将无法访问其资源，因为他们尚未获得授权。

检查 LDAP 身份管理服务的状态

Tanzu Kubernetes Grid 使用 Pinniped 将集群与 LDAP 身份服务集成，并使用 Dex 公开服务端点。启用 LDAP 时，Tanzu Kubernetes Grid 会在 pinniped-supervisor 命名空间中创建 pinniped-supervisor 服务，在 pinniped-concierge 命名空间中创建 pinniped-concierge，以及在 tanzu-system-auth 命名空间中创建 dexsvc。按照以下步骤检查 LDAP 服务的状态，并记下公开该服务的 EXTERNAL-IP 地址。

  1. 获取有关在 tanzu-system-auth 命名空间的管理集群中运行的服务的信息：

    kubectl get services -n tanzu-system-auth

    您可能会在输出中看到以下条目：

    vSphere with NSX ALB：

    NAME             TYPE           CLUSTER-IP     EXTERNAL-IP    PORT(S)          AGE
service/dexsvc   LoadBalancer   100.70.70.12   20.52.230.18   443:30167/TCP   84m

    AWS：

    NAME             TYPE           CLUSTER-IP       EXTERNAL-IP                              PORT(S)         AGE
service/dexsvc   LoadBalancer   100.65.184.107   a6e[...]74.eu-west-1.elb.amazonaws.com   443:32547/TCP   84m

    Azure：

    NAME             TYPE           CLUSTER-IP       EXTERNAL-IP   PORT(S)         AGE
service/dexsvc   LoadBalancer   100.69.169.220   20.54.226.44  443:30451/TCP   84m

    没有 NSX ALB 的 vSphere：

    NAME             TYPE       CLUSTER-IP     EXTERNAL-IP   PORT(S)          AGE
service/dexsvc   NodePort   100.70.70.12   <none>        5556:30167/TCP   84m

  2. 检查管理集群中的所有服务是否正在运行：

    kubectl get pods -A

    Pinniped 服务可能需要几分钟才能启动并运行。例如，在 AWS 和 Azure 部署中，该服务必须等待 LoadBalancer IP 地址准备就绪。等待看到 pinniped-post-deploy-job 已完成，然后再继续执行后续步骤。

    NAMESPACE             NAME                                   READY  STATUS      RESTARTS  AGE
[...]
pinniped-supervisor   pinniped-post-deploy-job-hq8fc         0/1    Completed   0         85m
    注意

    您能够运行 kubectl get pods，因为您正在对管理集群使用 admin 上下文。尝试连接到具有常规上下文的管理集群的用户将无法访问其资源，因为他们尚未获得授权。

  3. 继续执行配置管理集群的 RBAC。

（仅限 OIDC）将回调 URI 提供给 OIDC 提供程序

如果将管理集群配置为使用 OIDC 身份验证，则必须向 OIDC 身份提供程序提供该管理集群的回调 URI。例如，如果您使用的是 OIDC，并且您的 IDP 为 Okta，请执行以下步骤：

  1. 登录到您的 Okta 帐户。
  2. 在主菜单中，转到应用程序。
  3. 选择您为 Tanzu Kubernetes Grid 创建的应用程序。
  4. 在“常规设置”面板中，单击编辑 (Edit)。

  5. 在“登录”下，更新登录重定向 URI 以包含运行 pinniped-supervisor 的节点的地址：

    • vSphere with NSX ALB、AWS 和 Azure：添加在上一过程中指出的 pinniped-supervisor 服务的外部 IP 地址和端口号：

      https://EXTERNAL-IP/callback

    • 没有 NSX ALB 的 vSphere：添加您设置为 API 端点的 IP 地址以及在上一过程中指出的 pinniped-supervisor 端口号：

      https://API-ENDPOINT-IP:31234/callback

      在所有情况下，都必须指定 https，而不是 http。

  6. 单击保存 (Save)。

为管理集群配置 RBAC

如果您计划使用标准的非管理员 kubeconfig 文件访问管理集群，请在完成身份管理配置后，按照 配置管理集群的 RBAC 中的说明配置 RBAC。

在现有部署中启用和配置身份管理

本节介绍了如何在现有部署中启用和配置身份管理。

获取身份提供程序详细信息

按照上面获取您的身份提供程序详细信息中的说明进行操作。

为管理集群生成 Pinniped 附加密钥

此过程将配置 Pinniped 附加项，并在管理集群中部署身份验证组件。要为 Pinniped 附加项生成 Kubernetes 密钥，请执行以下操作：

  1. 将 kubectl 的上下文设置为管理集群。例如，对于名为 id-mgmt-test 的管理集群：

    kubectl config use-context id-mgmt-test-admin@id-mgmt-test

  2. 通过将部署管理集群时定义的配置设置复制到新文件中，创建集群配置文件。将以下设置添加到管理集群配置文件，包括 OIDC 或 LDAP 身份提供程序详细信息：

    注意

    您只需要为管理集群设置这些变量。

    # Identity management type. This must be "oidc" or "ldap".

IDENTITY_MANAGEMENT_TYPE:

# Explicitly set the namespace, which for management clusters is "tkg-system".

NAMESPACE: tkg-system

# Set these variables if you want to configure OIDC.

OIDC_IDENTITY_PROVIDER_CLIENT_ID:
OIDC_IDENTITY_PROVIDER_CLIENT_SECRET:
OIDC_IDENTITY_PROVIDER_GROUPS_CLAIM:
OIDC_IDENTITY_PROVIDER_ISSUER_URL:
OIDC_IDENTITY_PROVIDER_SCOPES: "email,profile,groups"
OIDC_IDENTITY_PROVIDER_USERNAME_CLAIM:

# Set these variables if you want to configure LDAP.

LDAP_BIND_DN:
LDAP_BIND_PASSWORD:
LDAP_GROUP_SEARCH_BASE_DN:
LDAP_GROUP_SEARCH_FILTER:
LDAP_GROUP_SEARCH_GROUP_ATTRIBUTE:
LDAP_GROUP_SEARCH_NAME_ATTRIBUTE: cn
LDAP_GROUP_SEARCH_USER_ATTRIBUTE: DN
LDAP_HOST:
LDAP_ROOT_CA_DATA_B64:
LDAP_USER_SEARCH_BASE_DN:
LDAP_USER_SEARCH_EMAIL_ATTRIBUTE: DN
LDAP_USER_SEARCH_FILTER:
LDAP_USER_SEARCH_ID_ATTRIBUTE: DN
LDAP_USER_SEARCH_NAME_ATTRIBUTE:
LDAP_USER_SEARCH_USERNAME: userPrincipalName

# Set these variables if you want to configure certificate duration

CERT_DURATION: 2160h
CERT_RENEW_BEFORE: 360h

    要查看其中哪些变量是可选的且可以忽略，请转到 配置身份提供程序的变量 - OIDC 和 配置身份提供程序的变量 - LDAP。

    如果您的管理集群位于代理后面，请确保新的配置文件包含代理配置详细信息：

    TKG_HTTP_PROXY:
TKG_HTTPS_PROXY:
TKG_NO_PROXY:

    有关这些变量的详细信息，请参见代理配置。

    vSphere：将 VSPHERE_CONTROL_PLANE_ENDPOINT 配置设置更改为未使用的 IP 地址，作为通过内部检查的虚拟值。

  3. 确保您的本地环境已将 IDENTITY_MANAGEMENT_TYPE 设置为 oidc 或 ldap，而不是设置为 none：

    echo $IDENTITY_MANAGEMENT_TYPE

    如果该变量设置为 none，请运行 export 命令将其重新设置为 oidc 或 ldap。

  4. 将 _TKG_CLUSTER_FORCE_ROLE 环境变量设置为 management：

    export _TKG_CLUSTER_FORCE_ROLE="management"

    在 Windows 中，使用 SET 命令。

  5. 将 FILTER_BY_ADDON_TYPE 环境变量设置为 authentication/pinniped，以便 tanzu cluster create 仅在与 Pinniped 相关的对象上运行：

    export FILTER_BY_ADDON_TYPE="authentication/pinniped"

  6. 为 Pinniped 附加项生成密钥：

    tanzu cluster create CLUSTER-NAME --dry-run -f CLUSTER-CONFIG-FILE > CLUSTER-NAME-example-secret.yaml

    其中：

    • CLUSTER-NAME 是目标管理集群的名称。
    • CLUSTER-CONFIG-FILE 是上面创建的配置文件。

    环境变量设置导致 tanzu cluster create --dry-run 生成 Kubernetes 密钥，而不是完整的集群清单。

  7. 查看密钥，然后将其应用于管理集群。例如：

    kubectl apply -f CLUSTER-NAME-example-secret.yaml

  8. 应用密钥后，通过运行 kubectl get app 命令检查 Pinniped 附加项的状态：

    $ kubectl get app CLUSTER-NAME-pinniped -n tkg-system
NAME           DESCRIPTION             SINCE-DEPLOY    AGE
pinniped       Reconcile succeeded     3m23s           7h50m

    如果返回的状态为 Reconcile failed，请运行以下命令以获取有关失败的详细信息：

    kubectl get app CLUSTER-NAME-pinniped -n tkg-system -o yaml

完成身份管理的配置

按照上面完成身份管理配置中的说明进行操作。

在工作负载集群上启用身份管理

在管理集群中启用身份管理时创建的任何工作负载集群都将自动配置为使用相同的身份管理服务。

在不使用浏览器的计算机上对用户进行身份验证

如果引导计算机是 jumpbox 或其他不显示的计算机，则可以从本地计算机上运行的浏览器对集群进行身份验证。具体操作方式取决于集群的 Pinniped 版本，该版本来自于集群所基于的 Tanzu Kubernetes 版本：

集群 TKr 版本 无浏览器身份验证过程
TKr v1.23.10（Tanzu Kubernetes Grid v1.6.1 的默认值）或更高版本 按照以下说明操作
基于较旧 TKR 或由旧版本的 Tanzu Kubernetes Grid 创建的集群 按照 Tanzu Kubernetes Grid v1.4 文档中的在不使用浏览器的计算机上对用户进行身份验证过程操作
注意

Tanzu Kubernetes Grid v2.2 不支持基于非交互式帐户或密码的无浏览器 CLI 登录。

  1. 从本地计算机上的终端窗口中，运行 ssh 以远程登录到引导计算机。

  2. 设置 TANZU_CLI_PINNIPED_AUTH_LOGIN_SKIP_BROWSER=true 环境变量。这会将 --skip-browser 选项添加到集群的 kubeconfig。

    # Linux
export TANZU_CLI_PINNIPED_AUTH_LOGIN_SKIP_BROWSER=true
# Windows
set TANZU_CLI_PINNIPED_AUTH_LOGIN_SKIP_BROWSER=true

  3. 将集群的标准 kubeconfig 导出到本地文件。请注意，该命令不包含 --admin 选项，因此导出的 kubeconfig 是标准 kubeconfig，而不是 admin 版本。例如，要将 kubeconfig 文件导出到 /tmp/my-cluster-kubeconfig，请执行以下操作：

    • 对于管理集群，请运行：

      tanzu mc kubeconfig get --export-file /tmp/my-cluster-kubeconfig

      您会看到确认信息 You can now access the cluster by specifying '--kubeconfig /tmp/my-mgmt-cluster-kubeconfig' flag when using 'kubectl' command。

    • 对于工作负载集群，请运行：

      tanzu cluster kubeconfig get my-cluster --export-file /tmp/my-cluster-kubeconfig

  4. 使用新创建的 kubeconfig 文件连接到集群：

    kubectl get pods -A --kubeconfig /tmp/my-cluster-kubeconfig

    CLI 输出身份提供程序的登录链接。例如：

    Log in by visiting this link:

   https://10.180.105.166:31234/oauth2/authorize?access_type=offline&client_id=pinniped-cli&code_challenge=-aJ617vJZXZeEnHPab1V2_VHPmc5VwspFig5QQKyTwg&code_challenge_method=S256&nonce=cafaf8f4d2cb714ef8fb3320c1b088ba&redirect_uri=http%3A%2F%2F127.0.0.1%3A33087%2Fcallback&response_mode=form_post&response_type=code&scope=offline_access+openid+pinniped%3Arequest-audience&state=fff3d4d46b36359d5ba2f24fad471dd8

   Optionally, paste your authorization code:

  5. 复制链接并将其粘贴到本地计算机上的浏览器中。

  6. 在浏览器中，登录到您的身份提供程序。此时将显示一个页面，提示您将授权代码粘贴到 CLI 中：

    完成登录

  7. 复制授权代码并将其粘贴到 CLI 中的 Optionally, paste your authorization code: 提示符后。

  8. 使用与之前所用相同的 kubeconfig 文件再次连接到集群：

    kubectl get pods -A --kubeconfig FILE-PATH

    • 如果已在集群上为经过身份验证的用户配置了角色绑定，输出将显示 pod 信息。

    • 如果未在集群上配置角色绑定，您将看到一条拒绝用户帐户访问 Pod 的消息：Error from server (Forbidden): pods is forbidden: User "[email protected]" cannot list resource "pods" in API group "" at the cluster scope。发生这种情况的原因是，用户已成功通过身份验证，但他们尚未获得访问集群上任何资源的授权。要授权用户访问集群资源，您必须通过创建集群角色绑定在集群上配置 RBAC：

部署管理集群后更新 Dex 设置

Pinniped 组件将 Dex 用于 LDAP 身份提供程序。对于 OIDC 身份提供程序，不使用 Dex。

如果要更新管理集群的 Pinniped 密钥的 values.yaml 部分中以 dex. 开头的设置，必须执行以下步骤：

  1. 确定要更新的一个或多个 dex. 设置。请参见自动管理的软件包 values.yaml 设置中的表。
  2. 检索管理集群的 Pinniped 密钥，如自动管理的软件包 values.yaml 设置中所述。

  3. 在 Pinniped 密钥中，更新在上面确定的一个或多个 dex. 设置，然后按照以下步骤操作：

    1. 设置 dex.dns.INFRASTRUCTURE-PROVIDER.ipAddresses 和 dex.config.dns.INFRASTRUCTURE-PROVIDER.dnsNames 阵列配置设置。这些字段可以设置为具有任何单个非空条目的数组，例如，0.0.0.0，因为它们是自动更新的。
    2. 将 pinniped.upstream_oidc_issuer_url 配置设置设定为以 https 开头的非空字符串。例如，https://0.0.0.0。稍后将自动更新此字段。
    3. 将 dex.config.staticClients 阵列配置设置设定为具有单个条目。此设置可以是至少具有 name、id 和 secret 键的任何映射，例如，{name: "example-name", id: "example-id", secret: "example-secret"}，因为它已自动更新。

    4. 将以下覆盖添加到 Pinniped 密钥：

      #@ load("@ytt:overlay", "overlay")
#@overlay/match by=overlay.subset({"metadata": {"name" : "upstream-oidc-identity-provider"}})
---
metadata:
  annotations:
    #@overlay/remove
    kapp.k14s.io/update-strategy: always-replace

  4. 应用 Pinniped 秘钥。

  5. 应用 Pinniped 密钥后，重新启动管理集群中的 tanzu-system-auth 命名空间。要重新启动命名空间，可以删除 Namespace 并等待 pinniped App 重新创建该命名空间。应用 Pinniped 密钥后，您可能需要重新启动 pinniped-supervisor Namespace 中的 pinniped-post-deploy-job Job。为此，您可以删除 Job并等待 pinniped App 重新创建它。

在现有部署中停用身份管理

要在启用了身份管理的现有部署中停用身份管理，请执行以下操作：

  1. 将 kubectl 的上下文设置为管理集群。例如，对于名为 id-mgmt-test 的管理集群：

    kubectl config use-context id-mgmt-test-admin@id-mgmt-test

  2. 检索管理集群配置文件并进行编辑以设置 IDENTITY_MANAGEMENT_TYPE: none。

  3. 通过 --dry-run 运行 tanzu management-cluster create 并筛选与 Pinniped 相关的对象，生成 Pinniped 密钥定义。

    FILTER_BY_ADDON_TYPE=authentication/pinniped tanzu management-cluster create --dry-run CLUSTER-CONFIG > PINNIPED-SECRET

    其中，CLUSTER-CONFIG 是集群配置文件，PINNIPED-SECRET 是您对生成的 Pinniped Secret 定义的命名，如 mc-no-idp.yaml。

  4. 应用新密钥以在管理集群上停用 Pinniped：

    kubectl apply -f PINNIPED-SECRET

  5. 在管理集群上停用 Pinniped 后，其基于类的集群会自动停用，但您需要手动停用其旧版集群：

    1. 列出管理集群上下文中剩余的任何 Pinniped 密钥：

      kubectl get secret -A | grep pinniped-addon

    2. 使用列出的密钥名称和命名空间调查 kubectl get secret 输出（如果有）中的密钥：

      kubectl get secret SECRET-NAME -n SECRET-NAMESPACE -o yaml

    3. 删除包含以下任一项的密钥：

      • type: tkg.tanzu.vmware.com/addon - 这些是旧版集群密钥
      • 任何 OIDC 或 LDAP 配置
      kubectl delete secret SECRET-NAME

      其中， SECRET-NAME 是在 Secret 规范中设置的 metadata.name 的值。

下一步操作

如果要使用标准的非管理员 kubeconfig 文件向用户授予对管理和工作负载集群的访问权限，则必须配置 RBAC 授权：

check-circle-line exclamation-circle-line close-line
Scroll to top icon