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

Article
02/08/2024

La sécurité des conteneurs protège l’ensemble du pipeline de bout en bout du build aux charges de travail d’application s’exécutant dans le service Azure Kubernetes (AKS).

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

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

Fournir un scénario complet d’authentification et d’autorisation.
Appliquer Azure Policy intégré à AKS pour sécuriser vos applications.
Des informations de bout en bout du build dans votre application avec Microsoft Defender for Containers.
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.

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

Sécurité de build

Parce qu’elles sont le point d’entrée de la chaîne d’approvisionnement, vous devez effectuer une analyse statique des builds d’image avant qu’elles ne soient promues dans le pipeline. Cela comprend l’évaluation de la conformité et de la vulnérabilité. Il ne s'agit pas d'échouer une version parce qu'elle présente une vulnérabilité, car cela interrompt le développement. Il s’agit d’examiner le segment Statut du fournisseur en fonction des vulnérabilités qui sont actionnables par les équipes de développement. Utilisez également des périodes de grâce pour permettre aux développeurs de corriger les problèmes identifiés.

Sécurité des registres

L’évaluation de l’état des vulnérabilités de l’image dans le registre détecte la dérive et intercepte également les images qui ne sont pas issues de votre environnement de génération. Utilisez Notary V2 pour joindre des signatures à vos images pour vous assurer que les déploiements proviennent d’un emplacement approuvé.

Sécurité des clusters

Dans AKS, les composants maîtres Kubernetes font partie du service managé fourni et tenu à jour par Microsoft. Chaque cluster AKS possède son propre maître Kubernetes dédié à locataire unique pour fournir le serveur d'API, le planificateur, etc. Pour plus d'informations, consultez 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.

Vous pouvez contrôler l’accès au serveur d’API avec des contrôles d’accès en fonction du rôle Kubernetes (RBAC Kubernetes) et le RBAC Azure. Pour plus d’informations, consultez Intégration Microsoft Entra avec AKS.

Sécurité des nœuds

Les nœuds AKS sont des machines virtuelles Azure dont vous assurez la gestion et la maintenance.

Les nœuds Linux exécutent des versions optimisées d’Ubuntu ou d’Azure Linux.
Les nœuds Windows Server exécutent une version optimisée de Windows Server 2022 utilisant le runtime du conteneur 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.

Notes

Clusters AKS exécutant :

Kubernetes version 1.19 et ultérieure : les pools de nœuds Linux utilisent containerd comme runtime de conteneur. Les pools de nœuds Windows Server 2019 et Windows Server 2022 utilisent containerd comme runtime de conteneur. Pour plus d’informations, consultez Ajouter un pool de nœuds Windows Server avec containerd.
Kubernetes version 1.19 et ultérieure : les pools de nœuds Linux utilisent Docker comme runtime de conteneur.

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

Les clusters AKS qui exécutent des machines virtuelles Azure de génération 2 incluent la prise en charge du lancement fiable qui protège contre les techniques d’attaque avancées et persistantes en combinant des technologies qui peuvent être activées indépendamment, comme le démarrage sécurisé et la version virtualisée du module de plateforme sécurisé (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.

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 le stockage, les nœuds utilisent Azure Disques managés. Pour la plupart des tailles de nœud de machine virtuelle, les disques managés Azure sont des disques Premium assortis de disques SSD hautes performances. Les données stockées sur les disques managés sont automatiquement chiffrées au repos au sein de la plateforme Azure. Pour améliorer la redondance, les disques managés Azure sont répliqués de manière sécurisée au sein du 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 :

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. Ils permettent d’isoler vos conteneurs d’autres groupes de conteneurs/pods, ainsi que du noyau de système d’exploitation du nœud des machines virtuelles. Les conteneurs confidentiels (préversion) 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 les réseaux locaux, vous pouvez déployer votre cluster AKS sur des sous-réseaux de réseau virtuel Azure existants. Ces réseaux virtuels se reconnectent à votre réseau local à l’aide d’un VPN de site à site ou d’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.

Groupes de sécurité réseau Azure

Pour filtrer le flux du trafic dans les réseaux virtuels, 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 l’interface Azure CNI ou Kubernet), ne modifiez pas le groupe de sécurité réseau au niveau de la carte réseau gérée 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.

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 comme meilleures pratiques pour [sécuriser l’accès des conteneurs aux ressources][sécuriser l’accès aux conteneurs].

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

Créez un secret en vous servant de l’API Kubernetes.
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.
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 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é.

Notes

Les fichiers manifestes secrets bruts contiennent les données secrètes au format base64. Pour plus d’informations, consultez la documentation officielle. Traitez ces fichiers comme des informations sensibles et ne les validez jamais dans le contrôle de code source.

Les secrets Kubernetes sont stockés dans etcd, un magasin clé-valeur distribué. AKS gère entièrement le magasin etcd et les données sont chiffrées au repos au sein de la plateforme Azure.

Étapes suivantes

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

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 :

Partager via