En este tema se explica cómo habilitar y configurar la administración de identidades en Tanzu Kubernetes Grid (TKG) con un clúster de administración independiente.
Puede habilitar la administración de identidades durante o después de la implementación del clúster de administración mediante la configuración de un proveedor de identidad LDAPS u OIDC. Todos los clústeres de carga de trabajo que cree después de habilitar la administración de identidades se configurarán automáticamente para utilizar el mismo proveedor de identidades que el clúster de administración. Para configurar de forma retroactiva los clústeres de carga de trabajo existentes con la administración de identidades recién habilitada, siga Habilitar la administración de identidades en los clústeres de carga de trabajo.
La habilitación y configuración de la administración de identidades incluye los siguientes pasos. Si desea utilizar archivos estándar y no administrativos kubeconfig
para acceder a los clústeres de carga de trabajo y de administración, después de completar los pasos descritos en este tema, también debe configurar el control de acceso basado en funciones (Role-Based Access Control, RBAC) siguiendo las instrucciones de Configurar RBAC.
(Recomendado) Habilitar y configurar la administración de identidades durante la implementación del clúster de administración:
Para obtener instrucciones, consulte (recomendado) Habilitar y configurar la administración de identidades durante la implementación del clúster de administración a continuación.
Habilitar y configurar la administración de identidades después de la implementación del clúster de administración:
Para obtener instrucciones, consulte Habilitar y configurar la administración de identidades en una implementación existente a continuación.
En esta sección se explica cómo habilitar y configurar la administración de identidades durante la implementación del clúster de administración.
Antes de poder habilitar la administración de identidades, debe tener un proveedor de identidades. Tanzu Kubernetes Grid admite proveedores de identidad de LDAPS y OIDC.
Para utilizar Okta como proveedor de OIDC, debe crear una cuenta con Okta y registrar una aplicación para Tanzu Kubernetes Grid con su cuenta:
http://localhost:8080/callback
. Esto se actualizará con la URL real después de implementar el clúster de administración.Utilice los detalles obtenidos anteriormente para configurar LDAPS u OIDC en Tanzu Kubernetes Grid:
Si va a implementar el clúster de administración desde un archivo de configuración, establezca las variables LDAP_*
o OIDC_*
en el archivo de configuración.
Por ejemplo:
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
Para obtener instrucciones sobre cómo preparar un archivo de configuración del clúster de administración, consulte Crear un archivo de configuración del clúster de administración.
NotaLos pods Dex deben rotarse manualmente cada vez que caduque el certificado TLS de Dex (90 días de forma predeterminada). Puede aumentar la duración del certificado mediante
CERT_DURATION
. Para reiniciar los pods Dex, ejecutekubectl rollout restart deployments/dex -n tanzu-system-auth
.
Después de implementar el clúster de administración, termine de configurar la administración de identidades siguiendo estos procedimientos, que se describen en las secciones siguientes:
kubectl
al clúster de administración.kubeconfig
para acceder al clúster de administración, Configurar RBAC para un clúster de administración.kubectl
al clúster de administraciónPara configurar la administración de identidades, debe obtener y utilizar el contexto admin
del clúster de administración:
Obtenga el contexto admin
del clúster de administración. Los procedimientos descritos en este tema utilizan un clúster de administración denominado id-mgmt-test
.
tanzu mc kubeconfig get id-mgmt-test --admin
Si el clúster de administración se denomina id-mgmt-test
, debería ver que se guardó la confirmación 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'
. El contexto admin
de un clúster de proporciona acceso completo al clúster sin necesidad de autenticación con el IDP.
Establezca kubectl
en el contexto admin
del clúster de administración:
kubectl config use-context id-mgmt-test-admin@id-mgmt-test
Tanzu Kubernetes Grid utiliza Pinniped para integrar clústeres con un servicio de identidad de OIDC. Cuando se habilita OIDC, Tanzu Kubernetes Grid crea el servicio pinniped-supervisor
en el espacio de nombres pinniped-supervisor
y pinniped-concierge
en el espacio de nombres pinniped-concierge
. Siga los pasos que se indican a continuación para comprobar el estado del servicio pinniped y anote la dirección EXTERNAL-IP
en la que se expone el servicio.
Obtenga información sobre los servicios que se ejecutan en el clúster de administración. El servicio de administración de identidades se ejecuta en el espacio de nombres pinniped-supervisor
:
kubectl get services -n pinniped-supervisor
Se muestra la siguiente entrada en resultados:
vSphere con 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
vSphere sin NSX ALB:
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/pinniped-supervisor NodePort 100.70.70.12 <none> 5556:31234/TCP 84m
Tenga en cuenta la siguiente información:
pinniped-supervisor
, tal como aparece en EXTERNAL-IP
.pinniped-supervisor
. En el ejemplo anterior, este puerto es 31234
.Compruebe que todos los servicios del clúster de administración se estén ejecutando.
kubectl get pods -A
El servicio Pinniped puede tardar varios minutos en estar activo y en ejecución. Por ejemplo, en las implementaciones de AWS y Azure, el servicio debe esperar a que las direcciones IP LoadBalancer
estén listas. Espere hasta que vea que pinniped-post-deploy-job
se ha completado antes de continuar con los siguientes pasos.
NAMESPACE NAME READY STATUS RESTARTS AGE
[...]
pinniped-supervisor pinniped-post-deploy-job-hq8fc 0/1 Completed 0 85m
NotaPuede ejecutar
kubectl get pods
porque utiliza el contextoadmin
para el clúster de administración. Los usuarios que intenten conectarse al clúster de administración con el contexto normal no podrán acceder a sus recursos porque aún no están autorizados para hacerlo.
Tanzu Kubernetes Grid utiliza Pinniped para integrar clústeres con un servicio de identidad LDAP, junto con Dex para exponer el endpoint de servicio. Cuando se habilita LDAP, Tanzu Kubernetes Grid crea el servicio pinniped-supervisor
en el espacio de nombres pinniped-supervisor
, pinniped-concierge
en el espacio de nombres pinniped-concierge
y dexsvc
en el espacio de nombres tanzu-system-auth
. Siga los pasos a continuación para comprobar el estado de un servicio LDAP y anote la dirección EXTERNAL-IP
en la que se expone el servicio.
Obtenga información sobre los servicios que se ejecutan en el clúster de administración en el espacio de nombres tanzu-system-auth
:
kubectl get services -n tanzu-system-auth
Se muestra la siguiente entrada en resultados:
vSphere con 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
vSphere sin NSX ALB:
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/dexsvc NodePort 100.70.70.12 <none> 5556:30167/TCP 84m
Compruebe que todos los servicios del clúster de administración se estén ejecutando:
kubectl get pods -A
El servicio Pinniped puede tardar varios minutos en estar activo y en ejecución. Por ejemplo, en las implementaciones de AWS y Azure, el servicio debe esperar a que las direcciones IP LoadBalancer
estén listas. Espere hasta que vea que pinniped-post-deploy-job
se ha completado antes de continuar con los siguientes pasos.
NAMESPACE NAME READY STATUS RESTARTS AGE
[...]
pinniped-supervisor pinniped-post-deploy-job-hq8fc 0/1 Completed 0 85m
NotaPuede ejecutar
kubectl get pods
porque utiliza el contextoadmin
para el clúster de administración. Los usuarios que intenten conectarse al clúster de administración con el contexto normal no podrán acceder a sus recursos porque aún no están autorizados para hacerlo.
Si configuró el clúster de administración para que use la autenticación de OIDC, debe proporcionar el URI de devolución de llamada de ese clúster de administración al proveedor de identidad de OIDC. Por ejemplo, si utiliza OIDC y su IDP es Okta, realice los siguientes pasos:
En Inicio de sesión, actualice los URI de redirección de inicio de sesión para incluir la dirección del nodo en el que se ejecuta el pinniped-supervisor
:
vSphere con NSX ALB, AWS y Azure: Agregue la dirección IP externa y el número de puerto del servicio pinniped-supervisor
que anotó en el procedimiento anterior:
https://EXTERNAL-IP/callback
vSphere sin NSX ALB: Agregue la dirección IP que estableció como endpoint de API y el número de puerto pinniped-supervisor
que anotó en el procedimiento anterior:
https://API-ENDPOINT-IP:31234/callback
En todos los casos, debe especificar https
, no http
.
Si tiene pensado utilizar archivos estándar y no administrativos kubeconfig
para acceder al clúster de administración, después de completar la configuración de la administración de identidades, configure RBAC siguiendo las instrucciones de Configurar RBAC para un clúster de administración.
En esta sección se explica cómo habilitar y configurar la administración de identidades en una implementación existente.
Siga las instrucciones de Obtener los detalles del proveedor de identidad anteriores.
Este procedimiento configura el complemento Pinniped e implementa los componentes de autenticación en el clúster de administración. Para generar un secreto de Kubernetes para el complemento Pinniped:
Establezca el contexto de kubectl
en su clúster de administración. Por ejemplo, con un clúster de administración denominado id-mgmt-test
:
kubectl config use-context id-mgmt-test-admin@id-mgmt-test
Cree un archivo de configuración de clúster copiando las opciones de configuración que definió al implementar el clúster de administración en un archivo nuevo. Agregue la siguiente configuración al archivo de configuración del clúster de administración, incluidos los detalles del proveedor de identidad de OIDC o LDAP:
NotaDebe establecer estas variables solo para los clústeres de administración.
# 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
Para ver cuáles de estas variables son opcionales y se pueden omitir, vaya a Variables para configurar proveedores de identidades : OIDC y Variables para configurar proveedores de identidades: LDAP.
Si el clúster de administración está detrás de un proxy, asegúrese de que el nuevo archivo de configuración incluya los detalles de configuración del proxy:
TKG_HTTP_PROXY:
TKG_HTTPS_PROXY:
TKG_NO_PROXY:
Para obtener más información sobre estas variables, consulte Configuración de proxy.
vSphere: Cambie la opción de configuración de VSPHERE_CONTROL_PLANE_ENDPOINT
a una dirección IP que no se utiliza, como un valor ficticio para pasar las comprobaciones internas.
Asegúrese de que el entorno local tenga IDENTITY_MANAGEMENT_TYPE
establecido en oidc
o ldap
y no en none
:
echo $IDENTITY_MANAGEMENT_TYPE
Si esta variable está establecida en none
, ejecute un comando export
para volver a establecerla en oidc
o ldap
.
Establezca la variable de entorno _TKG_CLUSTER_FORCE_ROLE
en management
:
export _TKG_CLUSTER_FORCE_ROLE="management"
En Windows, utilice el comando SET
.
Establezca la variable de entorno FILTER_BY_ADDON_TYPE
en authentication/pinniped
de modo que tanzu cluster create
funcione solo en objetos relacionados con Pinniped:
export FILTER_BY_ADDON_TYPE="authentication/pinniped"
Genere un secreto para el complemento Pinniped:
tanzu cluster create CLUSTER-NAME --dry-run -f CLUSTER-CONFIG-FILE > CLUSTER-NAME-example-secret.yaml
Donde:
CLUSTER-NAME
es el nombre de su clúster de administración de destino.CLUSTER-CONFIG-FILE
es el archivo de configuración que creó anteriormente.La configuración de la variable de entorno hace que tanzu cluster create --dry-run
genere un secreto de Kubernetes, no un manifiesto del clúster completo.
Revise el secreto y, a continuación, aplíquelo al clúster de administración. Por ejemplo:
kubectl apply -f CLUSTER-NAME-example-secret.yaml
Después de aplicar el secreto, compruebe el estado del complemento Pinniped ejecutando el comando kubectl get app
:
$ kubectl get app CLUSTER-NAME-pinniped -n tkg-system
NAME DESCRIPTION SINCE-DEPLOY AGE
pinniped Reconcile succeeded 3m23s 7h50m
Si el estado devuelto es Reconcile failed
, ejecute el siguiente comando para obtener detalles sobre el error:
kubectl get app CLUSTER-NAME-pinniped -n tkg-system -o yaml
Siga las instrucciones de Completar la configuración de administración de identidades anteriores.
Todos los clústeres de carga de trabajo que cree al habilitar la administración de identidades en el clúster de administración se configurarán automáticamente para utilizar el mismo servicio de administración de identidades.
Si su máquina de arranque es un Jumpbox u otro equipo sin visualización, puede autenticarse en un clúster desde un navegador que se ejecute en su máquina local. La forma de hacerlo depende de la versión de Pinniped del clúster, que proviene de la versión Tanzu Kubernetes en la que se basa el clúster:
Versión de TKr del clúster | Procedimiento de autenticación sin navegador |
---|---|
TKr v1.23.10 (de forma predeterminada para Tanzu Kubernetes Grid v1.6.1) o versiones posteriores | Siga las instrucciones a continuación |
Clústeres basados en TKr más antiguos o creados por versiones anteriores de Tanzu Kubernetes Grid | Siga el procedimiento Autenticar usuarios en una máquina sin navegador en la documentación de Tanzu Kubernetes Grid v1.4 |
NotaTanzu Kubernetes Grid v2.2 no admite el inicio de sesión de CLI sin navegador basado en cuentas no interactivas o concesiones de contraseña.
Desde una ventana de terminal de su máquina local, ejecute ssh
para iniciar sesión de forma remota en la máquina de arranque.
Establezca la variable de entorno TANZU_CLI_PINNIPED_AUTH_LOGIN_SKIP_BROWSER=true
. Esto agrega la opción --skip-browser
a la kubeconfig
del clúster.
# Linux
export TANZU_CLI_PINNIPED_AUTH_LOGIN_SKIP_BROWSER=true
# Windows
set TANZU_CLI_PINNIPED_AUTH_LOGIN_SKIP_BROWSER=true
Exporte el kubeconfig
estándar del clúster a un archivo local. Tenga en cuenta que el comando no incluye la opción --admin
, por lo que el archivo kubeconfig
que se exporta es la versión estándar kubeconfig
y no la versión admin
. Por ejemplo, para exportar el archivo kubeconfig
a /tmp/my-cluster-kubeconfig
:
Para un clúster de administración, ejecute:
tanzu mc kubeconfig get --export-file /tmp/my-cluster-kubeconfig
Deberás ver la confirmación de You can now access the cluster by specifying '--kubeconfig /tmp/my-mgmt-cluster-kubeconfig' flag when using 'kubectl' command
.
Para un clúster de carga de trabajo, ejecute:
tanzu cluster kubeconfig get my-cluster --export-file /tmp/my-cluster-kubeconfig
Conéctese al clúster mediante el archivo kubeconfig
recién creado:
kubectl get pods -A --kubeconfig /tmp/my-cluster-kubeconfig
La CLI genera un vínculo de inicio de sesión para el proveedor de identidad. Por ejemplo:
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:
Copie el vínculo y péguelo en un navegador de la máquina local.
En el navegador, inicie sesión en el proveedor de identidad. Aparece una página que le solicita que pegue un código de autorización en la CLI:
Copie el código de autorización y péguelo en la CLI después de la solicitud Optionally, paste your authorization code:
.
Vuelva a conectarse al clúster mediante el mismo archivo kubeconfig
que utilizó anteriormente:
kubectl get pods -A --kubeconfig FILE-PATH
Si ya configuró un enlace de función en el clúster para el usuario autenticado, el resultado muestra la información del pod.
Si no ha configurado un enlace de función en el clúster, verá un mensaje que deniega el acceso de la cuenta de usuario a los pods: Error from server (Forbidden): pods is forbidden: User "[email protected]" cannot list resource "pods" in API group "" at the cluster scope
. Esto sucede porque el usuario se autenticó correctamente, pero aún no tiene autorización para acceder a ningún recurso del clúster. Para autorizar al usuario a acceder a los recursos del clúster, debe configurar RBAC en el clúster mediante la creación de un enlace de función de clúster:
El componente Pinniped utiliza Dex para los proveedores de identidades LDAP. Para los proveedores de identidades OIDC, no se utiliza Dex.
Si desea actualizar una opción que comience con dex.
en la sección values.yaml
del secreto Pinniped para el clúster de administración, debe realizar los siguientes pasos:
dex.
que desea actualizar. Consulte la tabla en Configuración de values.yaml del paquete administrado automáticamente.En el secreto Pinniped, actualice el ajuste o ajustes dex.
que identificó anteriormente y siga los pasos que se indican a continuación:
dex.dns.INFRASTRUCTURE-PROVIDER.ipAddresses
y dex.config.dns.INFRASTRUCTURE-PROVIDER.dnsNames
. Estos campos se pueden establecer en matrices con cualquier entrada única que no esté vacía, por ejemplo, 0.0.0.0
, ya que se actualizan automáticamente.pinniped.upstream_oidc_issuer_url
en una cadena que no esté vacía que comience con https
. Por ejemplo, https://0.0.0.0
. Este campo se actualiza automáticamente más tarde.dex.config.staticClients
para tener una sola entrada. Esta configuración puede ser cualquier asignación con al menos las claves name
, id
y secret
, por ejemplo, {name: "example-name", id: "example-id", secret: "example-secret"}
, ya que se actualiza automáticamente.Agregue la siguiente superposición al secreto 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
Aplique el secreto Pinniped.
tanzu-system-auth
en el clúster de administración después de aplicar el secreto Pinniped. Para reiniciar el espacio de nombres, puede eliminar Namespace
y esperar a que pinniped
App
vuelvan a crearlo. Es posible que deba reiniciar pinniped-post-deploy-job
Job
en pinniped-supervisor
Namespace
después de aplicar el secreto Pinniped. Para ello, puede eliminar Job
y esperar a que pinniped
App
vuelva a crearlo.Para desactivar la administración de identidades en una implementación existente en la que la administración de identidades está habilitada:
Establezca el contexto de kubectl
en su clúster de administración. Por ejemplo, con un clúster de administración denominado id-mgmt-test
:
kubectl config use-context id-mgmt-test-admin@id-mgmt-test
Recupere el archivo de configuración del clúster de administración y edítelo para establecer IDENTITY_MANAGEMENT_TYPE: none
.
Genere una definición de secreto de Pinniped ejecutando tanzu management-cluster create
con --dry-run
y filtrando objetos relacionados con Pinniped.
FILTER_BY_ADDON_TYPE=authentication/pinniped tanzu management-cluster create --dry-run CLUSTER-CONFIG > PINNIPED-SECRET
Donde CLUSTER-CONFIG
es el archivo de configuración del clúster y PINNIPED-SECRET
es a lo que se denomina la definición Secret
de Pinniped generada, como mc-no-idp.yaml
.
Aplique el nuevo secreto para desactivar Pinniped en el clúster de administración:
kubectl apply -f PINNIPED-SECRET
Después de desactivar Pinniped en el clúster de administración, sus clústeres basados en clases se desactivan automáticamente, pero es necesario desactivar sus clústeres heredados manualmente:
Enumere los secretos de Pinniped restantes en el contexto del clúster de administración:
kubectl get secret -A | grep pinniped-addon
Investigue los secretos en los resultados de kubectl get secret
, si los hubiera, mediante el nombre de secreto y el espacio de nombres enumerados:
kubectl get secret SECRET-NAME -n SECRET-NAMESPACE -o yaml
Elimine los secretos que contienen:
type: tkg.tanzu.vmware.com/addon
: estos son secretos de clústeres heredadoskubectl delete secret SECRET-NAME
Donde SECRET-NAME
es el valor de metadata.name
establecido en la especificación Secret
.
Si pretende utilizar archivos estándar y no administrativos kubeconfig
para proporcionar a los usuarios acceso a los clústeres de carga de trabajo y administración, debe configurar la autorización de RBAC: