Configurar la administración de identidades

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.

Acerca de la habilitación y configuración de la administración de identidades

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:

Obtenga los detalles del proveedor de identidad.
Utilice los detalles obtenidos para configurar LDAPS u OIDC en Tanzu Kubernetes Grid.
Una vez creado el clúster de administración, confirme que el servicio de autenticación se esté ejecutando correctamente y complete la configuració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:

Obtenga los detalles del proveedor de identidad.
Genere el secreto de complemento Pinniped para el clúster de administración.
Confirme que el servicio de autenticación se esté ejecutando correctamente y complete la configuración.
Si el clúster de administración administra algún clúster de carga de trabajo, genere el secreto del complemento Pinniped para cada clúster de carga de trabajo que se creó antes de habilitar la administración de identidades.

Para obtener instrucciones, consulte Habilitar y configurar la administración de identidades en una implementación existente a continuación.

(Recomendado) Habilitar y configurar la administración de identidades durante la implementación del clúster de administració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.

Obtener los detalles del proveedor de identidad

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 el servidor LDAPS interno de su empresa como proveedor de identidades, obtenga la información de LDAPS del administrador de LDAP.
Para utilizar OIDC como proveedor de identidades, debe tener una cuenta con un proveedor de identidad que admita el estándar de OpenID Connect, por ejemplo, Okta.

Ejemplo: Registrar una aplicación Tanzu Kubernetes Grid en Okta

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:

Si no tiene una, cree una cuenta de Okta.
Vaya al portal de administración haciendo clic en el botón Administrador.
Vaya a Aplicaciones y haga clic en Agregar aplicación.
Haga clic en Crear nueva aplicación.
Para Plataforma, seleccione Web y, para Método de inicio de sesión, seleccione Conexión de identificación abierta y, a continuación, haga clic en Crear.
Asigne un nombre a la aplicación.
Introduzca un marcador URI de redirección de sesión. Por ejemplo, escriba http://localhost:8080/callback. Esto se actualizará con la URL real después de implementar el clúster de administración.
Haga clic en Guardar.
En la pestaña General de la aplicación, copie y guarde los ID de cliente y Secreto de cliente. Necesitará estas credenciales cuando implemente el clúster de administración.
En la pestaña Asignaciones, asigne personas y grupos a la aplicación. Las personas y los grupos que asigne a la aplicación serán los usuarios que podrán acceder al clúster de administración y los clústeres de carga de trabajo que utilice para implementar.

Configurar los ajustes de LDAPS u OIDC en Tanzu Kubernetes Grid

Utilice los detalles obtenidos anteriormente para configurar LDAPS u OIDC en Tanzu Kubernetes Grid:

Si va a implementar el clúster de administración mediante la interfaz del instalador, configure LDAPS o OIDC en la sección Administración de identidades. Para obtener instrucciones, consulte Configurar la administración de identidades en Implementar clústeres de administración con la interfaz del instalador.

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.

Nota
Los 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, ejecute kubectl rollout restart deployments/dex -n tanzu-system-auth.

Completar la configuración de administración de identidades

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:

Conectar kubectl al clúster de administración.
Confirme que el servicio de autenticación se está ejecutando correctamente comprobando su estado:
- OIDC: Comprobar el estado de un servicio de administración de identidades de OIDC.
- LDAP: Comprobar el estado de un servicio de administración de identidades de LDAP.
OIDC: Proporcionar el URI de devolución de llamada al proveedor de OIDC.
Para admitir el uso de archivos estándar de kubeconfig para acceder al clúster de administración, Configurar RBAC para un clúster de administración.

Conectar `kubectl` al clúster de administración

Para 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
```

Comprobar el estado de un servicio de administración de identidades de OIDC

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 all -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:
- vSphere con NSX ALB, AWS y Azure: Anote la dirección externa del servicio pinniped-supervisor, tal como aparece en EXTERNAL-IP.
- vSphere sin NSX ALB: Tenga en cuenta el puerto en el que se ejecuta el servicio 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
```

Nota
Puede ejecutar kubectl get pods porque utiliza el contexto admin 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.

Comprobar el estado de un servicio de administración de identidades LDAP

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 all -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
```
Nota
Puede ejecutar kubectl get pods porque utiliza el contexto admin 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.
Continúe con Configurar RBAC para el clúster de administración.

(Solo OIDC) Proporcionar el URI de devolución de llamada al proveedor de OIDC

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:

Inicie sesión en la cuenta de Okta.
En el menú principal, vaya a Aplicaciones.
Seleccione la aplicación que creó para Tanzu Kubernetes Grid.
En el panel Configuración general, haga clic en Editar.
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.
Haga clic en Guardar.

Configurar RBAC para el clúster de administración

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.

Habilitar y configurar la administración de identidades en una implementación existente

En esta sección se explica cómo habilitar y configurar la administración de identidades en una implementación existente.

Obtener los detalles del proveedor de identidad

Siga las instrucciones de Obtener los detalles del proveedor de identidad anteriores.

Generar el secreto de complemento Pinniped para el clúster de administración

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:

Nota
Debe 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 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 pinniped -n tkg-system -o yaml
```

Completar la configuración de administración de identidades

Siga las instrucciones de Completar la configuración de administración de identidades anteriores.

Habilitar la administración de identidades en clústeres de carga de trabajo

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.

Autenticar usuarios en una máquina sin navegador

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

Nota
Tanzu Kubernetes Grid v2.1 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:
  - Consulte Crear un enlace de función en el clúster de administración.
  - Consulte Crear un enlace de función en un clúster de carga de trabajo.

Actualizar la configuración de Dex después de la implementación del clúster de administración

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:

Identifique el ajuste o ajustes dex. que desea actualizar. Consulte la tabla en Actualizar la sección values.yaml.
Recupere el secreto de Pinniped para el clúster de administración como se describe en Actualizar la sección values.yaml.
En el secreto Pinniped, actualice el ajuste o ajustes dex. que identificó anteriormente y siga los pasos que se indican a continuación:
1. Establezca las opciones de configuración de matriz 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.
2. Establezca la configuración de 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.
3. Establezca la opción de configuración de matriz 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.
4. 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.
Reinicie el espacio de nombres 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.

Desactivar la administración de identidades en una implementación existente

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:
1. Enumere los secretos de Pinniped restantes en el contexto del clúster de administración:
```
kubectl get secret -A | grep pinniped-addon
```
2. 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
```
3. Elimine los secretos que contienen:
  - type: tkg.tanzu.vmware.com/addon: estos son secretos de clústeres heredados
  - cualquier configuración de OIDC o LDAP
```
kubectl delete secret SECRET-NAME
```
  Donde SECRET-NAME es el valor de metadata.name establecido en la especificación Secret.

Qué hacer a continuación

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:

Para configurar RBAC para el clúster de administración, siga las instrucciones de Configurar RBAC para un clúster de administración.
Después de completar los pasos de este tema, puede comenzar a crear clústeres de carga de trabajo. Para configurar RBAC para los clústeres de carga de trabajo, siga las instrucciones de Configurar RBAC para un clúster de carga de trabajo.

Configurar la administración de identidades

Acerca de la habilitación y configuración de la administración de identidades

(Recomendado) Habilitar y configurar la administración de identidades durante la implementación del clúster de administración

Obtener los detalles del proveedor de identidad

Ejemplo: Registrar una aplicación Tanzu Kubernetes Grid en Okta

Configurar los ajustes de LDAPS u OIDC en Tanzu Kubernetes Grid

Completar la configuración de administración de identidades

Conectar kubectl al clúster de administración

Comprobar el estado de un servicio de administración de identidades de OIDC

Comprobar el estado de un servicio de administración de identidades LDAP

(Solo OIDC) Proporcionar el URI de devolución de llamada al proveedor de OIDC

Configurar RBAC para el clúster de administración

Habilitar y configurar la administración de identidades en una implementación existente

Obtener los detalles del proveedor de identidad

Generar el secreto de complemento Pinniped para el clúster de administración

Completar la configuración de administración de identidades

Habilitar la administración de identidades en clústeres de carga de trabajo

Autenticar usuarios en una máquina sin navegador

Actualizar la configuración de Dex después de la implementación del clúster de administración

Desactivar la administración de identidades en una implementación existente

Qué hacer a continuación

Conectar `kubectl` al clúster de administración