Partage via

Meilleures pratiques relatives aux mises à jour et à la sécurité du cluster dans Azure Kubernetes Service (AKS)

  • Article

Quand vous gérez des clusters dans AKS (Azure Kubernetes Service), la sécurité des charges de travail et des données est un point important. Lorsque vous exécutez des clusters multilocataires à l’aide de l’isolation logique, vous devez tout particulièrement sécuriser l’accès aux ressources et aux charges de travail. Réduisez le risque d’attaque en appliquant les dernières mises à jour de sécurité du système d’exploitation de nœud et de Kubernetes.

Cet article est dédié à la sécurisation de votre cluster AKS. Vous allez apprendre à effectuer les actions suivantes :

  • Utiliser Microsoft Entra ID et le contrôle d’accès en fonction du rôle Kubernetes (RBAC Kubernetes) pour sécuriser l’accès au serveur d’API.
  • Sécuriser l’accès du conteneur aux ressources de nœud.
  • Mettre à niveau un cluster AKS avec la dernière version de Kubernetes.
  • Maintenir les nœuds à jour et appliquer automatiquement des correctifs de sécurité.

Vous pouvez également consulter les meilleures pratiques relatives à la gestion des images conteneur et à la sécurité du pod.

Activer la protection contre les menaces

Conseils sur les bonnes pratiques

Vous pouvez activer Defender pour les conteneurs afin de sécuriser vos conteneurs. La solution Defender pour les conteneurs peut évaluer les configurations de cluster et fournir des recommandations de sécurité, exécuter des analyses de vulnérabilité et fournir une protection et des alertes en temps réel pour les nœuds et clusters Kubernetes.

Sécuriser l’accès aux nœuds de cluster et au serveur d’API

Conseils sur les bonnes pratiques

L’une des manières les plus fiables de sécuriser votre cluster consiste à sécuriser l’accès au serveur d’API Kubernetes. Pour contrôler l’accès au serveur d’API, intégrez RBAC Kubernetes à Microsoft Entra ID. Avec ces contrôles, vous pouvez sécuriser AKS de la même façon que vous sécurisez l’accès à vos abonnements Azure.

Le serveur d’API Kubernetes propose un point de connexion unique pour que les requêtes exécutent des actions dans un cluster. Pour sécuriser et auditer l’accès au serveur d’API, limitez l’accès et accordez les niveaux d’autorisation les plus faibles possibles. Bien que cette approche ne soit pas unique à Kubernetes, elle est particulièrement importante lorsque vous avez isolé votre cluster AKS de façon logique pour une utilisation multilocataire.

Microsoft Entra ID fournit une solution de gestion des identités adaptée aux entreprises qui s’intègre aux clusters AKS. Kubernetes ne procurant pas de solution de gestion des identités, vous serez peut-être contraint de restreindre de façon précise l’accès au serveur d’API. Avec les clusters intégrés Microsoft Entra dans AKS, vous utilisez vos comptes groupe et utilisateur existants pour authentifier des utilisateurs sur le serveur d’API.

Intégration de Microsoft Entra pour les clusters AKS

À l’aide de RBAC Kubernetes et de l’intégration à Microsoft Entra ID, vous pouvez sécuriser le serveur d’API et fournir les autorisations minimales requises pour un ensemble de ressources délimité, tel qu’un espace de noms unique. Vous pouvez accorder divers rôles Kubernetes à différents utilisateurs ou groupes Microsoft Entra. Avec des autorisations précises, vous pouvez restreindre l’accès au serveur d’API et fournir une piste d’audit claire des actions effectuées.

La bonne pratique recommandée consiste à utiliser des groupes pour fournir un accès aux fichiers et dossiers plutôt que des identités individuelles. Par exemple, utilisez une appartenance de groupe Microsoft Entra ID afin de lier des utilisateurs à des rôles Kubernetes, plutôt que des utilisateurs individuels. Lorsque l’appartenance au groupe d’un utilisateur change, ses autorisations d’accès sur le cluster AKS changent en conséquence.

Par ailleurs, supposez que vous liez l’utilisateur individuel directement à un rôle et que ses fonctions de travail changent. Les appartenances au groupe Microsoft Entra seront mises à jour, tandis que ses autorisations sur le cluster AKS resteront inchangées. Dans ce scénario, l’utilisateur se retrouvera avec plus d’autorisations qu’il n’en a besoin.

Pour obtenir plus d’informations sur l’intégration Microsoft Entra, RBAC Kubernetes et RBAC Azure, consultez les Meilleures pratiques relatives à l’authentification et à l’autorisation dans AKS.

Restreindre l’accès à l’API de métadonnées d’instance

Conseils sur les bonnes pratiques

Ajoutez une stratégie réseau dans tous les espaces de noms utilisateur pour bloquer la sortie pod vers le point de terminaison des métadonnées.

Notes

Pour implémenter la stratégie réseau, incluez l’attribut --network-policy azure lors de la création du cluster AKS. Utilisez la commande suivante pour créer le cluster : az aks create -g myResourceGroup -n myManagedCluster --network-plugin azure --network-policy azure --generate-ssh-keys

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: restrict-instance-metadata
spec:
  podSelector:
    matchLabels: {}
  policyTypes:
  - Egress
  egress:
  - to:
    - ipBlock:
        cidr: 10.10.0.0/0#example
        except:
        - 169.254.169.254/32

Sécuriser l’accès du conteneur aux ressources

Conseils sur les bonnes pratiques

Limitez l’accès aux actions que les conteneurs peuvent effectuer. Fournissez le plus petit nombre d’autorisations, et évitez d’utiliser l’accès racine ou l’escalade de privilèges.

De la même façon que vous devez accorder aux utilisateurs ou aux groupes le minimum de privilèges requis, vous devez limiter les conteneurs uniquement aux actions et processus nécessaires. Pour réduire le risque d’attaque, évitez de configurer les applications et les conteneurs qui nécessitent une escalade des privilèges ou un accès racine.

Pour un contrôle encore plus précis des actions de conteneur, vous pouvez également utiliser des fonctionnalités de sécurité Linux intégrées telles que AppArmor et seccomp. Pour plus d’informations, consultez Sécuriser l’accès du conteneur aux ressources.

Effectuer des mises à jour régulières vers la dernière version de Kubernetes

Conseils sur les bonnes pratiques

Pour rester informé des nouvelles fonctionnalités et correctifs de bogues, effectuez des mises à niveau régulières de la version Kubernetes dans votre cluster AKS.

Kubernetes sort de nouvelles fonctionnalités à un rythme plus effréné que les plateformes d’infrastructure plus traditionnelles. Les mises à jour Kubernetes comprennent ce qui suit :

  • Nouvelles fonctionnalités
  • Correctifs de bogues ou de sécurité

En général, les nouvelles fonctionnalités passent par un état alpha, puis bêta ,avant d’atteindre un état stable. Une fois stables, elles sont en disponibilité générale et recommandées pour une utilisation en production. Le cycle de publication des nouvelles fonctionnalités Kubernetes vous permet de mettre à jour Kubernetes sans rencontrer régulièrement de changements cassants ou ajuster vos déploiements et modèles.

AKS prend en charge trois versions mineures de Kubernetes. Lorsqu’une nouvelle version de correctif mineure est introduite, la version mineure et les publications des correctifs les plus anciennes prises en charge sont mises hors service. Les mises à jour mineures de Kubernetes se produisent sur une base périodique. Pour rester dans les limites de support, vérifiez que vous disposez d’un processus de gouvernance pour vérifier les mises à niveau nécessaires. Pour plus d’informations, consultez la section Versions de Kubernetes prises en charge dans AKS.

Pour consulter les versions disponibles pour votre cluster, utilisez la commande az aks get-upgrades comme indiqué dans l’exemple suivant :

az aks get-upgrades --resource-group myResourceGroup --name myAKSCluster --output table

Vous pouvez ensuite mettre à niveau votre cluster AKS à l’aide de la commande az aks upgrade. Le processus de mise à niveau effectue les opérations suivantes de manière sécurisée :

  • Bouclage et drainage d’un nœud à la fois
  • Planification des pods sur les nœuds restants
  • Déploiement d’un nouveau nœud exécutant les versions les plus récentes du système d’exploitation et de Kubernetes

Important

Testez les nouvelles versions mineures dans un environnement de développement de test, et vérifiez que votre charge de travail demeure intègre avec la nouvelle version de Kubernetes.

Kubernetes est susceptible de déprécier les API (comme dans la version 1.16) sur lesquelles reposent vos charges de travail. Lors de la mise en production de nouvelles versions, envisagez d’utiliser plusieurs pools de nœuds sur des versions distinctes et de mettre à niveau les pools individuels un par un pour déployer progressivement la mise à jour sur l’ensemble du cluster. Si vous exécutez plusieurs clusters, mettez-les à niveau l’un après l’autre de manière à surveiller progressivement l’impact ou les modifications.

az aks upgrade --resource-group myResourceGroup --name myAKSCluster --kubernetes-version KUBERNETES_VERSION

Pour plus d’informations sur les mises à niveau dans AKS, consultez Versions de Kubernetes prises en charge dans Azure Kubernetes Service (AKS) et Mise à jour d’un cluster Azure Kubernetes Service (AKS).

Traiter les mises à jour des nœuds Linux

Chaque soir, les nœuds Linux dans AKS obtiennent les correctifs de sécurité par le biais de leur canal de mise à jour de distribution. Ce comportement est configuré automatiquement à mesure que les nœuds sont déployés dans un cluster AKS. Pour minimiser les perturbations et l’impact potentiel sur les charges de travail en cours d’exécution, les nœuds ne sont pas automatiquement redémarrés si un correctif de sécurité ou mise à jour du noyau l’exige. Pour plus d’informations sur le traitement des redémarrages de nœud, consultez la sectionAppliquer des mises à jour de sécurité et du noyau à des nœuds dans AKS.

Mises à niveau d’images de nœud

Les mises à niveau sans assistance appliquent les mises à jour au système d’exploitation des nœuds Linux, mais l’image utilisée pour créer les nœuds de votre cluster reste inchangée. Si un nouveau nœud Linux est ajouté à votre cluster, l’image d’origine est utilisée pour créer ce nœud. Ce nouveau nœud recevra toutes les mises à jour de sécurité et de noyau disponibles au cours de la vérification automatique chaque nuit, mais restera non corrigé jusqu’à ce que toutes les vérifications et tous les redémarrages soient terminés. Vous pouvez utiliser la mise à niveau d’image de nœud pour vérifier et mettre à jour les images de nœud utilisées par votre cluster. Pour plus d’informations sur la mise à niveau des images de nœud, consultez Mise à niveau des images de nœud Azure Kubernetes Service (AKS).

Traiter les mises à jour des nœuds Windows Server

Pour les nœuds Windows Server, effectuez régulièrement une opération de mise à niveau des images de nœud pour isoler et drainer de façon sécurisée les pods et déployer les nœuds mis à jour.