Concepts de sécurité pour les applications et les clusters dans Azure Kubernetes Service (AKS)

La sécurité du conteneur protège l’ensemble du pipeline de bout en bout depuis la génération jusqu'aux charges applicatives s'exécutant dans le service Azure Kubernetes (AKS).

La chaîne d’approvisionnement sécurisée comprend l’environnement de construction et le registre.

Kubernetes inclut des composants de sécurité, tels que les normes de sécurité des pods et les secrets. Azure inclut des composants tels que Microsoft Entra ID, Microsoft Defender pour les conteneurs, les Azure Policy, les Azure Key Vault, les groupes de sécurité réseau et les mises à niveau de cluster orchestrées. AKS associe ces composants de sécurité à :

• Fournir un scénario complet d’authentification et d’autorisation.
• Appliquez les stratégies Azure Policy intégrées à AKS pour sécuriser vos applications.
• Une visibilité de bout en bout, de la phase de génération jusqu’à votre application, avec Microsoft Defender pour les conteneurs.
• Conserver votre cluster AKS exécutant les dernières mises à jour de sécurité du système d’exploitation et les dernières versions de Kubernetes.
• Fournir un trafic de pod sécurisé et un accès aux informations d’identification sensibles.

AKS prend en charge deux modes de cluster : AKS Automatic et AKS Standard. Les concepts de sécurité de cet article s’appliquent aux deux modes, sauf indication contraire. AKS Automatic inclut une base de référence de sécurité renforcée avec plusieurs contrôles préconfigurés par défaut, tandis qu’AKS Standard offre une plus grande flexibilité de configuration.

Cet article présente les concepts fondamentaux qui sécurisent vos applications dans AKS.

Construire la sécurité

La sécurisation du processus de build constitue le point d’entrée de votre chaîne d’approvisionnement logicielle sécurisée. Avant que les images ne soient promues dans des environnements de déploiement, exécutez l’analyse statique et l’évaluation de la vulnérabilité et de la conformité dans CI.

Dans les deux modes AKS, utilisez le tri basé sur les risques plutôt que de bloquer toutes les builds sur n’importe quelle vulnérabilité. Hiérarchiser la correction à l’aide de l’état et de la gravité du fournisseur et appliquer des périodes de grâce pour les exceptions non exploitables ou limitées dans le temps.

AKS Automatic permet de réduire la dérive de configuration en aval en démarrant des clusters à partir d’une base de référence renforcée avec des contrôles de sécurité préconfigurés. Cela rend la validation au moment de la génération de la qualité des images et de la conformité des stratégies encore plus importante, car les images approuvées sont plus constamment promues dans une base de référence d’exécution sécurisée.

AKS Standard offre davantage de flexibilité au niveau du cluster. Les pipelines de build doivent donc appliquer explicitement le référentiel de base de votre organisation concernant la provenance des images, les seuils de vulnérabilité et les contrôles de conformité avant le déploiement.

Sécurité du Registre

La sécurité des registres vérifie que seules des images fiables et conformes sont disponibles pour le déploiement, et permet de détecter les écarts après la génération. Évaluez en continu l’état de vulnérabilité des images dans le registre, et pas seulement lors de la génération. L’analyse du registre détecte les vulnérabilités nouvellement révélées et les images qui ont contourné les processus de build approuvés. Utilisez la signature et la vérification d’images, comme Notary V2, pour garantir que les charges de travail sont déployées à partir de sources de confiance avec une provenance vérifiable.

Pour AKS Automatic, où plusieurs fonctionnalités de sécurité d’exécution sont préconfigurées, les contrôles de Registre restent une porte en amont critique pour nettoyer la chaîne d’approvisionnement du runtime. Pour AKS Standard, appliquez les mêmes contrôles du registre et alignez-les sur la configuration d’admission de votre cluster et sur vos stratégies afin d’imposer de manière cohérente l’utilisation d’images approuvées.

Sécurité des clusters

Dans AKS, les composants principaux de Kubernetes font partie du service géré fourni, géré et maintenu par Microsoft. Chaque cluster AKS dispose de sa propre instance principale Kubernetes dédiée et monolocataire pour fournir le serveur API, le planificateur, etc. Pour plus d’informations, consultez la gestion des vulnérabilités pour Azure Kubernetes Service.

Par défaut, le serveur d’API Kubernetes utilise une adresse IP publique avec un nom de domaine complet (FQDN). Vous pouvez limiter l’accès au point de terminaison du serveur d’API à l’aide de plages d’adresses IP autorisées. Vous pouvez également créer un cluster entièrement privé pour limiter l’accès du serveur d’API à votre réseau virtuel.

Pour AKS Automatic, l’intégration du réseau virtuel du serveur d’API est préconfigurée dans le cadre de la posture de sécurité par défaut. Dans AKS Standard, la même fonctionnalité est disponible et peut être activée en fonction des exigences de conception et de sécurité de votre réseau.

Vous pouvez contrôler l'accès au serveur d'API en utilisant le contrôle d'accès basé sur les rôles de Kubernetes (RBAC Kubernetes) et Azure RBAC. Dans AKS Automatic, Azure RBAC pour l’autorisation Kubernetes est préconfigurée. Dans AKS Standard, vous pouvez choisir et configurer le modèle d’autorisation qui convient le mieux à votre environnement. Pour plus d’informations, consultez Microsoft Entra intégration avec AKS.

Paramètres de sécurité par défaut automatiques d’AKS

AKS Automatic inclut une base de référence renforcée avec des contrôles de sécurité préconfigurés par défaut, notamment :

• Azure RBAC pour l’autorisation Kubernetes
• Intégration du réseau virtuel du serveur d’API
• Identité de charge de travail et émetteur OIDC
• Protections de déploiement et normes de sécurité des pods de référence en mode d’application
• Nettoyeur d’images pour supprimer les images vulnérables inutilisées
• Restrictions de sécurité du pool de nœuds système managés qui préservent les limites entre les charges de travail client et l’infrastructure gérée par AKS

AKS Standard prend en charge ces fonctionnalités avec une plus grande flexibilité d’implémentation, mais elles peuvent nécessiter une activation explicite et une gestion opérationnelle.

Sécurité des nœuds

Les nœuds AKS sont Azure machines virtuelles. Dans AKS Standard, vous gérez les options de configuration et de cycle de vie du pool de nœuds. Dans AKS Automatic, AKS gère les pools de nœuds système et les composants système principaux en votre nom, notamment la mise à l’échelle et les mises à niveau, avec des restrictions de sécurité pour l’infrastructure système managée.

Les nœuds Linux exécutent des versions optimisées d’Ubuntu ou Azure Linux. Les nœuds Windows Server exécutent une version optimisée de Windows Server à l’aide de l’environnement d'exécution des conteneurs containerd.

Quand un cluster AKS est créé ou fait l’objet d’un scale-up, les nœuds sont déployés automatiquement avec les dernières configurations et mises à jour de sécurité du système d’exploitation.

Pour plus d’informations sur le processus de mise à niveau de la sécurité pour les nœuds Worker Linux et Windows, consultez Nœuds de mise à jour corrective de sécurité.

Les clusters AKS exécutant des machines virtuelles Azure de génération 2 incluent la prise en charge de Lancement approuvé. Cette fonctionnalité protège contre les techniques d’attaque avancées et persistantes en combinant des technologies que vous pouvez activer indépendamment, comme le démarrage sécurisé et une version virtualisée du module de plateforme approuvée (vTPM). Les administrateurs peuvent déployer des nœuds Worker AKS avec des chargeurs de démarrage vérifiés et signés, des noyaux de système d’exploitation et des pilotes pour garantir l’intégrité de l’ensemble de la chaîne de démarrage de la machine virtuelle sous-jacente.

Options de système d’exploitation optimisées pour le conteneur et la sécurité

Azure Container Linux (ACL) est un système d’exploitation immuable optimisé pour les conteneurs pour AKS. ACL est dérivé du projet Flatcar Container Linux et s’appuie sur la conception immuable éprouvée de Flatcar, orientée conteneurs, tout en y ajoutant les paquets Azure Linux, la maintenance et l’intégration à la plateforme. Cela permet à ACL de rester en étroite adéquation avec les innovations apportées en amont à Flatcar, tout en répondant aux exigences d’Azure en matière de production, de sécurité et de conformité. Pour en savoir plus sur Flatcar Container Linux, consultez la documentation Flatcar.

ACL est disponible de façon générale (GA) en tant qu’option de système d’exploitation dans AKS à partir de la version 1.34 d’AKS. Vous pouvez déployer des pools de nœuds ACL dans un nouveau cluster AKS, ajouter des pools de nœuds ACL à vos clusters existants et migrer des pools de nœuds Linux existants vers ACL.

Pour plus d’informations sur ACL, consultez Vue d’ensemble d’Azure Container Linux (ACL) pour AKS.

Autorisation de nœud

L'autorisation de nœud est un mode d'autorisation à usage spécial qui autorise spécifiquement les demandes d'API kubelet pour se protéger contre les attaques Est-Ouest. L’autorisation de nœud est activée par défaut sur les clusters AKS 1.24 + .

Déploiement de nœuds

Les nœuds sont déployés sur un sous-réseau de réseau virtuel privé, sans adresse IP publique attribuée. À des fins de dépannage et de gestion, SSH est activé par défaut et est uniquement accessible à partir de l’adresse IP interne. La désactivation de SSH pendant la création d’un cluster et d’un pool de nœuds, ou pour un pool de nœuds existant, est en préversion. Pour plus d’informations, consultez Gérer l’accès SSH.

Stockage du nœud

Pour fournir un stockage, les nœuds utilisent Disques managés Azure. Pour la plupart des tailles de nœud de machine virtuelle, Disques managés Azure sont des disques Premium sauvegardés par des disques SSD hautes performances. Les données stockées sur des disques managés sont automatiquement chiffrées au repos dans la plateforme Azure. Pour améliorer la redondance, Disques managés Azure sont répliquées en toute sécurité dans le centre de données Azure.

Charges de travail multilocataires hostiles

Actuellement, les environnements Kubernetes ne sont pas sûrs pour une utilisation multilocataire hostile. Des fonctionnalités de sécurité supplémentaires, telles que les stratégies de sécurité de pod ou le RBAC Kubernetes pour les nœuds, bloquent efficacement les attaques. Pour une véritable sécurité lors de l’exécution de charges de travail multilocataires hostiles, ne faites confiance qu’à un hyperviseur. Le domaine de sécurité de Kubernetes devient le cluster, et non un nœud individuel.

Pour ces types de charges de travail multilocataires hostiles, vous devez utiliser des clusters physiquement isolés. Pour plus d’informations sur les méthodes d’isolation des charges de travail, consultez Meilleures pratiques relatives à l’isolation de clusters dans AKS.

Isolation du calcul

Pour des raisons de conformité ou d’exigences réglementaires, certaines charges de travail peuvent nécessiter un niveau d’isolation élevé par rapport aux autres charges de travail client. Pour ces charges de travail, Azure fournit les éléments suivants :

• Des conteneurs isolés du noyau à utiliser comme nœuds d’agent dans un cluster AKS. Ces conteneurs sont complètement isolés d’un type de matériel spécifique et isolés de l’infrastructure hôte Azure, du système d’exploitation hôte et de l’hyperviseur. Ils sont dédiés à un seul client. Sélectionnez l’une des tailles de machine virtuelle isolée comme taille de noyau lorsque vous créez un cluster AKS ou que vous ajoutez un pool de nœuds.
• Des conteneurs confidentiels (préversion), également basés sur des conteneurs Kata confidentiels, qui chiffrent la mémoire du conteneur et empêchent les données en mémoire pendant le calcul d’être dans un format lisible en texte clair, ainsi que leur falsification. Il permet d’isoler vos conteneurs d’autres groupes de conteneurs/pods et du noyau du système d’exploitation du nœud de machine virtuelle. Les conteneurs confidentiels (aperçu) utilisent le chiffrement de mémoire basé sur le matériel (SEV-SNP).
• Pod Sandboxing (préversion), qui fournit une limite d’isolation entre l’application conteneur et les ressources de noyau et de calcul partagées (UC, mémoire et réseau) de l’hôte du conteneur.

Sécurité du réseau

Pour la connectivité et la sécurité avec des réseaux locaux, vous pouvez déployer votre cluster AKS dans des sous-réseaux de réseau virtuel existants Azure. Ces réseaux virtuels se connectent à votre réseau local à l’aide de Azure VPN site à site ou Express Route. Définissez des contrôleurs d’entrée Kubernetes avec des adresses IP internes privées pour limiter l’accès aux services à la connexion réseau interne.

Dans AKS Automatic, les fonctionnalités de réseau virtuel managé et les valeurs par défaut des entrées et sorties principales sont préconfigurées pour fournir une base de référence sécurisée. Dans AKS Standard, les modèles réseau et les contrôles de sortie/entrée sont plus flexibles et doivent être sélectionnés en fonction de votre architecture de sécurité.

groupes de sécurité réseau Azure

Pour filtrer le flux de trafic de réseau virtuel, Azure utilise des règles de groupe de sécurité réseau. Ces règles définissent les plages d’adresses IP source et de destination, les ports et les protocoles qui se voient autoriser ou refuser l’accès aux ressources. Des règles par défaut sont créées pour autoriser le trafic TLS vers le serveur d’API Kubernetes. Vous créez des services avec des équilibreurs de charge, des mappages de port ou des itinéraires entrants. AKS modifie automatiquement le groupe de sécurité réseau pour le flux de trafic.

Si vous fournissez votre propre sous-réseau pour votre cluster AKS (que vous utilisiez Azure CNI ou Kubenet), ne modifiez pas le groupe de sécurité réseau au niveau de l'interface réseau géré par AKS. Au lieu de cela, créez d’autres groupes de sécurité réseau au niveau du sous-réseau pour modifier le flux du trafic. Assurez-vous qu'ils n'interfèrent pas avec le trafic nécessaire à la gestion du cluster, tel que l'accès à l'équilibreur de charge, la communication avec le plan de contrôle ou la sortie.

Stratégie de réseau Kubernetes

Pour limiter le trafic réseau entre les pods de votre cluster, AKS propose la prise en charge de stratégies de réseau Kubernetes. Les stratégies de réseau vous permettent d’autoriser ou de refuser des chemins d’accès réseau spécifiques au sein du cluster en fonction des espaces de noms et des sélecteurs d’étiquettes.

Sécurité des applications

Pour protéger les pods exécutés sur AKS, songez à utiliser Microsoft Defender pour les conteneurs afin de détecter et limiter les cyberattaques contre vos applications qui s’exécutent dans vos pods. Effectuez une analyse continue pour détecter les dérives dans l'état de vulnérabilité de votre application et mettez en place un processus bleu/vert/canari pour corriger et remplacer les images vulnérables.

Dans AKS Automatic, l’identité de charge de travail et l’émetteur OIDC sont préconfigurés pour simplifier l’accès sécurisé aux charges de travail aux services Azure. Dans AKS Standard, ces fonctionnalités sont disponibles et peuvent être activées dans le cadre de votre posture de sécurité de base.

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

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. Les fonctionnalités de sécurité Linux intégrées telles que AppArmor et seccomp sont recommandées en tant que meilleures pratiques pour sécuriser l’accès aux ressources du conteneur.

Secrets de Kubernetes

Avec un secret Kubernetes, vous injectez des données sensibles dans des pods, telles que les clés ou les informations d’identification d’accès.

1. Créez un secret en vous servant de l’API Kubernetes.
2. Définissez votre pod ou déploiement et demandez un secret spécifique.
   • Les secrets sont fournis uniquement aux nœuds avec un pod planifié qui en a besoin.
   • Le secret est stocké dans tmpfs, qui n’est pas écrit sur le disque.
3. Quand vous supprimez le dernier pod sur un nœud nécessitant un secret, ce dernier est supprimé du tmpfs du nœud.
   • Les secrets sont stockés dans un espace de noms donné et ne sont accessibles qu’à partir des pods se trouvant dans cet espace de noms.

L'utilisation de Secrets réduit la quantité d'informations sensibles définies dans le manifeste YAML des pods ou des services. Au lieu de cela, vous demandez le secret stocké sur le serveur d’API Kubernetes dans le cadre de votre manifeste YAML. Ainsi, l’accès au secret n’est accordé qu’au pod concerné.

Les secrets Kubernetes sont stockés dans etcd, un magasin clé-valeur distribué. AKS permet le chiffrement des secrets au repos dans etcd à l’aide de clés gérées par le client.

Contenu connexe

Pour vous familiariser avec la sécurisation de vos clusters AKS, consultez Mettre à niveau un cluster AKS.

Si vous évaluez les paramètres par défaut et les responsabilités opérationnelles spécifiques au mode, consultez Qu'est-ce que Azure Kubernetes Service (AKS) automatique ?

Pour connaître les meilleures pratiques associées, voir Meilleures pratiques relatives aux mises à jour et à la sécurité du cluster dans AKS et Bonnes pratiques relatives à la sécurité de pod dans AKS.

Pour plus d’informations sur les concepts fondamentaux de Kubernetes et d’AKS, consultez :

• Clusters et charges de travail Kubernetes/AKS
• Identité Kubernetes/AKS
• Réseaux virtuels Kubernetes/AKS
• Stockage Kubernetes/AKS
• Mise à l’échelle Kubernetes/AKS