Vue d’ensemble de la gestion des certificats dans AKS activé par Azure Arc

Article
01/11/2024

S’applique à : AKS sur Azure Stack HCI 22H2, AKS sur Windows Server

AKS activé par Azure Arc utilise une combinaison d’authentification basée sur des certificats et des jetons pour sécuriser la communication entre les services (ou agents) responsables de différentes opérations au sein de la plateforme. L’authentification par certificat utilise un certificat numérique pour identifier une entité (agent, machine, utilisateur ou appareil) avant d’accorder l’accès à une ressource.

Agent cloud

Lorsque vous déployez AKS activé par Arc, AKS installe des agents utilisés pour effectuer différentes fonctions au sein du cluster. Ces agents sont notamment les suivants :

Agent cloud : un service responsable de l’orchestration de la plateforme sous-jacente.
Agent de nœud : un service qui se trouve sur chaque nœud, effectuant le travail réel de création, de suppression, etc., des machines virtuelles
Pod KMS (Key Management System) : un service responsable de la gestion des clés.
Autres services : opérateur cloud, gestionnaire de certificats, etc.

Le service d’agent cloud dans AKS est chargé d’orchestrer les opérations de création, de lecture, de mise à jour et de suppression (CRUD) des composants d’infrastructure tels que Machines Virtuelles (machines virtuelles), les interfaces Réseau virtuel (VNIC) et les Réseau virtuel (VNET) dans le cluster.

Pour communiquer avec l’agent cloud, les clients exigent que des certificats soient provisionnés pour sécuriser cette communication. Chaque client nécessite qu’une identité y soit associée, qui définit les règles de contrôle d’accès en fonction du rôle (RBAC) associées au client. Chaque identité se compose de deux entités :

Un jeton, utilisé pour l’authentification initiale, qui retourne un certificat, et
Un certificat, obtenu à partir du processus de connexion ci-dessus, et utilisé pour l’authentification dans toutes les communications.

Chaque entité est valide pendant une période spécifique (la valeur par défaut est de 90 jours), au terme de laquelle elle expire. Pour un accès continu à l’agent cloud, chaque service exige que le certificat soit renouvelé et que le jeton fasse l’objet d’une rotation.

Types de certificats

Il existe deux types de certificats utilisés dans AKS activés par Arc :

Certificat d’autorité de certification de l’agent cloud : le certificat utilisé pour signer/valider des certificats clients. Ce certificat est valide pendant 365 jours (1 an).
Certificats clients : certificats émis par le certificat d’autorité de certification de l’agent cloud pour permettre aux clients de s’authentifier auprès de l’agent cloud. Ces certificats sont généralement valides pendant 90 jours.

Microsoft vous recommande de mettre à jour les clusters dans les 60 jours d’une nouvelle version, non seulement pour garantir que les certificats et jetons internes sont conservés à jour, mais également pour garantir que vous obtenez l’accès aux nouvelles fonctionnalités, aux correctifs de bogue, et pour être à jour avec les correctifs de sécurité critiques. Pendant ces mises à jour mensuelles, le processus de mise à jour effectue une rotation de tous les jetons pour lesquels ce n’est pas fait automatiquement lors de l’exploitation normale du cluster. La validité du certificat et du jeton est réinitialisée à 90 jours par défaut à partir de la date à laquelle le cluster est mis à jour.

Sécuriser la communication avec des certificats dans AKS activé par Arc

Les certificats permettent de créer une communication sécurisée entre composants dans un cluster. AKS fournit le provisionnement sans contact, le provisionnement prête à l’emploi et la gestion des certificats pour les composants Kubernetes intégrés. Dans cet article, vous allez apprendre à provisionner et gérer des certificats dans AKS activés par Arc.

Certificats et autorités de certification

AKS génère et utilise les autorités de certification et les certificats suivants.

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 kubelet.
Chacune kubelet crée également une demande de signature de certificat (CSR), signée par l’autorité de certification du cluster, pour la communication entre kubelet le serveur d’API et le serveur d’API.
Le magasin de valeurs de clés etcd dispose d’un certificat signé par l’autorité de certification de cluster, pour la communication émanant de etcd à destination du serveur d’API.

autorité de certification etcd

Le magasin de valeurs de clé etcd crée une autorité de certification d’etcd qui signe les certificats pour authentifier et autoriser la réplication de données entre réplicas etcd dans le cluster.

Autorité de certification de proxy frontal :

L’autorité de certification de proxy frontal sécurise la communication entre le serveur d’API et le serveur d’API d’extension.

Approvisionnement du certificat

L’approvisionnement de certificats pour un kubelet est effectué à l’aide du démarrage TLS. Pour tous les autres certificats, utilisez le mode de création de clés et de certificats basé sur YAML.

Les certificats sont stockés dans /etc/kubernetes/pki.
Les clés sont RSA 4096, EcdsaCurve : P384

Remarque

Les certificats racine sont valides pendant 10 ans. Tous les autres certificats non racines sont de courte durée et valides pendant quatre jours.

Renouvellement et gestion des certificats

Les certificats non racine sont automatiquement renouvelés. Tous les certificats de plan de contrôle pour Kubernetes, à l’exception des certificats suivants sont gérés :

certificat de serveur kubelet ;
certificat de client kubeconfig.

En guise de meilleure pratique de sécurité, vous devez utiliser l’authentification unique Active Directory pour l’authentification utilisateur.

Révocation de certificat

La révocation de certificats doit être rare et elle doit être effectuée au moment du renouvellement du certificat.

Une fois que vous avez le numéro de série du certificat que vous souhaitez révoquer, utilisez la ressource personnalisée Kubernetes pour définir et conserver les informations de révocation. Chaque objet de révocation peut se composer d’une ou plusieurs entrées de révocation.

Pour effectuer une révocation, utilisez l’un des éléments suivants :

Numéro de série
Groupe
Nom DNS
Adresse IP

Une notBefore heure peut être spécifiée pour révoquer uniquement les certificats émis avant un certain horodatage. Si une notBefore heure n’est pas spécifiée, tous les certificats existants et futurs correspondant à la révocation seront révoqués.

Remarque

La révocation des certificats de kubelet serveur n’est actuellement pas disponible.

Si vous utilisez un numéro de série lorsque vous effectuez une révocation, vous pouvez utiliser la Repair-AksHciClusterCerts commande PowerShell, décrite ci-dessous, pour obtenir votre cluster dans un état de fonctionnement. Si vous utilisez l’un des autres champs répertoriés précédemment, veillez à spécifier une notBefore heure.

apiVersion: certificates.microsoft.com/v1 
kind: RenewRevocation 
metadata: 
  name: my-renew-revocation 
  namespace: kube-system 
spec: 
  description: My list of renew revocations 
  revocations: 
  - description: Revoked certificates by serial number 
    kind: serialnumber 
    notBefore: "2020-04-17T17:22:05Z" 
    serialNumber: 77fdf4b1033b387aaace6ce1c18710c2 
  - description: Revoked certificates by group 
    group: system:nodes 
    kind: Group 
  - description: Revoked certificates by DNS 
    dns: kubernetes.default.svc. 
    kind: DNS 
  - description: Revoked certificates by DNS Suffix 
    dns: .cluster.local 
    kind: DNS 
  - description: Revoked certificates by IP 
    ip: 170.63.128.124 
    kind: IP

Partager via