Utiliser des autorités de certification personnalisées dans Azure Kubernetes Service (AKS)

L'Autorité de Certification Personnalisée vous permet d’ajouter jusqu’à 10 certificats codés en base64 dans le magasin de confiance de votre nœud. Cette fonctionnalité est souvent nécessaire lorsque les autorités de certification doivent être présentes sur le nœud, comme lors de la connexion à un registre privé.

Cet article vous présente comment créer des autorités de certification personnalisées et les appliquer à vos clusters AKS.

Note

La fonctionnalité d’autorité de certification personnalisée ajoute vos certificats personnalisés au stock de confiance du nœud AKS. Les certificats ajoutés avec cette fonctionnalité ne sont pas disponibles pour les conteneurs fonctionnant dans des pods. Si vous avez besoin des certificats à l’intérieur des conteneurs, vous devez les ajouter séparément en les ajoutant à l’image utilisée par vos pods ou au moment de l’exécution via un script et un secret.

Prerequisites

  • Un abonnement Azure. Si vous n’avez pas d’abonnement Azure, créez un compte gratuit.
  • Azure CLI version 2.72.0 ou ultérieure installée et configurée. Pour rechercher votre version de l’interface CLI, exécutez la az --version commande. Si vous devez installer ou mettre à niveau, voir Installer Azure CLI.
  • Chaîne de certificat encodée en base64 ou fichier texte avec certificat.

Limitations

  • Les pools de nœuds Windows ne sont pas pris en charge.
  • L’installation de différentes autorités de certification dans le même cluster n’est pas prise en charge.

Créer un fichier de certificat

  • Créez un fichier texte contenant jusqu’à 10 certificats séparés par une ligne vide. Lorsque vous transmettez ce fichier à votre cluster, les certificats sont installés dans les magasins de confiance du nœud AKS.

    Exemple de fichier texte :

        -----BEGIN CERTIFICATE-----
    cert1
    -----END CERTIFICATE-----

    -----BEGIN CERTIFICATE-----
    cert2
    -----END CERTIFICATE-----

Avant de passer à l’étape suivante, assurez-vous qu’il n’y a pas d’espaces vides dans votre fichier texte pour éviter les erreurs.

Transmettez des autorités de certification personnalisées à votre cluster AKS

  • Passez des certificats à votre cluster en utilisant la commande az aks create ou az aks update avec --custom-ca-trust-certificates défini sur le nom de votre fichier de certificat.

    # Create a new cluster
az aks create \
    --resource-group <resource-group-name> \
    --name <cluster-name> \
    --node-count 2 \
    --custom-ca-trust-certificates <path-to-certificate-file> \
    --generate-ssh-keys

# Update an existing cluster
az aks update \
    --resource-group <resource-group-name> \
    --name <cluster-name> \
    --custom-ca-trust-certificates <path-to-certificate-file>

    Note

    Cette opération déclenche une mise à jour de modèle pour garantir que tous les nœuds existants disposent des mêmes autorités de certification installées pour l’approvisionnement adéquat. AKS crée de nouveaux nœuds, vide les nœuds existants, supprime les nœuds existants et les remplace par des nœuds sur lesquels le nouvel ensemble d’autorités de certification est installé.

Vérifier que les autorités de certification sont installées

  • Confirmez que les autorités de certification sont installées à l’aide de la commande az aks show.

    az aks show --resource-group <resource-group-name> --name <cluster-name> | grep securityProfile -A 4

    Dans la sortie, la securityProfile section doit inclure vos certificats d’autorité de certification personnalisés. Par exemple:

      "securityProfile": {
    "azureKeyVaultKms": null,
    "customCaTrustCertificates": [
        "values"

Résoudre les erreurs de formatage CA personnalisées

L’ajout de certificats à un cluster peut entraîner une erreur si le fichier avec les certificats n’est pas correctement mis en forme. Vous pouvez voir une erreur similaire à l’exemple suivant :

failed to decode one of SecurityProfile.CustomCATrustCertificates to PEM after base64 decoding

Si vous rencontrez cette erreur, vous devez vérifier que votre fichier d’entrée n’a pas de nouvelles lignes, espaces blancs ou données supplémentaires autres que les certificats correctement mis en forme, comme indiqué dans l’exemple de fichier.

Résoudre les erreurs de certification X.509 personnalisée signée par une autorité inconnue

AKS nécessite que les certificats transmis soient correctement mis en forme et encodés en base64. Vérifiez que les autorités de certification que vous avez passées sont correctement encodées en base64 et que les fichiers avec des autorités de certification n’ont pas de sauts de ligne CRLF.

Redémarrer le conteneur pour récupérer de nouveaux certificats

Si containerd ne récupère pas de nouveaux certificats, exécutez la systemctl restart containerd commande à partir du shell du nœud. Une fois le conteneur redémarré, le runtime de conteneur doit récupérer les nouveaux certificats.

enableCustomCATrust (aperçu) migration avant mise hors service

Important

À compter du 14 septembre 2026, la propriété enableCustomCATrust en préversion prendra sa retraite. Après cette date, le enableCustomCATrust=true champ au niveau du pool de nœuds n’active plus la fonctionnalité Autorité de certification personnalisée dans AKS. La dernière API en préversion qui prend en charge cette propriété est 2025-08-02-preview. Les pools de nœuds existants qui s’appuient encore sur enableCustomCATrust=true peuvent rencontrer des échecs lors des opérations de mise à l’échelle ou lors de la mise à jour des certificats. Pour éviter toute interruption de service, mettez à jour les clusters et les pools de nœuds concernés, puis supprimez la propriété de préversion avant le 14 septembre 2026. Pour connaître les étapes de migration, consultez enableCustomCATrustla migration liée à la mise hors service (préversion). Pour plus d’informations sur cette mise hors service, consultez le problème GitHub de mise hors service. Pour rester informé des annonces et des mises à jour, suivez les notes de publication AKS.

Supprimer la propriété Custom CA Trust des pools de nœuds

Les versions actuelles Azure CLI n'incluent pas l'--disable-custom-ca-trustoption. Pour supprimer la propriété enableCustomCATrust obsolète, utilisez une mise à jour générique de la ressource pour chaque pool de nœuds concerné. L’API 2025-08-02-preview est la dernière version de l’API qui expose cette propriété.

POOL_ID=$(az aks nodepool show \
  --resource-group <resource-group> \
  --cluster-name <cluster-name> \
  --name <node-pool-name> \
  --query id \
  --output tsv)

az resource update \
  --ids "$POOL_ID" \
  --api-version 2025-08-02-preview \
  --set properties.enableCustomCATrust=false

Cette commande récupère la ressource complète du pool de nœuds, met à jour enableCustomCATrust et renvoie la ressource mise à jour. Elle conserve les autres propriétés du pool de nœuds.

Vérifiez que la propriété est désactivée et que la mise à jour du pool de nœuds a réussi :

az rest \
  --method get \
  --url "https://management.azure.com${POOL_ID}?api-version=2025-08-02-preview" \
  --query "properties.{enableCustomCATrust:enableCustomCATrust,provisioningState:provisioningState}" \
  --output json

Répétez ces étapes pour chaque pool de nœuds où enableCustomCATrust est activé. La sortie attendue indique que enableCustomCATrust est défini sur false et provisioningState est défini sur Succeeded.

Si vous souhaitez que la confiance accordée à une autorité de certification (CA) personnalisée soit activée sur vos clusters après ce retrait, utilisez --custom-ca-trust-certificates et fournissez le chemin d’accès à un fichier de certificat.

Contenu connexe

Pour plus d’informations sur les bonnes pratiques en matière de sécurité AKS, consultez Meilleures pratiques relatives aux mises à niveau et à la sécurité du cluster dans Azure Kubernetes Service (AKS).

  • Last updated on