Partager via

Plug-in de certificats d’autorité de certification pour le module complémentaire de maillage de services Istio sur Azure Kubernetes Service

  • Article

Dans le module complémentaire de maillage de services Istio pour Azure Kubernetes Service, l’autorité de certification Istio génère par défaut un certificat racine autosigné et une clé, qu’elle utilise pour signer les certificats de charge de travail. Pour protéger la clé d’autorité de certification racine, vous devez utiliser une autorité de certification racine, qui s’exécute sur une machine sécurisée hors connexion. Vous pouvez utiliser l’autorité de certification racine pour émettre des certificats intermédiaires aux autorités de certification Istio qui s’exécutent dans chaque cluster. Une autorité de certification Istio peut signer des certificats de charge de travail à l’aide du certificat et de la clé spécifiés par l’administrateur, et distribuer un certificat racine spécifié par l’administrateur aux charges de travail comme racine d’approbation. Cet article explique comment apporter vos propres certificats et clés pour l’autorité de certification Istio dans le module complémentaire de maillage de services istio pour Azure Kubernetes Service.

Diagramme montrant l’autorité de certification racine et intermédiaire avec Istio.

Cet article explique comment configurer l’autorité de certification Istio avec un certificat racine, signer un certificat et une clé fournis en tant qu’entrées à l’aide d’Azure Key Vault pour le module complémentaire de maillage de service Istio.

Avant de commencer

Vérifier la version d’Azure CLI

Le module complémentaire nécessite l’installation d’Azure CLI version 2.57.0 ou ultérieure. Vous pouvez exécuter az --version pour vérifier la version. Pour effectuer l’installation ou la mise à niveau, consultez [Installer Azure CLI][azure-cli-install].

Configurer Azure Key Vault

  1. Vous avez besoin d’une ressource Azure Key Vault pour fournir le certificat et les entrées de clé au module complémentaire Istio.

  2. Vous devez générer un certificat racine, des certificats intermédiaires, une clé intermédiaire et la chaîne de certificats hors connexion. Les étapes 1 à 3 de ici ont un exemple de génération de ces fichiers.

  3. Créez des secrets dans Azure Key Vault à l’aide des certificats et de la clé :

    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-to-folder/cert-chain.pem>

  4. Activez fournisseur Azure Key Vault pour secret Store CSI Driver for your cluster:

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

    Remarque

    Lors de la rotation des certificats, pour contrôler la rapidité de synchronisation des secrets sur le cluster, vous pouvez utiliser le paramètre --rotation-poll-interval du module complémentaire fournisseur de secrets Azure Key Vault. Par exemple : az aks addon update --resource-group $RESOURCE_GROUP --name $CLUSTER --addon azure-keyvault-secrets-provider --enable-secret-rotation --rotation-poll-interval 20s

  5. Autoriser l’identité managée affectée par l’utilisateur du module complémentaire à avoir accès à la ressource 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

    Remarque

    Si vous avez créé votre coffre de clés avec l’autorisation RBAC Azure pour votre modèle d’autorisation au lieu de la stratégie d’accès au coffre, suivez les instructions ici pour créer des autorisations pour l’identité managée. Ajoutez une attribution de rôle pour Key Vault Reader pour l’identité managée affectée par l’utilisateur du module complémentaire.

Configurer un module complémentaire de maillage de service basé sur Istio avec des certificats d’autorité de certification de plug-in

  1. Activez le module complémentaire Istio Service Mesh pour votre cluster AKS existant tout en référençant les secrets Azure Key Vault créés précédemment :

    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

    Remarque

    Pour les clusters existants avec le module complémentaire Istio à l’aide du certificat racine auto-signé généré par l’autorité de certification Istio, le passage à l’autorité de certification du plug-in n’est pas pris en charge. Vous devez d’abord désactiver le maillage sur ces clusters, puis l’activer à nouveau à l’aide de la commande ci-dessus pour passer les entrées de l’autorité de certification du plug-in.

  2. Vérifiez que le cacerts est créé sur le cluster :

    kubectl get secret -n aks-istio-system

    Sortie attendue :

    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. Vérifiez que le plan de contrôle Istio a récupéré l’autorité de certification personnalisée :

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

    La sortie attendue doit être similaire à :

    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"

Rotation de l’autorité de certification

Vous devrez peut-être faire pivoter régulièrement les autorités de certification pour des raisons de sécurité ou de stratégie. Cette section vous explique comment gérer les scénarios de rotation de l’autorité de certification intermédiaire et de l’autorité de certification racine.

Rotation de l’autorité de certification intermédiaire

  1. Vous pouvez faire pivoter l’autorité de certification intermédiaire tout en conservant l’autorité de certification racine la même. Mettez à jour les secrets dans la ressource Azure Key Vault avec les nouveaux fichiers de certificat et de clé :

    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. Attendez la durée de --rotation-poll-interval. Vérifiez si le secret cacerts a été actualisé sur le cluster en fonction de la nouvelle autorité de certification intermédiaire mise à jour sur la ressource Azure Key Vault :

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

    La sortie attendue doit être similaire à :

    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. Les charges de travail reçoivent des certificats du plan de contrôle Istio valides pendant 24 heures par défaut. Si vous ne redémarrez pas les pods, toutes les charges de travail obtiennent de nouveaux certificats feuille en fonction de la nouvelle autorité de certification intermédiaire en 24 heures. Si vous souhaitez forcer toutes ces charges de travail à obtenir de nouveaux certificats feuille immédiatement à partir de la nouvelle autorité de certification intermédiaire, vous devez redémarrer les charges de travail.

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

Rotation de l’autorité de certification racine

  1. Vous devez mettre à jour les secrets Azure Key Vault avec le fichier de certificat racine ayant la concaténation de l’ancien et du nouveau certificat racine :

    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>

    Le contenu de root-cert.pem suivez ce format :

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

    Le module complémentaire inclut une CronJob s’exécutant toutes les dix minutes sur le cluster pour rechercher les mises à jour du certificat racine. S’il détecte une mise à jour, il redémarre le plan de contrôle Istio (istiod déploiement) pour récupérer les mises à jour. Vous pouvez vérifier ses journaux pour vérifier que la mise à jour du certificat racine a été détectée et que le plan de contrôle Istio a été redémarré :

    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}')

    Sortie attendue :

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

    Une fois istiod redémarré, il doit indiquer que deux certificats ont été ajoutés au domaine d’approbation :

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

    Sortie attendue :

    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. Vous devez attendre 24 heures (heure par défaut pour la validité du certificat feuille) ou forcer un redémarrage de toutes les charges de travail. Ainsi, toutes les charges de travail reconnaissent l’ancienne et la nouvelle autorité de certification pour vérification mTLS.

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

  3. Vous pouvez maintenant mettre à jour les secrets Azure Key Vault avec uniquement la nouvelle autorité de certification (sans l’ancienne autorité de certification) :

    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>

    Vérifiez les journaux de l' CronJob pour confirmer la détection de la mise à jour du certificat racine et le redémarrage 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}')

    Sortie attendue :

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

    Une fois istiod mis à jour, il ne doit confirmer que l’utilisation de la nouvelle autorité de certification racine :

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

    Sortie attendue :

    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"

    Dans les exemples de sorties présentés dans cet article, vous pouvez observer que nous sommes déplacés de la racine A (utilisée lors de l’activation du module complémentaire) vers la racine B.

  4. Vous pouvez attendre de nouveau 24 heures ou forcer un redémarrage de toutes les charges de travail. Forcer un redémarrage rend les charges de travail obtenir immédiatement de nouveaux certificats feuille à partir de la nouvelle autorité de certification racine.

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