Partager via

Autorité de certification personnalisée dans Azure Kubernetes Service (AKS) (préversion)

  • Article

AKS génère et utilise les certificats, autorités de certification et comptes de service suivants :

  • Le serveur d’API AKS crée une autorité de certification appelée « Autorité de certification de cluster ».
  • Le serveur d’API dispose d’une autorité de certification de cluster, qui signe les certificats pour la communication unidirectionnelle, du serveur d’API vers les kubelets.
  • Chaque kubelet crée également une demande de signature de certificat (CSR), qui est signée par l’autorité de certification de cluster, pour la communication du kubelet vers le serveur d’API.
  • L’agrégation d’API utilise l’autorité de certification de cluster pour émettre des certificats destinés à la communication avec d’autres API. L’agrégation d’API peut également disposer de sa propre autorité de certification pour émettre ces certificats, mais elle utilise actuellement l’autorité de certification de cluster.
  • Chaque nœud utilise un jeton de compte de service qui est signé par l’Autorité de certification de cluster.
  • Le client kubectl dispose d’un certificat pour communiquer avec le cluster AKS.

Vous pouvez également créer des autorités de certification personnalisées qui vous permettent d’établir une approbation entre votre cluster Azure Kubernetes Service (AKS) et vos charges de travail, telles que des registres privés, des proxys et des pare-feu. Un secret Kubernetes stocke les informations de l’autorité de certification, puis les transmet à tous les nœuds du cluster. Cette fonctionnalité étant appliquée par pool de nœuds, vous devez l’activer sur des pools de nœuds nouveaux et existants.

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

Prérequis

  • Un abonnement Azure. Si vous n’avez pas d’abonnement Azure, créez un compte gratuit.
  • Azure CLI installé (version 2.43.0 ou ultérieure).
  • Chaîne de certificat encodée en base64 ou fichier texte avec certificat.

Limites

  • Cette fonctionnalité n’est actuellement pas prise en charge pour des pools de nœuds Windows.

Installer l’extension Azure CLI aks-preview

Important

Les fonctionnalités d’évaluation AKS sont disponibles en libre-service et font l’objet d’un abonnement. Les préversions sont fournies « en l’état » et « en fonction des disponibilités », et sont exclues des contrats de niveau de service et de la garantie limitée. Les préversions AKS sont, dans la mesure du possible, partiellement couvertes par le service clientèle. Telles quelles, ces fonctionnalités ne sont pas destinées à une utilisation en production. Pour plus d’informations, consultez les articles de support suivants :

  1. Installez l’extension aks-preview à l’aide de la commande az extension add.

    az extension add --name aks-preview

  2. Mettez à jour vers la dernière version de l’extension à l’aide de la commande az extension update.

    az extension update --name aks-preview

Inscrire l’indicateur de fonctionnalité CustomCATrustPreview

  1. Inscrivez l’indicateur de fonctionnalité CustomCATrustPreview à l’aide de la commande az feature register.

    az feature register --namespace "Microsoft.ContainerService" --name "CustomCATrustPreview"

    Quelques minutes sont nécessaires pour que l’état s’affiche Registered (Inscrit).

  2. Vérifiez l’état de l’inscription en utilisant la commande az feature show.

    az feature show --namespace "Microsoft.ContainerService" --name "CustomCATrustPreview"

  3. Quand l’état reflète Inscrit, actualisez l’inscription du fournisseur de ressources Microsoft.ContainerService à l’aide de la commande az provider register.

    az provider register --namespace Microsoft.ContainerService

Installation d’une autorité de certification personnalisée sur des pools de nœuds AKS

Installer des autorités de certification sur des pools de nœuds AKS

  • Si votre environnement nécessite l’ajout de vos autorités de certification personnalisées au magasin de confiance des nœuds pour un approvisionnement correct, vous devez transmettre un fichier texte contenant jusqu’à 10 certificats séparés par une ligne vide pendant l’exécution des opérations az aks create et az aks update. Exemple de fichier texte :

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

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

Installer des autorités de certification pendant la création d’un pool de nœuds

  • Installez les autorités de certification lors de la création de pool de nœuds en utilisant la commande az aks create et en spécifiant votre fichier texte pour le paramètre --custom-ca-trust-certificates.

    az aks create \
    --resource-group <resource-group-name> \
    --name <cluster-name> \
    --node-count 2 \
    --enable-custom-ca-trust \
    --custom-ca-trust-certificates pathToFileWithCAs \
    --generate-ssh-keys

Rotation de l’autorité de certification pour la disponibilité pendant le démarrage du pool de nœuds

  • Mettez à jour des autorités de certification transmises à votre cluster lors du démarrage en tirant parti de la commande az aks update et en spécifiant votre fichier texte pour le paramètre --custom-ca-trust-certificates.

    az aks update \
    --resource-group <resource-group-name> \
    --name <cluster-name> \
    --custom-ca-trust-certificates pathToFileWithCAs

    Notes

    Cette opération déclenche une mise à jour du modèle, veillant à ce que les nouveaux nœuds disposent des autorités de certification les plus récentes requises pour un approvisionnement correct. AKS crée des nœuds supplémentaires, vide ceux qui existent, les supprime et les remplace par des nœuds ayant le nouvel ensemble d’autorités de certification installé.

Installer des autorités de certification après la création d’un pool de nœuds

Si votre environnement peut être correctement approvisionné sans vos autorités de certification personnalisées, vous pouvez les fournir en déployant un secret dans l’espace de noms kube-system. Cette approche permet la rotation des certificats sans nécessiter de récréation de nœud.

  • Créez un manifeste YAML secret Kubernetes avec votre chaîne de certificats codée en base64 dans le champ data.

    apiVersion: v1
kind: Secret
metadata: 
    name: custom-ca-trust-secret
    namespace: kube-system
type: Opaque
data:
    ca1.crt: |
      {base64EncodedCertStringHere}
    ca2.crt: |
      {anotherBase64EncodedCertStringHere}

    Les données de ce secret sont utilisées pour mettre à jour les autorités de certification sur tous les nœuds. Vérifiez que le secret est nommé custom-ca-trust-secret et qu’il est créé dans l’espace de noms kube-system. L’installation d’autorités de certification à l’aide du secret dans l’espace de noms kube-system vous permet une rotation de l’autorité de certification sans que vous deviez recréer un nœud. Pour mettre à jour ou supprimer une autorité de certification, vous pouvez modifier et appliquer le manifeste YAML. Le cluster interroge les modifications et met à jour les nœuds en conséquence. L’application des modifications peut prendre quelques minutes.

    Notes

    Il est possible qu’un redémarrage de conteneur sur le nœud soit nécessaire pour que les autorités de certification soient correctement récupérées. Si les autorités de certification semblent ne pas être correctement ajoutées au magasin de confiance de votre nœud, vous pouvez déclencher un redémarrage à l’aide de la commande suivante à partir de l’interpréteur de commandes du nœud :

    systemctl restart containerd

Configurer un nouveau cluster AKS pour utiliser une autorité de certification personnalisée

  • Configurez un nouveau cluster AKS pour utiliser une autorité de certification personnalisée en tirant parti de la commande az aks create avec le paramètre --enable-custom-ca-trust.

    az aks create \
    --resource-group <resource-group-name> \
    --name <cluster-name> \
    --node-count 2 \
    --enable-custom-ca-trust \
    --generate-ssh-keys

Configurer un nouveau cluster AKS pour utiliser une autorité de certification personnalisée avec des autorités de certification installées avant le démarrage du nœud

  • Configurez un nouveau cluster AKS, pour utiliser une autorité de certification personnalisée avec des autorités de certification installées avant le démarrage du nœud, en tirant parti de la commande az aks create avec les paramètres --enable-custom-ca-trust et --custom-ca-trust-certificates.

    az aks create \
    --resource-group <resource-group-name> \
    --name <cluster-name> \
    --node-count 2 \
    --enable-custom-ca-trust \
    --custom-ca-trust-certificates pathToFileWithCAs \
    --generate-ssh-keys

Configurer un cluster AKS existant pour avoir des autorités de certification personnalisées installées avant le démarrage du nœud

  • Configurez un cluster AKS existant, pour ajouter vos autorités de certification personnalisées au magasin de confiance du nœud avant son démarrage, via l’utilisation de la commande az aks update avec le paramètre --custom-ca-trust-certificates.

    az aks update \
    --resource-group <resource-group-name> \
    --name <cluster-name> \
    --custom-ca-trust-certificates pathToFileWithCAs

Configurer un nouveau pool de nœuds pour utiliser une autorité de certification personnalisée

  • Configurez un nouveau pool de nœuds pour utiliser une autorité de certification personnalisée en utilisant la commande az aks nodepool add avec le paramètre --enable-custom-ca-trust.

    az aks nodepool add \
    --cluster-name <cluster-name> \
    --resource-group <resource-group-name> \
    --name <node-pool-name> \
    --enable-custom-ca-trust \
    --os-type Linux

    Si aucun autre pool de nœuds ayant la fonctionnalité activée n’existe, le cluster doit rapprocher ses paramètres pour que les modifications prennent effet. Cette opération se produit automatiquement dans le cadre de la boucle de rapprochement d’AKS. Avant l’opération, le jeu de démon et les pods n’apparaissent pas sur le cluster. Vous pouvez déclencher une opération de rapprochement immédiate à l’aide de la commande az aks update. L’ensemble de démons et les pods apparaissent une fois la mise à jour terminée.

Configurer un pool de nœuds existant pour utiliser une autorité de certification personnalisée

  • Configurez un pool de nœuds existant pour utiliser une autorité de certification personnalisée à l’aide de la commande az aks nodepool update avec le paramètre --enable-custom-ca-trust.

    az aks nodepool update \
    --resource-group <resource-group-name> \
    --cluster-name <cluster-name> \
    --name <node-pool-name> \
    --enable-custom-ca-trust

    Si aucun autre pool de nœuds ayant la fonctionnalité activée n’existe, le cluster doit rapprocher ses paramètres pour que les modifications prennent effet. Cette opération se produit automatiquement dans le cadre de la boucle de rapprochement d’AKS. Avant l’opération, le jeu de démon et les pods n’apparaissent pas sur le cluster. Vous pouvez déclencher une opération de rapprochement immédiate à l’aide de la commande az aks update. L’ensemble de démons et les pods apparaissent une fois la mise à jour terminée.

Désactiver l’autorité de certification personnalisée sur un pool de nœuds

  • Désactivez la fonctionnalité d’autorité de certification personnalisée sur un pool de nœuds existant en utilisant la commande az aks nodepool update avec le paramètre --disable-custom-ca-trust.

    az aks nodepool update \
    --resource-group <resource-group-name> \
    --cluster-name <cluster-name> \
    --name <node-pool-name> \
    --disable-custom-ca-trust

Dépannage

La fonctionnalité est activée et le secret avec les autorités de certification est ajouté, mais les opérations échouent avec l’erreur Certificat X.509 signé par une autorité inconnue

Certificats mal mis en forme passés dans le secret

AKS nécessite que les certificats passés dans le secret créé par l’utilisateur 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. Les certificats transmis --custom-ca-trust-certificates ne doivent pas être encodés en base64.

le conteneur n’a récupéré aucun nouveau certificat

À partir de l’interpréteur de commandes du nœud, exécutez systemctl restart containerd. Une fois le conteneur redémarré, les nouveaux certificats sont correctement récupérés par le runtime du conteneur.

Étapes suivantes

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).