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

S’applique à : ✔️ AKS Automatic ✔️ AKS Standard

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 :

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

Responsabilités de sécurité en mode cluster AKS

AKS prend en charge deux modes de cluster : AKS Automatic et AKS Standard. Les objectifs de sécurité sont identiques dans les deux modes, mais la responsabilité de l’implémentation diffère.

AKS Automatic inclut une base de référence renforcée avec des contrôles plus préconfigurés dans les configurations prises en charge. AKS Standard fournit un contrôle de configuration direct plus large, ce qui augmente la responsabilité de l’opérateur pour la configuration de la ligne de base et les opérations en cours.

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.

Ces instructions s’appliquent aux deux modes. Même si AKS Automatic fournit des paramètres de sécurité préconfigurés par défaut, l’intégration de la protection contre les menaces et les workflows de réponse aux alertes restent des responsabilités opérationnelles pour votre équipe.

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.

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

Avec AKS Automatic, les niveaux de référence en matière d’autorisation et de sécurité sont davantage préconfigurés dans les configurations prises en charge, de sorte que les opérateurs se concentrent sur la validation, la gouvernance et la gestion des exceptions. Dans AKS Standard, les opérateurs configurent généralement directement ces mécanismes de contrôle et en assurent eux-mêmes la gestion tout au long du cycle de vie.

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.

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

Dans AKS Standard, assurez-vous que votre modèle réseau et votre moteur de stratégie sélectionnés prennent en charge ce chemin de stratégie. Dans AKS Automatic, appliquez des restrictions de sortie équivalentes au niveau de l’espace de noms où elles sont prises en charge dans la configuration de votre cluster.

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.

En utilisant les espaces de noms utilisateur, vous améliorez l’isolation de l’hôte et limitez les mouvements latéraux en cas de rupture de conteneur. Ces améliorations restent significatives, que le pod s’exécute en tant que root ou non.

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.

Même si AKS Automatic fournit des valeurs par défaut renforcées, les contrôles de sécurité au niveau de la charge de travail restent des responsabilités d’équipe d’application et de plateforme.

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 de Kubernetes vous permet de mettre à jour Kubernetes sans avoir régulièrement à subir des changements incompatibles ni à ajuster vos déploiements et vos 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.

Dans AKS Automatic, le comportement lié à la mise à niveau est plus préconfiguré dans les configurations prises en charge, et les opérateurs doivent se concentrer sur la validation de préparation de la charge de travail et la gouvernance des versions. Dans AKS Standard, les opérateurs choisissent et régissent la stratégie de mise à niveau et le délai de déploiement plus directement.

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

Get-AzAksUpgradeProfile -ResourceGroupName myResourceGroup -ClusterName myAKSCluster |
Select-Object -Property Name, ControlPlaneProfileKubernetesVersion -ExpandProperty ControlPlaneProfileUpgrade |
Format-Table -Property *

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

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

Dans AKS Automatic, le comportement de mise à jour de nœud est plus préconfiguré dans les configurations prises en charge. Dans AKS Standard, les opérateurs définissent généralement la gouvernance des correctifs et des redémarrages avec des contrôles opérationnels explicites.

Mise à jour des 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.

Contenu connexe

Pour plus d’informations sur AKS et la sécurisation de votre cluster AKS, consultez les articles suivants :

• Comparaison des fonctionnalités AKS Automatic et AKS Standard
• Meilleures pratiques pour l’authentification et l’autorisation dans AKS