Partager via


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

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 installer ou mettre à niveau Azure CLI, 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 ici comportent 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 le pilote Secrets Store CSI pour votre 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. Si votre coffre de clés utilise Azure RBAC pour le modèle d’autorisations, suivez les instructions ici pour attribuer un rôle Azure de Key Vault Secrets User à l'identité gérée attribuée par l'utilisateur du module complémentaire. Sinon, si votre coffre de clés utilise le modèle d’autorisations de stratégie d’accès au coffre, autorisez l’identité managée affectée par l’utilisateur du module complémentaire à accéder à la ressource Azure Key Vault à l’aide de la stratégie d’accès :

    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
    

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

  1. Activez le module complémentaire de maillage de service Istio 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 utilisant le certificat racine autosigné 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 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

Régulièrement, vous pouvez être amené à procéder à une rotation des 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.

Autorité de l'autorité de certification intermédiaire

  1. Vous pouvez remplacer l’autorité de certification intermédiaire tout en conservant la même autorité de certification racine. 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 les certificats ont été actualisés 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 dans les 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 suit ce format :

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

    Vérifiez les journaux istiod une fois les certificats synchronisés avec le cluster.

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

    Sortie attendue :

    2023-11-07T06:42:00.287916Z     info    Updating new ROOT-CA
    2023-11-07T06:42:00.287928Z     info    update root cert and generate new dns certs
    2023-11-07T06:42:00.288254Z     info    Update trust anchor with new root cert
    2023-11-07T06:42:00.288279Z     info    trustBundle     updating Source IstioCA with certs
    2023-11-07T06:42:00.288298Z     info    Istiod has detected the newly added intermediate CA and updated its key and certs accordingly
    2023-11-07T06:42:00.288303Z     info    Istiod certificates are reloaded
    
  2. Vous devez attendre 24 heures (durée 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 la vérification de 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 istiod une fois les certificats synchronisés avec le cluster.

    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 passés de la racine A (utilisée lors de l’activation du module complémentaire) à la racine B.