Administrar secretos del clúster

En este tema se explica cómo configurar y administrar secretos utilizados por los clústeres de carga de trabajo en Tanzu Kubernetes Grid, entre los que se incluyen:

Credenciales que los clústeres utilizan para acceder a los recursos y las API de la infraestructura de nube. Consulte Actualizar credenciales de los clústeres.
Certificados de cliente que utilizan los componentes del clúster interno para autenticar solicitudes (solo clústeres de carga de trabajo implementados en clústeres de administración independientes). Consulte Renovar certificados de clústeres.
Certificados de entidad de certificación (CA) que los clústeres utilizan para acceder a registros de contenedores privados. Consulte Configurar clústeres con varios registros de confianza y Agregar la confianza del certificado de CA personalizado a clústeres existentes.
Credenciales que los clústeres utilizan para acceder a registros de contenedores privados autenticados. Consulte Configurar la autenticación en un registro de contenedores privado.

Actualizar credenciales de clúster

Si cambian las credenciales que utiliza para acceder a vSphere o Azure, puede actualizar los clústeres para que usen las nuevas credenciales. AWS controla las credenciales de forma diferente, por lo que esta sección solo se aplica a vSphere y Azure.

vSphere

Actualizar credenciales de clúster de carga de trabajo y administración independiente

Para actualizar las credenciales de vSphere utilizadas por el clúster de administración independiente actual y por todos sus clústeres de carga de trabajo, utilice el comando tanzu mc credentials update --cascading:

Ejecute tanzu context use MGMT-CLUSTER para iniciar sesión en el clúster de administración que va a actualizar.
Ejecute tanzu mc credentials update. Puede transferir valores a las siguientes opciones de comando o permitir que la CLI le solicite:
- --vsphere-user: Nombre de la cuenta de vSphere.
- --vsphere-password: Contraseña de la cuenta de vSphere.
- --vsphere-thumbprint: Huella digital TLS de la instancia de vCenter Server.

Actualizar solo las credenciales del clúster de administración independiente

Para actualizar las credenciales de vSphere de un clúster de administración independiente sin actualizarlas también para sus clústeres de carga de trabajo, utilice el comando tanzu mc credentials update como se indica anteriormente, pero sin la opción --cascading.

Actualizar credenciales del clúster de carga de trabajo

Para actualizar las credenciales que utiliza un único clúster de carga de trabajo para acceder a vSphere, utilice el comando tanzu cluster credentials update:

Ejecute tanzu context use MGMT-CLUSTER para iniciar sesión en el clúster de administración que creó el clúster de carga de trabajo que va a actualizar. El clúster de administración puede ser el clúster supervisor o el clúster de administración independiente.
Ejecute tanzu cluster credentials update CLUSTER-NAME. Puede transferir valores a las siguientes opciones de comando o permitir que la CLI le solicite:
- --namespace: El espacio de nombres del clúster para el que está actualizando las credenciales como default.
- --vsphere-user: Nombre de la cuenta de vSphere.
- --vsphere-password: Contraseña de la cuenta de vSphere.
- --vsphere-thumbprint: Huella digital TLS de la instancia de vCenter Server.

También puede utilizar tanzu mc credentials update --cascading para actualizar las credenciales de vSphere para un clúster de administración y todos los clústeres de carga de trabajo que administra.

AWS

Esta sección no se aplica a las implementaciones de AWS.

Azure

Actualizar credenciales de clúster de carga de trabajo y administración independiente

Importante
Antes de comenzar, obtenga las nuevas credenciales de Azure del portal de Azure o del administrador de Azure.

Para actualizar las credenciales de Azure utilizadas por el clúster de administración independiente actual y por todos sus clústeres de carga de trabajo, utilice el comando tanzu mc credentials update --cascading:

Ejecute tanzu context use MGMT-CLUSTER para iniciar sesión en el clúster de administración que va a actualizar.
Ejecute tanzu mc credentials update. Puede transferir valores a las siguientes opciones de comando o permitir que la CLI le solicite:
- --azure-client-id: El identificador de cliente de la aplicación para Tanzu Kubernetes Grid que registró en Azure.
- --azure-client-secret: El secreto de cliente de la aplicación para Tanzu Kubernetes Grid que registró en Azure.
- --azure-tenant-id: El identificador de tenant para Active Directory de Azure en el que se encuentra la aplicación para Tanzu Kubernetes Grid.

Actualizar solo las credenciales del clúster de administración independiente

Para actualizar las credenciales de Azure de un clúster de administración independiente sin actualizarlas también para sus clústeres de carga de trabajo, utilice el comando tanzu mc credentials update como se indica anteriormente, pero sin la opción --cascading.

Actualizar credenciales del clúster de carga de trabajo

Para actualizar las credenciales que utiliza un único clúster de carga de trabajo para acceder a Azure, utilice el comando tanzu cluster credentials update:

Ejecute tanzu context use MGMT-CLUSTER para iniciar sesión en el clúster de administración que creó el clúster de carga de trabajo que va a actualizar.
Ejecute tanzu cluster credentials update CLUSTER-NAME. Puede transferir valores a las siguientes opciones de comando o permitir que la CLI le solicite:
- --namespace: El espacio de nombres del clúster para el que está actualizando las credenciales como default.
- --azure-client-id: El identificador de cliente de la aplicación para Tanzu Kubernetes Grid que registró en Azure.
- --azure-client-secret: El secreto de cliente de la aplicación para Tanzu Kubernetes Grid que registró en Azure.
- --azure-tenant-id: El identificador de tenant para Active Directory de Azure en el que se encuentra la aplicación para Tanzu Kubernetes Grid.

También puede utilizar tanzu mc credentials update --cascading para actualizar las credenciales de Azure para un clúster de administración y todos los clústeres de carga de trabajo que administra.

Renovación automática de certificados del nodo del plano de control

Configure los clústeres de TKG para renovar automáticamente sus certificados de máquina virtual de nodo del plano de control de la siguiente manera, según el método de configuración y el tipo de clúster:

Especificación de objeto de estilo Kubernetes (clústeres basados en clases):
- En la especificación del objeto Cluster, incluya el siguiente bloque en spec.topology.variables:
```
- name: controlPlaneCertificateRotation.activate
value: true
- name: controlPlaneCertificateRotation.daysBefore
value: EXPIRY-DAYS
```
Archivo de configuración del clúster plano (clústeres basados en clases o heredados):
- En el archivo de configuración del clúster, incluya los siguientes ajustes:
```
CONTROLPLANE_CERTIFICATE_ROTATION_ENABLED: true
CONTROLPLANE_CERTIFICATE_ROTATION_DAYS_BEFORE: EXPIRY-DAYS
```

Donde EXPIRY-DAYS es un ajuste opcional para el número de días antes de la fecha de caducidad del certificado para renovar automáticamente los certificados del nodo de clúster. Predeterminado: 90; mínimo: 7.

Renovar certificados de clúster (MC independiente)

La administración independiente y sus clústeres de carga de trabajo utilizan certificados de cliente para autenticar solicitudes. Estos certificados son válidos durante un año. Para renovarlos, puede actualizar los clústeres o seguir el procedimiento que se indica a continuación. Este procedimiento está destinado a certificados de clúster que no han caducado y siguen siendo válidos.

Identifique el clúster para el que desea renovar sus certificados. Por ejemplo:

tanzu cluster list
NAME                 NAMESPACE  STATUS   CONTROLPLANE  WORKERS  KUBERNETES         ROLES   PLAN  TKR
workload-slot35rp10  default    running  3/3           3/3      v1.27.5+vmware.1  <none>  prod  v1.27.5---vmware.2-tkg.1

Para ver una lista de los nodos del clúster, ejecute:

kubectl get nodes -o wide

Compruebe la fecha de caducidad de los certificados:

vSphere

Ejecute el siguiente comando.

kubectl get nodes \
-o jsonpath='{.items[*].status.addresses[?(@.type=="ExternalIP")].address}' \
-l node-role.kubernetes.io/master= > nodes

for i in `cat nodes`; do
   printf "\n######\n"
   ssh -o "StrictHostKeyChecking=no" -q capv@$i hostname
   ssh -o "StrictHostKeyChecking=no" -q capv@$i sudo kubeadm certs check-expiration
done;

AWS

Ejecute el siguiente comando.

kubectl get nodes \
-o jsonpath='{.items[*].status.addresses[?(@.type=="InternalIP")].address}' \
-l node-role.kubernetes.io/master= > nodes

for i in `cat nodes`; do
    printf "\n######\n"
    ssh -i aws-cluster-key.pem -o "StrictHostKeyChecking=no" -q ubuntu@$i hostname
    ssh -i aws-cluster-key.pem -o "StrictHostKeyChecking=no" -q ubuntu@$i sudo kubeadm certs check-expiration
done;

Azure

Ejecute el siguiente comando.

kubectl get nodes \
-o jsonpath='{.items[*].status.addresses[?(@.type=="InternalIP")].address}' \
-l node-role.kubernetes.io/master= > nodes

for i in `cat nodes`; do
    printf "\n######\n"
    ssh -i azure-cluster-key.pem -o "StrictHostKeyChecking=no" -q capi@$i hostname
    ssh -i azure-cluster-key.pem -o "StrictHostKeyChecking=no" -q capi@$i sudo kubeadm certs check-expiration
done;

Resultados de muestra:

######
workload-slot35rp10-control-plane-ggsmj
[check-expiration] Reading configuration from the cluster...
[check-expiration] FYI: You can look at this config file with 'kubectl -n kube-system get cm kubeadm-config -o yaml'
W0923 17:51:03.686273 4172778 utils.go:69] The recommended value for "resolvConf" in "KubeletConfiguration" is: /run/systemd/resolve/resolv.conf; the provided value is: /run/systemd/resolve/resolv.conf

CERTIFICATE                EXPIRES                  RESIDUAL TIME   CERTIFICATE AUTHORITY   EXTERNALLY MANAGED
admin.conf                 Sep 21, 2023 23:13 UTC   363d            ca                      no
apiserver                  Sep 21, 2023 23:13 UTC   363d            ca                      no
apiserver-etcd-client      Sep 21, 2023 23:13 UTC   363d            etcd-ca                 no
apiserver-kubelet-client   Sep 21, 2023 23:13 UTC   363d            ca                      no
controller-manager.conf    Sep 21, 2023 23:13 UTC   363d            ca                      no
etcd-healthcheck-client    Sep 21, 2023 23:13 UTC   363d            etcd-ca                 no
etcd-peer                  Sep 21, 2023 23:13 UTC   363d            etcd-ca                 no
etcd-server                Sep 21, 2023 23:13 UTC   363d            etcd-ca                 no
front-proxy-client         Sep 21, 2023 23:13 UTC   363d            front-proxy-ca          no
scheduler.conf             Sep 21, 2023 23:13 UTC   363d            ca                      no

CERTIFICATE AUTHORITY   EXPIRES                  RESIDUAL TIME   EXTERNALLY MANAGED
ca                      Sep 18, 2032 23:09 UTC   9y              no
etcd-ca                 Sep 18, 2032 23:09 UTC   9y              no
front-proxy-ca          Sep 18, 2032 23:09 UTC   9y              no

Establezca el contexto kubectl en el clúster de administración. Por ejemplo:
```
kubectl config use-context mgmt-slot35rp10-admin@mgmt-slot35rp10
```

Obtenga el nombre del objeto de KCP para el clúster de destino. Por ejemplo:

kubectl get kcp

NAME                                CLUSTER               INITIALIZED   API SERVER AVAILABLE   REPLICAS   READY   UPDATED   UNAVAILABLE   AGE   VERSION
workload-slot35rp10-control-plane   workload-slot35rp10   true          true                   3          3       3         0             42h   v1.27.5+vmware.1

Renueve los certificados activando un lanzamiento del plano de control:

kubectl patch kcp workload-slot35rp10-control-plane --type merge -p "{\"spec\":{\"rolloutAfter\":\"`date +'%Y-%m-%dT%TZ'`\"}}

Después de ejecutar este comando, Tanzu Kubernetes Grid comienza a aprovisionar de nuevo las máquinas del clúster:

kubectl get machines

workload-slot35rp10-control-plane-7z95k     workload-slot35rp10                                                                                                Provisioning   20s   v1.27.5+vmware.1
workload-slot35rp10-control-plane-ggsmj     workload-slot35rp10   workload-slot35rp10-control-plane-ggsmj     vsphere://4201a86e-3c15-879a-1b85-78f76a16c27f   Running        42h   v1.27.5+vmware.1
workload-slot35rp10-control-plane-hxbxb     workload-slot35rp10   workload-slot35rp10-control-plane-hxbxb     vsphere://42014b2e-07e4-216a-24ef-86e2d52d7bbd   Running        42h   v1.27.5+vmware.1
workload-slot35rp10-control-plane-sm4nw     workload-slot35rp10   workload-slot35rp10-control-plane-sm4nw     vsphere://4201cff3-2715-ffe1-c4a6-35fc795995ce   Running        42h   v1.27.5+vmware.1
workload-slot35rp10-md-0-667bcd6b57-79br9   workload-slot35rp10   workload-slot35rp10-md-0-667bcd6b57-79br9   vsphere://420142a2-d141-7d6b-b322-9c2afcc47da5   Running        42h   v1.27.5+vmware.1
...

Cuando todas las máquinas estén Running, compruebe que la renovación del certificado se haya completado correctamente:

Establezca el contexto kubectl en el clúster de carga de trabajo:

kubectl config use-context workload-slot35rp10-admin@workload-slot35rp10

Vuelva a comprobar la fecha de caducidad de los certificados:

kubectl get nodes \
-o jsonpath='{.items[*].status.addresses[?(@.type=="ExternalIP")].address}' \
-l node-role.kubernetes.io/master= > nodes

for i in `cat nodes`; do
  printf "\n######\n"
  ssh -o "StrictHostKeyChecking=no" -q capv@$i hostname
  ssh -o "StrictHostKeyChecking=no" -q capv@$i sudo kubeadm certs check-expiration
done;

Resultados de muestra:

######
workload-slot35rp10-control-plane-4xgw8
[check-expiration] Reading configuration from the cluster...
[check-expiration] FYI: You can look at this config file with 'kubectl -n kube-system get cm kubeadm-config -o yaml'

W0923 18:10:02.660438   13427 utils.go:69] The recommended value for "resolvConf" in "KubeletConfiguration" is: /run/systemd/resolve/resolv.conf; the provided value is: /run/systemd/resolve/resolv.conf
CERTIFICATE                EXPIRES                  RESIDUAL TIME   CERTIFICATE AUTHORITY   EXTERNALLY MANAGED
admin.conf                 Sep 23, 2023 18:05 UTC   364d            ca                      no
apiserver                  Sep 23, 2023 18:05 UTC   364d            ca                      no
apiserver-etcd-client      Sep 23, 2023 18:05 UTC   364d            etcd-ca                 no
apiserver-kubelet-client   Sep 23, 2023 18:05 UTC   364d            ca                      no
controller-manager.conf    Sep 23, 2023 18:05 UTC   364d            ca                      no
etcd-healthcheck-client    Sep 23, 2023 18:05 UTC   364d            etcd-ca                 no
etcd-peer                  Sep 23, 2023 18:05 UTC   364d            etcd-ca                 no
etcd-server                Sep 23, 2023 18:05 UTC   364d            etcd-ca                 no
front-proxy-client         Sep 23, 2023 18:05 UTC   364d            front-proxy-ca          no
scheduler.conf             Sep 23, 2023 18:05 UTC   364d            ca                      no

CERTIFICATE AUTHORITY   EXPIRES                  RESIDUAL TIME   EXTERNALLY MANAGED
ca                      Sep 18, 2032 23:09 UTC   9y              no
etcd-ca                 Sep 18, 2032 23:09 UTC   9y              no
front-proxy-ca          Sep 18, 2032 23:09 UTC   9y              no

Si la renovación del certificado se completó correctamente, la columna Residual Time muestra 364d. Los certificados en los nodos de trabajo se renuevan automáticamente.

Configurar clústeres con registros de confianza (supervisor)

Para configurar un clúster de TKG implementado por Supervisor para que use un registro de contenedores privado externo a TKG, es decir, un registro con un certificado autofirmado que no se ejecuta en un clúster de TKG, consulte los siguientes temas en la documentación de vSphere:

vSphere 8: Integrar un clúster de TKG 2 con un registro de contenedores privado
vSphere 7: Usar un registro de contenedores externo con clústeres de Tanzu Kubernetes

Configurar clústeres con varios registros de confianza (MC independiente)

En un entorno restringido por Internet con un clúster de administración independiente, puede configurar variables TKG_CUSTOM_IMAGE_REPOSITORY_* para conceder a los clústeres de TKG acceso a un registro privado que contenga imágenes del sistema de TKG desde las que arrancar, por ejemplo, una máquina virtual de Harbor como se describe en Implementar un registro de Harbor sin conexión en vSphere.

Las variables ADDITIONAL_IMAGE_REGISTRY_* configuran un nuevo clúster para que tenga comunicaciones de confianza con registros adicionales que usan certificados de entidad de certificación (CA) autofirmados, por ejemplo:

Un registro privado que funciona como repositorio de paquetes para instalar paquetes administrados por CLI.
Un registro de Harbor escalable y autofirmado para imágenes de aplicaciones alojadas en TKG, implementado con el paquete de Harbor como se describe en Instalar Harbor para el registro de servicios.
Un registro de imágenes autofirmado para containerd como se describe en Configurar registro de imágenes en el repositorio containerd.

La forma en que se configuran los clústeres para que confíen en estos registros privados adicionales depende de si el clúster está basado en planes o en clases, como se describe a continuación.

Registros de confianza para un clúster basado en clases

Para configurar un clúster de carga de trabajo basado en clases o un clúster de administración independiente con confianza para registros de imágenes personalizados adicionales, configure las variables como se indica a continuación para un máximo de tres registros de imágenes adicionales:

Para configurar más de tres registros, configure los tres primeros como se indica a continuación en el paso 1 de un proceso de dos pasos descrito en Crear un clúster basado en clases y, a continuación, siga Hacer que un clúster basado en clases confíe en un registro personalizado a continuación para agregar más registros al manifiesto generado antes de crear el clúster en el paso 2.
```
ADDITIONAL_IMAGE_REGISTRY_1: "OTHER-REGISTRY-1"
ADDITIONAL_IMAGE_REGISTRY_1_SKIP_TLS_VERIFY: false
ADDITIONAL_IMAGE_REGISTRY_1_CA_CERTIFICATE: "CA-BASE64-1"

ADDITIONAL_IMAGE_REGISTRY_2: "OTHER-REGISTRY-2"
ADDITIONAL_IMAGE_REGISTRY_2_SKIP_TLS_VERIFY: false
ADDITIONAL_IMAGE_REGISTRY_2_CA_CERTIFICATE: "CA-BASE64-2"

ADDITIONAL_IMAGE_REGISTRY_3: "OTHER-REGISTRY-3"
ADDITIONAL_IMAGE_REGISTRY_3_SKIP_TLS_VERIFY: false
ADDITIONAL_IMAGE_REGISTRY_3_CA_CERTIFICATE: "CA-BASE64-3"
```
Donde OTHER-REGISTRY-<n> es la dirección IP o el FQDN de un registro privado adicional y CA-BASE64-<n> es su certificado de CA en formato codificado en base64, sin el prefijo http://. Esto es necesario porque este archivo se escribirá en el disco, por lo que debe ser un nombre de archivo Unix normal.

Registros de confianza para un nuevo clúster basado en planes

Para habilitar un nuevo TKC o un clúster basado en planes para extraer imágenes de registros de contenedores que usan certificados autofirmados, agregue los certificados personalizados a los nodos del clúster de carga de trabajo mediante un archivo de superposición ytt.

El código de superposición a continuación agrega certificados de CA personalizados a todos los nodos de un clúster nuevo. El código funciona en todas las plataformas de destino de nube para clústeres basados en plantillas de imagen de máquina virtual de Ubuntu o Photon.

Para las superposiciones que personalizan clústeres y crean un nuevo plan de clúster, consulte Superposicionesytt . Para obtener información sobre cómo descargar e instalar ytt, consulte Instalar Carvel Tools.

Elija si desea aplicar la CA personalizada a todos los clústeres nuevos, solo los creados en una infraestructura de nube o los creados con una versión específica del proveedor de API del clúster, como Proveedor de API del clúster vSphere v1.5.1.
En el directorio local ~/.config/tanzu/tkg/providers/ busque el directorio ytt que abarca el ámbito seleccionado. Por ejemplo, /ytt/03_customizations/ se aplica a todos los clústeres y /infrastructure-vsphere/ytt/ se aplica a todos los clústeres de vSphere.

En el directorio ytt elegido, cree un nuevo archivo .yaml o amplíe un archivo de superposición existente con el siguiente código:

#@ load("@ytt:overlay", "overlay")
#@ load("@ytt:data", "data")

#! This ytt overlay adds additional custom CA certificates on TKG cluster nodes, so containerd and other tools trust these CA certificates.
#! It works when using Photon or Ubuntu as the TKG node template on all TKG target platforms.

#! Trust your custom CA certificates on all Control Plane nodes.
#@overlay/match by=overlay.subset({"kind":"KubeadmControlPlane"})
---
spec:
  kubeadmConfigSpec:
    #@overlay/match missing_ok=True
    files:
      #@overlay/append
      - content: #@ data.read("tkg-custom-ca.pem")
        owner: root:root
        permissions: "0644"
        path: /etc/ssl/certs/tkg-custom-ca.pem
    #@overlay/match missing_ok=True
    preKubeadmCommands:
      #! For Photon OS
      #@overlay/append
      - '! which rehash_ca_certificates.sh 2>/dev/null || rehash_ca_certificates.sh'
      #! For Ubuntu
      #@overlay/append
      - '! which update-ca-certificates 2>/dev/null || (mv /etc/ssl/certs/tkg-custom-ca.pem /usr/local/share/ca-certificates/tkg-custom-ca.crt && update-ca-certificates)'

#! Trust your custom CA certificates on all worker nodes.
#@overlay/match by=overlay.subset({"kind":"KubeadmConfigTemplate"}), expects="1+"
---
spec:
  template:
    spec:
      #@overlay/match missing_ok=True
      files:
        #@overlay/append
        - content: #@ data.read("tkg-custom-ca.pem")
          owner: root:root
          permissions: "0644"
          path: /etc/ssl/certs/tkg-custom-ca.pem
      #@overlay/match missing_ok=True
      preKubeadmCommands:
        #! For Photon OS
        #@overlay/append
        - '! which rehash_ca_certificates.sh 2>/dev/null || rehash_ca_certificates.sh'
        #! For Ubuntu
        #@overlay/append
        - '! which update-ca-certificates 2>/dev/null || (mv /etc/ssl/certs/tkg-custom-ca.pem /usr/local/share/ca-certificates/tkg-custom-ca.crt && update-ca-certificates)'

En el mismo directorio ytt, agregue la entidad de certificación a un archivo tkg-custom-ca.pem nuevo o existente.
Antes de crear el clúster, establezca la función allow-legacy-cluster en true como se describe en (heredado) Crear un clúster basado en planes o un clúster de TKC.

Agregar la confianza del certificado de CA personalizado a clústeres existentes (MC independiente)

Puede habilitar la comunicación de confianza entre un clúster existente y registros de Harbor personalizados adicionales con CA autofirmadas, además de las establecidas por las variables de configuración TKG_CUSTOM_IMAGE_REPOSITORY_*, para TLS containerd y otros usos. La forma de hacerlo depende de si el clúster está basado en planes o en clases, como se describe a continuación.

Hacer que un clúster basado en clases confíe en un registro personalizado

Para agregar un registro personalizado de confianza a un clúster basado en clases existente, edite su objeto Cluster y agregue la configuración additionalImageRegistries en topology.variables en la especificación de objeto:

topology:
  variables:
  - name: additionalImageRegistries
    value:
    - caCert: "CA-BASE64"
      host: OTHER-REGISTRY
      skipTlsVerify: false

Donde:

OTHER-REGISTRY es la ubicación del registro privado adicional, que sigue el formato : . Por ejemplo, 10.92.127.192:8443.
CA-BASE64 es su certificado CA en formato codificado en base64, por ejemplo, LS0tLS1CRU[...].

Para agregar confianza a varios registros, incluya varios bloques de valores additionalImageRegistries.

Tenga en cuenta que los bloques topology.variables para imageRepository y trust establecen valores a partir de las variables de configuración TKG_CUSTOM_IMAGE_REPOSITORY_* y TKG_PROXY_CA_CERT.

Hacer que un clúster basado en planes confíe en un registro personalizado

Para habilitar la confianza entre un clúster basado en un plan existente y un registro de Harbor con una CA autofirmada:

Recupere el certificado de CA de Harbor:

Cambie el contexto al clúster que ejecuta Harbor, como un clúster de servicios compartidos:
```
kubectl config use-context SERVICES-CLUSTER-CONTEXT
```
DondeSERVICES-CLUSTER-CONTEXT es el contexto del clúster. Por ejemplo, tkg-wld-admin@tkg-wld.

Recupere el certificado:

kubectl -n tanzu-system-registry get secret harbor-tls -o=jsonpath="{.data.ca\.crt}" | base64 -d
-----BEGIN CERTIFICATE-----
MIIFazCCA1OgAwIBAgIQMfZy08muvIVKdZVDz7/rYzANBgkqhkiG9w0BAQsFADBI
[...]
yiDghW7antzYL9S1CC8sVgVOwFJwfFXpdiir35mQlySG301V4FsRV+Z0cFp4Ni0=
-----END CERTIFICATE-----

Agregue la CA personalizada al clúster de administración independiente kubeadmconfigtemplate:

Cambie el contexto al clúster de administración.
```
kubectl config use-context MANAGEMENT-CLUSTER-CONTEXT
```
Donde MANAGEMENT-CLUSTER-CONTEXT es el contexto del clúster de administración. Por ejemplo, tkg-mgmt-admin@tkg-mgmt.
En un editor, abra el archivo de plantilla kubeadmconfigtemplate del clúster:
```
kubectl edit kubeadmconfigtemplate CLUSTER-NAME-md-0
```
Donde CLUSTER-NAME es el nombre del clúster que debe modificarse.

Cambie la sección spec.template.spec.files del archivo para incluir el certificado, como se muestra aquí:

spec:
template:
  spec:
    files:
    - content: |
          -----BEGIN CERTIFICATE-----
         MIIFazCCA1OgAwIBAgIQMfZy08muvIVKdZVDz7/rYzANBgkqhkiG9w0BAQsFADBI
         [...]
         yiDghW7antzYL9S1CC8sVgVOwFJwfFXpdiir35mQlySG301V4FsRV+Z0cFp4Ni0=
         -----END CERTIFICATE-----
       owner: root:root
       path: /etc/ssl/certs/tkg-custom-ca.pem
       permissions: "0644"

En la parte inferior del archivo, agregue un bloque preKubeadmCommands como se muestra aquí:

preKubeadmCommands:
- '! which rehash_ca_certificates.sh 2>/dev/null || rehash_ca_certificates.sh'
- '! which update-ca-certificates 2>/dev/null || (mv /etc/ssl/certs/tkg-custom-ca.pem
   /usr/local/share/ca-certificates/tkg-custom-ca.crt && update-ca-certificates)'

Guarde el archivo de plantilla kubeadmconfigtemplate con los cambios.
Aplique las revisiones al clúster de administración independiente con los cambios siguientes:
```
kubectl patch machinedeployments.cluster.x-k8s.io tkg-test-md-0 --type merge -p "{\"spec\":{\"template\":{\"metadata\":{\"annotations\":{\"date\":\"`date +'%s'`\"}}}}}"
```
Al ejecutar este comando, se activa una actualización gradual de los nodos del clúster y se actualiza su marca de tiempo.

Configurar la autenticación en un registro de contenedores privado

Puede agregar secretos de autenticación para permitir que un clúster acceda a un registro de contenedor privado, lo que requiere autenticación del usuario para extraer imágenes. También puede ver, actualizar o eliminar los secretos de autenticación que configuró para los registros privados a los que accede un clúster.

Agregar un secreto de autenticación para un registro de contenedor privado

En la CLI de Tanzu puede agregar secretos de autenticación para acceder a un registro de contenedores privado desde un clúster. Después de agregar el secreto de registro a los espacios de nombres del clúster, puede extraer todos los repositorios de paquetes, los paquetes y las imágenes de contenedor que están alojados en el registro privado. Posteriormente, puede agregar el repositorio de paquetes y los recursos de paquetes al clúster.

Antes de realizar este procedimiento obtenga el nombre de usuario y la contraseña del registro de contenedores privado.

Para agregar un secreto de autenticación a un registro privado, ejecute el siguiente comando:

tanzu secret registry add SECRET-NAME -n NAMESPACE --server REGISTRY-URL --username USERNAME --password PASSWORD

Donde:

SECRET-NAME es el nombre del secreto de autenticación del registro que desea agregar.
NAMESPACE es el espacio de nombres de Tanzu Kubernetes Grid al que pertenece el registro.
USERNAME es el nombre de usuario para acceder al registro. Ponga el nombre de usuario entre comillas simples si contiene caracteres especiales.
PASSWORD es la contraseña para acceder al registro. Ponga la contraseña entre comillas simples si contiene caracteres especiales. También puede especificar la contraseña en los siguientes formatos:
- Reemplace la cadena --password PASSWORD en el comando por --password-env-var ENV-VAR para especificar la contraseña a través de la variable de entorno que ya configuró. El formato del comando es el siguiente:
  
  tanzu secret registry add SECRET-NAME -n NAMESPACE --server REGISTRY-URL --username USERNAME --password-env-var ENV-VAR
- Reemplace la cadena --password PASSWORD en el comando por la cadena --password-stdin para especificar la contraseña a través de la entrada estándar e introduzca la contraseña cuando se le solicite. El formato del comando es el siguiente:
  
  tanzu secret registry add SECRET-NAME -n NAMESPACE --server REGISTRY-URL --username USERNAME --password-stdin
- Reemplace la cadena --password PASSWORD en el comando por la cadena --password-file PASSWORD-FILE para especificar la contraseña a través de un archivo de contraseñas. El formato del comando es el siguiente:
  
  tanzu secret registry add SECRET-NAME -n NAMESPACE --server REGISTRY-URL --username USERNAME --password-file PASSWORD-FILE

De forma opcional, para que el secreto de registro esté disponible en todos los espacios de nombres de un clúster, utilice la opción --export-to-all-namespaces como se muestra en el siguiente formato:

tanzu secret registry add SECRET-NAME -n NAMESPACE --server REGISTRY-URL --username USERNAME --password PASSWORD --export-to-all-namespaces

A continuación se muestra un ejemplo de resultados de este comando:

tanzu secret registry add tanzu-net -n test-ns --server registry.pivotal.io --username test-user --password-file pass-file --export-to-all-namespaces
Warning: By choosing --export-to-all-namespaces, given secret contents will be available to ALL users in ALL namespaces. Please ensure that included registry credentials allow only read-only access to the registry with minimal necessary scope.
/ Adding registry secret 'test-secret'...
  Added registry secret 'test-secret' into namespace 'test-ns'

Ver los secretos de autenticación del registro en un clúster

Puede ver los secretos de autenticación del registro en el espacio de nombres predeterminado o en todos los espacios de nombres de un clúster. Puede ver los secretos en forma de una tabla o un archivo JSON o YAML.

Para ver los secretos de autenticación del registro en un espacio de nombres específico de un clúster, ejecute lo siguiente:

tanzu secret registry list -n NAMESPACE

Donde NAMESPACE es el espacio de nombres de Tanzu Kubernetes Grid al que pertenece el registro.

A continuación se muestra un ejemplo de este comando:

tanzu secret registry list -n test-ns
/ Retrieving registry secrets...
  NAME         REGISTRY                 EXPORTED           AGE
  pkg-dev-reg  registry.pivotal.io      to all namespaces  15d

Para ver la lista de secretos de autenticación del registro en todos los espacios de nombres de un clúster, ejecute lo siguiente:

tanzu secret registry list -A

A continuación se muestra un ejemplo de este comando:

tanzu secret registry list -A
\ Retrieving registry secrets...
 NAME                          REGISTRY             EXPORTED           AGE  NAMESPACE
 pkg-dev-reg                   registry.pivotal.io  to all namespaces  15d  test-ns
 tanzu-standard-fetch-0        registry.pivotal.io  not exported       15d  tanzu-package-repo-global
 private-repo-fetch-0          registry.pivotal.io  not exported       15d  test-ns
 antrea-fetch-0                registry.pivotal.io  not exported       15d  tkg-system
 metrics-server-fetch-0        registry.pivotal.io  not exported       15d  tkg-system
 tanzu-addons-manager-fetch-0  registry.pivotal.io  not exported       15d  tkg-system
 tanzu-core-fetch-0            registry.pivotal.io  not exported       15d  tkg-system

Para ver la lista de secretos de autenticación del registro en formato de archivo JSON, ejecute el siguiente comando:

tanzu secret registry list -n kapp-controller-packaging-global -o json

A continuación se muestra un ejemplo de este comando:

tanzu secret registry list -n kapp-controller-packaging-global -o json
[
 {
   "age": "15d",
   "exported": "to all namespaces",
   "name": "pkg-dev-reg",
   "registry": "us-east4-docker.pkg.dev"
 }
]

Para ver la lista de secretos de autenticación del registro en formato de archivo YAML, ejecute lo siguiente:

tanzu secret registry list -n kapp-controller-packaging-global -o yaml

A continuación se muestra un ejemplo de este comando:

 tanzu secret registry list -n kapp-controller-packaging-global -o yaml
 - age: 15d
   exported: to all namespaces
   name: pkg-dev-reg
   registry: us-east4-docker.pkg.dev

Para ver la lista de secretos de autenticación del registro en formato de tabla, ejecute lo siguiente:

tanzu secret registry list -n kapp-controller-packaging-global -o table

A continuación se muestra un ejemplo de este comando:

tanzu secret registry list -n kapp-controller-packaging-global -o table
/ Retrieving registry secrets...
  NAME         REGISTRY                 EXPORTED           AGE
  pkg-dev-reg  us-east4-docker.pkg.dev  to all namespaces  15d

Actualizar un secreto de autenticación del registro

Puede actualizar las credenciales en un secreto y hacer que un secreto esté disponible en todos los espacios de nombres o ponerlo a disposición solo en un espacio de nombres del clúster.

Para actualizar el secreto en el espacio de nombres en el que se creó, ejecute el siguiente comando:

tanzu secret registry update SECRET-NAME --username USERNAME -n NAMESPACE --password PASSWORD

Donde:

SECRET-NAME es el nombre del secreto del registro que desea actualizar.
NAMESPACE es el espacio de nombres de Tanzu Kubernetes Grid donde se actualiza el secreto de autenticación del registro.
USERNAME es el nuevo nombre de usuario para acceder al registro (si desea actualizar el nombre de usuario).
PASSWORD es la nueva contraseña del registro (si desea actualizar la contraseña).

Nota
Puede actualizar el nombre de usuario o la contraseña o ambos.

A continuación se muestra un ejemplo de este comando:

tanzu secret registry update test-secret --username test-user -n test-ns --password-env-var PASSENV
\ Updating registry secret 'test-secret'...
 Updated registry secret 'test-secret' in namespace 'test-ns'

Para actualizar el secreto de autenticación del registro y ponerlo a disposición en otros espacios de nombres del clúster, ejecute el siguiente comando:

tanzu secret registry update SECRET-NAME --username USERNAME -n NAMESPACE --password PASSWORD --export-to-all-namespaces=true

Donde:

SECRET-NAME es el nombre del secreto del registro que desea actualizar.
NAMESPACE es el espacio de nombres de Tanzu Kubernetes Grid donde se actualiza el secreto de autenticación del registro.
USERNAME es el nombre de usuario para acceder al registro. Introduzca un nuevo nombre de usuario si desea actualizar el nombre de usuario.
PASSWORD es la contraseña del registro. Introduzca una nueva contraseña si desea actualizar la contraseña.

A continuación se muestra un ejemplo de este comando:

tanzu secret registry update test-secret--username test-user -n test-ns --password-env-var PASSENV --export-to-all-namespaces=true
Warning: By specifying --export-to-all-namespaces as true, given secret contents will be available to ALL users in ALL namespaces. Please ensure that included registry credentials allow only read-only access to the registry with minimal necessary scope.
Are you sure you want to proceed? [y/N]: y

\ Updating registry secret 'test-secret'...
  Updated registry secret 'test-secret' in namespace 'test-ns'
  Exported registry secret 'test-secret' to all namespaces

Para que un secreto de autenticación del registro no esté disponible en otros espacios de nombres del clúster, ejecute el siguiente comando:

tanzu secret registry update SECRET-NAME --username USERNAME -n NAMESPACE --password PASSWORD --export-to-all-namespaces=false

Donde:

SECRET-NAME es el nombre del secreto del registro que desea actualizar.
NAMESPACE es el espacio de nombres de Tanzu Kubernetes Grid donde se actualiza el secreto de autenticación del registro.
USERNAME es el nombre de usuario para acceder al registro.
PASSWORD es la contraseña del registro.

A continuación se muestra un ejemplo de este comando:

tanzu secret registry update test-secret --username test-user -n test-ns --password-env-var PASSENV --export-to-all-namespaces=false
Warning: By specifying --export-to-all-namespaces as false, the secret contents will get unexported from ALL namespaces in which it was previously available to.
Are you sure you want to proceed? [y/N]: y

\ Updating registry secret 'test-secret'...
  Updated registry secret 'test-secret' in namespace 'test-ns'
  Unexported registry secret 'test-secret' from all namespaces

Eliminar un secreto de autenticación del registro

Con la CLI de Tanzu, puede eliminar un secreto de autenticación del registro en un clúster. Para eliminar un secreto de autenticación del registro en un espacio de nombres específico, ejecute el siguiente comando:

tanzu secret registry delete SECRET-NAME -n NAMESPACE

Donde:

SECRET-NAME es el nombre del secreto del registro que desea eliminar.
(Opcional) NAMESPACE es el espacio de nombres de Tanzu Kubernetes Grid del que desea eliminar el secreto de autenticación del registro. Si no especifica un espacio de nombres, el secreto de autenticación se elimina del espacio de nombres predeterminado. Si el secreto se exportó a otros espacios de nombres del clúster, también se elimina.

A continuación se muestra un ejemplo de este comando:

tanzu secret registry delete test-secret -n test-ns
Deleting registry secret 'test-secret' from namespace 'test-ns'. Are you sure? [y/N]: y
\ Deleting registry secret 'test-secret'...
 Deleted registry secret 'test-secret' from namespace 'test-ns'