Share via

Conecte los certificados CA para el complemento de malla de servicios basado en Istio en el servicio Azure Kubernetes

  • Artículo

En el addon de malla de servicios basado en Istio para el servicio Azure Kubernetes, por defecto la autoridad de certificación (CA) de Istio genera un certificado raíz y una clave autofirmados y los utiliza para firmar los certificados de la carga de trabajo. Para proteger la clave de entidad de certificación raíz, debe usar una ENTIDAD de certificación raíz, que se ejecuta en una máquina segura sin conexión. Puede usar la entidad de certificación raíz para emitir certificados intermedios a las CA de Istio que se ejecutan en cada clúster. Una CA de Istio puede firmar certificados de carga de trabajo mediante el certificado y la clave especificados por el administrador, y distribuir un certificado raíz especificado por el administrador a las cargas de trabajo como raíz de confianza. En este artículo se explica cómo traer sus propios certificados y claves para la entidad de certificación de Istio en el complemento de malla de servicio basado en Istio para Azure Kubernetes Service.

Diagrama que muestra la CA raíz e intermedia con Istio.

En este artículo se explica cómo configurar la entidad de certificación de Istio con un certificado raíz, un certificado de firma y una clave proporcionados como entradas mediante Azure Key Vault en el complemento de malla de servicio basado en Istio.

Antes de empezar

Comprobación de la versión de la CLI de Azure

El complemento requiere tener instalada la versión 2.57.0 o posterior de la CLI de Azure. Puede ejecutar az --version para comprobar la versión. Para instalar o actualizar, consulte [Instalar Azure CLI][azure-cli-install].

Configuración de Azure Key Vault

  1. Necesita un recurso de Azure Key Vault para proporcionar el certificado y las entradas de clave al complemento Istio.

  2. Debe generar el certificado raíz, los certificados intermedios, la clave intermedia y la cadena de certificados sin conexión. Los pasos 1-3 a partir de aquí tienen un ejemplo de cómo generar estos archivos.

  3. Cree secretos en Azure Key Vault mediante los certificados y la clave:

    az keyvault secret set --vault-name $AKV_NAME --name root-cert --file <path-to-folder/root-cert.pem>
az keyvault secret set --vault-name $AKV_NAME --name ca-cert --file <path-to-folder/ca-cert.pem>
az keyvault secret set --vault-name $AKV_NAME --name ca-key --file <path-to-folder/ca-key.pem>
az keyvault secret set --vault-name $AKV_NAME --name cert-chain --file <path/cert-chain.pem>

  4. Habilite el proveedor de Azure Key Vault para el controlador de Secret Store de CSI para el clúster:

    az aks enable-addons --addons azure-keyvault-secrets-provider --resource-group $RESOURCE_GROUP --name $CLUSTER

    Nota:

    Al rotar certificados, para controlar la rapidez con la que se sincronizan los secretos con el clúster, puede usar el --rotation-poll-interval parámetro del complemento Proveedor de secretos de Azure Key Vault. Por ejemplo: az aks addon update --resource-group $RESOURCE_GROUP --name $CLUSTER --addon azure-keyvault-secrets-provider --enable-secret-rotation --rotation-poll-interval 20s

  5. Autorice a la identidad administrada asignada por el usuario del complemento para que tenga acceso al recurso de Azure Key Vault:

    OBJECT_ID=$(az aks show --resource-group $RESOURCE_GROUP --name $CLUSTER --query 'addonProfiles.azureKeyvaultSecretsProvider.identity.objectId' -o tsv)

az keyvault set-policy --name $AKV_NAME --object-id $OBJECT_ID --secret-permissions get list

    Nota:

    Si creó una instancia de Key Vault con la autorización de Azure RBAC para el modelo de permisos, en lugar de la directiva de acceso de Key Vault, siga las instrucciones que se indican aquí para crear permisos para la identidad administrada. Agregue una asignación de roles de Azure para Key Vault Reader para la identidad administrada asignada por el usuario del complemento.

Configurar el complemento de malla de servicios basado en Istio con certificados CA de complemento

  1. Habilite el complemento de malla del servicio Istio para el clúster de AKS existente mientras hace referencia a los secretos de Azure Key Vault que se crearon anteriormente:

    az aks mesh enable --resource-group $RESOURCE_GROUP --name $CLUSTER \
--root-cert-object-name root-cert \
--ca-cert-object-name ca-cert \
--ca-key-object-name ca-key \
--cert-chain-object-name cert-chain \
--key-vault-id /subscriptions/$SUBSCRIPTION/resourceGroups/$RESOURCE_GROUP/providers/Microsoft.KeyVault/vaults/$AKV_NAME

    Nota:

    Para los clústeres existentes con el complemento Istio que utilizan un certificado raíz autofirmado generado por la CA de Istio, el cambio a la CA del complemento no es compatible. Primero debe deshabilitar la malla en estos clústeres y, a continuación, habilitarla de nuevo con el comando anterior para pasar por las entradas de ca del complemento.

  2. Compruebe que se cacerts crea en el clúster:

    kubectl get secret -n aks-istio-system

    Resultado esperado:

    NAME                                                         TYPE                 DATA   AGE
cacerts                                                      opaque               4      13h
sh.helm.release.v1.azure-service-mesh-istio-discovery.v380   helm.sh/release.v1   1      2m15s
sh.helm.release.v1.azure-service-mesh-istio-discovery.v381   helm.sh/release.v1   1      8s

  3. Compruebe que el plano de control de Istio ha recogido la entidad de certificación personalizada:

    kubectl logs deploy/istiod-asm-1-17 -c discovery -n aks-istio-system | grep -v validationController | grep x509

    La salida esperada debe ser similar a:

    2023-11-06T15:49:15.493732Z     info    x509 cert - Issuer: "CN=Intermediate CA - A1,O=Istio,L=cluster-A1", Subject: "", SN: e191d220af347c7e164ec418d75ed19e, NotBefore: "2023-11-06T15:47:15Z", NotAfter: "2033-11-03T15:49:15Z"
2023-11-06T15:49:15.493764Z     info    x509 cert - Issuer: "CN=Root A,O=Istio", Subject: "CN=Intermediate CA - A1,O=Istio,L=cluster-A1", SN: 885034cba2894f61036f2956fd9d0ed337dc636, NotBefore: "2023-11-04T01:40:02Z", NotAfter: "2033-11-01T01:40:02Z"
2023-11-06T15:49:15.493795Z     info    x509 cert - Issuer: "CN=Root A,O=Istio", Subject: "CN=Root A,O=Istio", SN: 18e2ee4089c5a7363ec306627d21d9bb212bed3e, NotBefore: "2023-11-04T01:38:27Z", NotAfter: "2033-11-01T01:38:27Z"

Rotación de la entidad de certificación

Es posible que tenga que rotar periódicamente las entidades de certificación por motivos de seguridad o directiva. En esta sección se explica cómo controlar los escenarios intermedios de rotación de ca y ca raíz.

Rotación intermedia de la entidad de certificación

  1. Puede rotar la entidad de certificación intermedia mientras mantiene la ca raíz igual. Actualice los secretos en el recurso de Azure Key Vault con los nuevos archivos de certificado y clave:

    az keyvault secret set --vault-name $AKV_NAME --name root-cert --file <path-to-folder/root-cert.pem>
az keyvault secret set --vault-name $AKV_NAME --name ca-cert --file <path-to-folder/ca-cert.pem>
az keyvault secret set --vault-name $AKV_NAME --name ca-key --file <path-to-folder/ca-key.pem>
az keyvault secret set --vault-name $AKV_NAME --name cert-chain --file <path/cert-chain.pem>

  2. Espere la duración del tiempo de --rotation-poll-interval. Compruebe si el cacerts secreto se actualizó en el clúster en función de la nueva entidad de certificación intermedia que se actualizó en el recurso de Azure Key Vault:

    kubectl logs deploy/istiod-asm-1-17 -c discovery -n aks-istio-system | grep -v validationController

    La salida esperada debe ser similar a:

    2023-11-07T06:16:21.091844Z     info    Update Istiod cacerts
2023-11-07T06:16:21.091901Z     info    Using istiod file format for signing ca files
2023-11-07T06:16:21.354423Z     info    Istiod has detected the newly added intermediate CA and updated its key and certs accordingly
2023-11-07T06:16:21.354910Z     info    x509 cert - Issuer: "CN=Intermediate CA - A2,O=Istio,L=cluster-A2", Subject: "", SN: b2753c6a23b54d8364e780bf664672ce, NotBefore: "2023-11-07T06:14:21Z", NotAfter: "2033-11-04T06:16:21Z"
2023-11-07T06:16:21.354967Z     info    x509 cert - Issuer: "CN=Root A,O=Istio", Subject: "CN=Intermediate CA - A2,O=Istio,L=cluster-A2", SN: 17f36ace6496ac2df88e15878610a0725bcf8ae9, NotBefore: "2023-11-04T01:40:22Z", NotAfter: "2033-11-01T01:40:22Z"
2023-11-07T06:16:21.355007Z     info    x509 cert - Issuer: "CN=Root A,O=Istio", Subject: "CN=Root A,O=Istio", SN: 18e2ee4089c5a7363ec306627d21d9bb212bed3e, NotBefore: "2023-11-04T01:38:27Z", NotAfter: "2033-11-01T01:38:27Z"
2023-11-07T06:16:21.355012Z     info    Istiod certificates are reloaded

  3. Las cargas de trabajo reciben certificados del plano de control de Istio que son válidos durante 24 horas de forma predeterminada. Si no reinicia los pods, todas las cargas de trabajo obtienen nuevos certificados hoja en función de la nueva entidad de certificación intermedia en 24 horas. Si desea forzar que todas estas cargas de trabajo obtengan nuevos certificados hoja inmediatamente después de la nueva entidad de certificación intermedia, debe reiniciar las cargas de trabajo.

    kubectl rollout restart deployment <deployment name> -n <deployment namespace>

Rotación de la autoridad de certificación raíz

  1. Debe actualizar los secretos de Azure Key Vault con el archivo de certificado raíz que tiene la concatenación de los certificados raíz antiguos y los nuevos certificados raíz:

    az keyvault secret set --vault-name $AKV_NAME --name root-cert --file <path-to-folder/root-cert.pem>
az keyvault secret set --vault-name $AKV_NAME --name ca-cert --file <path-to-folder/ca-cert.pem>
az keyvault secret set --vault-name $AKV_NAME --name ca-key --file <path-to-folder/ca-key.pem>
az keyvault secret set --vault-name $AKV_NAME --name cert-chain --file <path/cert-chain.pem>

    El contenido de root-cert.pem sigue este formato:

    -----BEGIN CERTIFICATE-----
<contents of old root certificate>
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
<contents of new root certificate>
-----END CERTIFICATE-----

    El complemento incluye una CronJob ejecución cada diez minutos en el clúster para comprobar si hay actualizaciones en el certificado raíz. Si detecta una actualización, reinicia el plano de control de Istio (istiod implementación) para recoger las actualizaciones. Puede comprobar sus registros para confirmar que se detectó la actualización del certificado raíz y que se ha reiniciado el plano de control de Istio:

    kubectl logs -n aks-istio-system $(kubectl get pods -n aks-istio-system | grep 'istio-cert-validator-cronjob-' | sort -k8 | tail -n 1 | awk '{print $1}')

    Resultado esperado:

    Root certificate update detected. Restarting deployment...
deployment.apps/istiod-asm-1-17 restarted
Deployment istiod-asm-1-17 restarted.

    Después istiod de reiniciarse, debe indicar que se agregaron dos certificados al dominio de confianza:

    kubectl logs deploy/istiod-asm-1-17 -c discovery -n aks-istio-system

    Resultado esperado:

    2023-11-07T06:42:00.287916Z     info    Using istiod file format for signing ca files
2023-11-07T06:42:00.287928Z     info    Use plugged-in cert at etc/cacerts/ca-key.pem
2023-11-07T06:42:00.288254Z     info    x509 cert - Issuer: "CN=Intermediate CA - A2,O=Istio,L=cluster-A2", Subject: "", SN: 286451ca8ff7bf9e6696f56bef829d42, NotBefore: "2023-11-07T06:40:00Z", NotAfter: "2033-11-04T06:42:00Z"
2023-11-07T06:42:00.288279Z     info    x509 cert - Issuer: "CN=Root A,O=Istio", Subject: "CN=Intermediate CA - A2,O=Istio,L=cluster-A2", SN: 17f36ace6496ac2df88e15878610a0725bcf8ae9, NotBefore: "2023-11-04T01:40:22Z", NotAfter: "2033-11-01T01:40:22Z"
2023-11-07T06:42:00.288298Z     info    x509 cert - Issuer: "CN=Root A,O=Istio", Subject: "CN=Root A,O=Istio", SN: 18e2ee4089c5a7363ec306627d21d9bb212bed3e, NotBefore: "2023-11-04T01:38:27Z", NotAfter: "2033-11-01T01:38:27Z"
2023-11-07T06:42:00.288303Z     info    Istiod certificates are reloaded
2023-11-07T06:42:00.288365Z     info    spiffe  Added 2 certs to trust domain cluster.local in peer cert verifier

  2. Debe esperar 24 horas (la hora predeterminada para la validez del certificado hoja) o forzar un reinicio de todas las cargas de trabajo. De este modo, todas las cargas de trabajo reconocen tanto las entidades de certificación antiguas como las nuevas para la comprobación de mTLS.

    kubectl rollout restart deployment <deployment name> -n <deployment namespace>

  3. Ahora puede actualizar los secretos de Azure Key Vault solo con la nueva CA de (sin la CA anterior):

    az keyvault secret set --vault-name $AKV_NAME --name root-cert --file <path-to-folder/root-cert.pem>
az keyvault secret set --vault-name $AKV_NAME --name ca-cert --file <path-to-folder/ca-cert.pem>
az keyvault secret set --vault-name $AKV_NAME --name ca-key --file <path-to-folder/ca-key.pem>
az keyvault secret set --vault-name $AKV_NAME --name cert-chain --file <path/cert-chain.pem>

    Compruebe los registros de CronJob para confirmar la detección de la actualización del certificado raíz y el reinicio de istiod:

    kubectl logs -n aks-istio-system $(kubectl get pods -n aks-istio-system | grep 'istio-cert-validator-cronjob-' | sort -k8 | tail -n 1 | awk '{print $1}')

    Resultado esperado:

    Root certificate update detected. Restarting deployment...
deployment.apps/istiod-asm-1-17 restarted
Deployment istiod-asm-1-17 restarted.

    Después istiod de actualizarse, solo debe confirmar el uso de la nueva CA raíz:

    kubectl logs deploy/istiod-asm-1-17 -c discovery -n aks-istio-system | grep -v validationController

    Resultado esperado:

    2023-11-07T08:01:17.780299Z     info    x509 cert - Issuer: "CN=Intermediate CA - B1,O=Istio,L=cluster-B1", Subject: "", SN: 1159747c72cc7ac7a54880cd49b8df0a, NotBefore: "2023-11-07T07:59:17Z", NotAfter: "2033-11-04T08:01:17Z"
2023-11-07T08:01:17.780330Z     info    x509 cert - Issuer: "CN=Root B,O=Istio", Subject: "CN=Intermediate CA - B1,O=Istio,L=cluster-B1", SN: 2aba0c438652a1f9beae4249457023013948c7e2, NotBefore: "2023-11-04T01:42:12Z", NotAfter: "2033-11-01T01:42:12Z"
2023-11-07T08:01:17.780345Z     info    x509 cert - Issuer: "CN=Root B,O=Istio", Subject: "CN=Root B,O=Istio", SN: 3f9da6ddc4cb03749c3f43243a4b701ce5eb4e96, NotBefore: "2023-11-04T01:41:54Z", NotAfter: "2033-11-01T01:41:54Z"

    En las salidas de ejemplo que se muestran en este artículo, puede observar que se ha movido de raíz A (que se usa al habilitar el complemento) a raíz B.

  4. Puede esperar de nuevo 24 horas o forzar un reinicio de todas las cargas de trabajo. Forzar un reinicio hace que las cargas de trabajo obtengan nuevos certificados hoja de la nueva CA raíz inmediatamente.

    kubectl rollout restart deployment <deployment name> -n <deployment namespace>