Tutorial: Protección de los métodos de implementación para la extensión del registro conectado

En estos tutoriales se tratan varios escenarios de implementación para la extensión del registro conectado en un clúster de Kubernetes habilitado para Arc. Una vez instalada la extensión del registro conectado, puede sincronizar imágenes desde el registro en la nube a ubicaciones locales o remotas.

Antes de profundizar, dedique un momento a aprender cómo funciona Kubernetes habilitado para Arc conceptualmente.

El registro conectado se puede implementar de forma segura mediante varios métodos de cifrado. Para garantizar una implementación correcta, siga la guía de inicio rápido para revisar los requisitos previos y otra información pertinente. De manera predeterminada, el registro conectado se configura con HTTPS, modo ReadOnly, Distribución de confianza y el servicio Administrador de certificados. Puede agregar más personalizaciones y dependencias según sea necesario, en función de su escenario.

¿Qué es el servicio Administrador de certificados?

El administrador de certificados del registro conectado es un servicio que administra certificados TLS para la extensión del registro conectada en un clúster de Kubernetes habilitado para Azure Arc. Garantiza una comunicación segura entre el registro conectado y otros componentes mediante el control de la creación, renovación y distribución de certificados. Este servicio se puede instalar como parte de la implementación del registro conectado o puede usar un administrador de certificados existente si ya está instalado en el clúster.

Cert-Manager es un complemento de Kubernetes de código abierto que automatiza la administración y emisión de certificados TLS de varios orígenes. Administra el ciclo de vida de los certificados emitidos por los grupos de CA creados mediante el servicio ca, lo que garantiza que son válidos y renovados antes de que expiren.

¿Qué es la distribución de confianza?

La distribución de confianza del registro conectado hace referencia al proceso de distribución segura de confianza entre el servicio de registro conectado y los clientes de Kubernetes dentro de un clúster. Esto se logra mediante el uso de una entidad de certificación (CA), como cert-manager, para firmar certificados TLS, que luego se distribuyen tanto al servicio del registro como a los clientes. Esto garantiza que todas las entidades se puedan autenticar de forma segura, manteniendo un entorno seguro y de confianza dentro del clúster de Kubernetes.

Requisitos previos

Para completar este tutorial, necesita:

• Siga el inicio rápido para implementar de forma segura la extensión del registro conectado.

Implementación de la extensión del registro conectado mediante el administrador de certificados preinstalado

En este tutorial, se muestra cómo usar un servicio cert-manager preinstalado en el clúster. Esta configuración le proporciona control sobre la administración de certificados, lo que le permite implementar la extensión del registro conectado con cifrado siguiendo los pasos proporcionados:

Ejecute el comando az-k8s-extension-create en el inicio rápido y establezca los parámetros cert-manager.enabled=true y cert-manager.install=false para determinar que el servicio cert-manager está instalado y habilitado:

    az k8s-extension create --cluster-name myarck8scluster \ 
    --cluster-type connectedClusters \ 
    --extension-type Microsoft.ContainerRegistry.ConnectedRegistry \ 
    --name myconnectedregistry \ 
    --resource-group myresourcegroup \ 
    --config service.clusterIP=192.100.100.1 \ 
    --config cert-manager.install=false \ 
    --config-protected-file protected-settings-extension.json

Implementación de la extensión del registro conectado mediante bring your own certificate (BYOC)

En este tutorial, se muestra cómo usar su propio certificado (BYOC) en el clúster. BYOC permite usar su propio certificado público y par de claves privadas, lo que le proporciona control sobre la administración de certificados. Esta configuración le permite implementar la extensión del registro conectado con cifrado siguiendo los pasos proporcionados:

Nota:

BYOC es aplicable a los clientes que traigan su propio certificado que ya es de confianza para sus nodos de Kubernetes. No se recomienda actualizar manualmente los nodos para confiar en los certificados.

Siga el inicio rápido y agregue el certificado público y la variable de cadena de clave privada + par valor.

1. Creación de un certificado SSL autofirmado con la dirección IP del servicio de registro conectado como SAN

  mkdir /certs

openssl req -newkey rsa:4096 -nodes -sha256 -keyout /certs/mycert.key -x509 -days 365 -out /certs/mycert.crt -addext "subjectAltName = IP:<service IP>"

2. Obtención de cadenas codificadas en base64 de estos archivos de certificado

export TLS_CRT=$(cat mycert.crt | base64 -w0) 
export TLS_KEY=$(cat mycert.key | base64 -w0) 

3. Ejemplo de archivo de configuración protegida con secreto en formato JSON:

Nota:

El certificado público y el par de claves privadas deben codificarse en formato base64 y agregarse al archivo de configuración protegido.

    {
    "connectionString": "[connection string here]",
    "tls.crt": $TLS_CRT,
    "tls.key": $TLS_KEY,
    "tls.cacrt": $TLS_CRT
    } 

4. Ahora, puede implementar la extensión del Registro conectado con HTTPS (cifrado TLS) mediante el certificado público y la administración de pares de claves privadas configurando variables establecidas en cert-manager.enabled=false y cert-manager.install=false. Con estos parámetros, cert-manager no está instalado o habilitado, ya que el certificado público y el par de claves privadas se usan en su lugar para el cifrado.

5. Ejecute el comando az-k8s-extension-createpara la implementación después de editar el archivo de configuración protegido:

   az k8s-extension create --cluster-name myarck8scluster \
   --cluster-type connectedClusters \  
   --extension-type  Microsoft.ContainerRegistry.ConnectedRegistry \ 
   --name myconnectedregistry \ 
   --resource-group myresourcegroup \
   --config service.clusterIP=192.100.100.1 \
   --config cert-manager.enabled=false \
   --config cert-manager.install=false \ 
   --config-protected-file protected-settings-extension.json 
   

Implementación del registro conectado con la administración de secretos de Kubernetes

En este tutorial, se muestra cómo usar un secreto de Kubernetes en el clúster. El secreto de Kubernetes permite administrar de forma segura el acceso autorizado entre pods dentro del clúster. Esta configuración le permite implementar la extensión del registro conectado con cifrado siguiendo los pasos proporcionados:

Siga el inicio rápido y agregue la variable de cadena secreta TLS de Kubernetes + enlazar valor.

1. Creación de un certificado SSL autofirmado con la dirección IP del servicio de registro conectado como SAN

mkdir /certs

openssl req -newkey rsa:4096 -nodes -sha256 -keyout /certs/mycert.key -x509 -days 365 -out /certs/mycert.crt -addext "subjectAltName = IP:<service IP>"

2. Obtención de cadenas codificadas en base64 de estos archivos de certificado

export TLS_CRT=$(cat mycert.crt | base64 -w0) 
export TLS_KEY=$(cat mycert.key | base64 -w0) 

3. Creación de un secreto k8s

cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Secret
metadata:
  name: k8secret
  type: kubernetes.io/tls
data:
  ca.crt: $TLS_CRT
  tls.crt: $TLS_CRT
  tls.key: $TLS_KEY
EOF

4. Ejemplo de archivo de configuración protegida con secreto en formato JSON:

       { 
       "connectionString": "[connection string here]",
       "tls.secret": “k8secret” 
       } 
   

Ahora, puede implementar la extensión del registro conectado con HTTPS (cifrado TLS) mediante la administración de secretos de Kubernetes mediante la configuración de variables establecidas en cert-manager.enabled=false y cert-manager.install=false. Con estos parámetros, cert-manager no está instalado o habilitado, ya que el secreto de Kubernetes se usa en su lugar para el cifrado.

5. Ejecute el comando az-k8s-extension-createpara la implementación después de editar el archivo de configuración protegido:

   az k8s-extension create --cluster-name myarck8scluster \
   --cluster-type connectedClusters \  
   --extension-type  Microsoft.ContainerRegistry.ConnectedRegistry \ 
   --name myconnectedregistry \ 
   --resource-group myresourcegroup \
   --config service.clusterIP=192.100.100.1 \
   --config cert-manager.enabled=false \
   --config cert-manager.install=false \ 
   --config-protected-file protected-settings-extension.json 
   

Implemente el registro conectado mediante su propia distribución de confianza y deshabilite la distribución de confianza predeterminada del registro conectado

En este tutorial, se muestra cómo configurar la distribución de confianza en el clúster. Al usar su propio secreto de Kubernetes o pares de claves públicas y privadas, puede implementar la extensión del Registro conectado con el cifrado TLS, la distribución de confianza inherente y rechazar la distribución de confianza predeterminada del registro conectado. Esta configuración le permite implementar la extensión del registro conectado con cifrado siguiendo los pasos proporcionados:

1. Siga el inicio rápido para agregar el secreto de Kubernetes o el certificado público, y los pares de variables de clave privada + valor en el archivo de configuración protegido en formato JSON.

2. Ejecute el comando az-k8s-extension-create en inicio rápido y establezca los parámetros trustDistribution.enabled=false, trustDistribution.skipNodeSelector=false para rechazar la distribución de confianza del Registro conectado:

   az k8s-extension create --cluster-name myarck8scluster \ 
   --cluster-type connectedClusters \ 
   --extension-type Microsoft.ContainerRegistry.ConnectedRegistry \ 
   --name myconnectedregistry \ 
   --resource-group myresourcegroup \ 
   --config service.clusterIP=192.100.100.1 \
   --config trustDistribution.enabled=false \ 
   --config cert-manager.enabled=false \
   --config cert-manager.install=false \ 
   --config-protected-file <JSON file path> 
   

Con estos parámetros, cert-manager no está instalado ni habilitado, además, no se aplica la distribución de confianza del Registro conectado. En su lugar, usa la distribución de confianza proporcionada por el clúster para establecer la confianza entre el registro conectado y los nodos de cliente.

Limpieza de recursos

Al eliminar la extensión del Registro conectado implementada, se quitan los pods del Registro conectado y las opciones de configuración correspondientes.

1. Ejecute el comando az-k8s-extension-delete para eliminar la extensión del Registro conectado:

   az k8s-extension delete --name myconnectedregistry 
   --cluster-name myarcakscluster \ 
   --resource-group myresourcegroup \ 
   --cluster-type connectedClusters
   

2. Ejecute el comando az acr connected-registry delete para eliminar el registro conectado:

   az acr connected-registry delete --registry myacrregistry \ 
   --name myconnectedregistry \ 
   --resource-group myresourcegroup
   

Al eliminar la extensión del Registro conectado y el Registro conectado, se quitan todos los recursos y configuraciones asociados.

Pasos siguientes

• Habilitación del registro conectado con la CLI de Azure Arc
• Actualización del registro conectado con Azure Arc
• Sincronización del registro conectado con Azure Arc en la ventana Programada
• Solución de problemas del registro conectado con Azure Arc
• Glosario de términos