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

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. De son côté, Azure fournit des composants tels que Active Directory, Microsoft Defender pour les conteneurs, Azure Policy, Azure Key Vault, les groupes de sécurité réseau et les mises à niveau de clusters orchestrées. AKS associe ces composants de sécurité à :

  • Fournir un scénario complet d’authentification et d’autorisation.
  • Tirer parti d’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

En tant que point d’entrée pour la chaîne d’approvisionnement, il est important d’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 de faire échouer une build parce qu’elle comporte une vulnérabilité, car cela interromprait 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. Tirez également parti 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 n’ont pas été 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 a son propre maître Kubernetes dédié monolocataire pour fournir le serveur d’API, le planificateur, etc.

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 d’Azure AD à 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 une distribution Ubuntu optimisée à l’aide de containerd ou du runtime de conteneur Docker.
  • Les nœuds Windows Server exécutent une version Windows Server 2019 optimisée utilisant le containerd ou le runtime de conteneur Docker.

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

Les clusters AKS utilisant :

  • Kubernetes version 1.19 et ultérieure pour les pools de nœuds Linux utilisent containerd comme runtime de conteneur. L’utilisation de containerd avec des pools de nœuds Windows Server 2019 est actuellement en préversion. Pour plus d’informations, consultez Ajouter un pool de nœuds Windows Server avec containerd.
  • Une version de Kubernetes antérieure à la v1.19 pour les pools de nœuds Linux utilisent Docker comme runtime de conteneur. Pour les pools de nœuds Windows Server 2019, Docker est le runtime de conteneur par défaut.

Correctifs de sécurité du nœud

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.

Les mises à jour nocturnes appliquent les mises à jour de sécurité au système d’exploitation sur le nœud, mais l’image de nœud 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 le 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 d’une image de nœud, consultez mise à niveau d’une image de nœud dans le Service Azure Kubernetes (AKS).

Nœuds Windows Server

Pour les nœuds Windows Server, Windows Update n’exécute pas et n’applique pas automatiquement les dernières mises à jour. Planifiez les mises à niveau des pools de nœuds Windows Server dans votre cluster AKS autour du cycle de publication de Windows Update standard et de votre propre processus de validation. Ce processus de mise à niveau crée des nœuds qui exécutent la dernière image et les derniers correctifs de Windows Server, puis supprime les anciens nœuds. Pour plus d’informations sur ce processus, consultez Mettre à niveau un pool de nœuds dans 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 effectuées par kubelets pour se protéger contre les attaques East-West. 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 aucune adresse IP publique affecté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.

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 multi-locataires 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 multi-locataires 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 machines virtuelles isolées à utiliser en tant que nœuds d’agent dans un cluster AKS. Ces machines virtuelles sont isolées dans un type de matériel spécifique et dédiées à un client unique.

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.

Mise à niveau des clusters

Azure fournit des outils d’orchestration de mise à niveau pour mettre à niveau un cluster AKS et des composants, maintenir la sécurité et la conformité, et accéder aux fonctionnalités les plus récentes. Cette orchestration de la mise à niveau inclut les composants maîtres et agents Kubernetes.

Pour démarrer le processus de mise à niveau, vous spécifiez l’une des versions de Kubernetes disponibles. Ensuite, Azure isole et draine de manière sécurisée chaque nœud AKS et effectue les mises à niveau.

Isolation et drainage

Pendant le processus de mise à niveau, les nœuds AKS sont chacun isolés du cluster afin que de nouveaux pods ne soient pas planifiés sur ces nœuds. Les nœuds sont ensuite drainés et mis à niveau comme suit :

  1. Un nouveau nœud est déployé dans le pool de nœuds.
    • Ce nœud exécute la dernière image et les derniers correctifs du système d’exploitation.
  2. Un des nœuds existants est identifié pour être mis à niveau.
  3. Les pods sur le nœud identifié sont arrêtés normalement et planifiés sur les autres nœuds du pool de nœuds.
  4. Ce nœud vidé est supprimé du cluster AKS.
  5. Les étapes 1-4 sont répétées jusqu’à ce que tous les nœuds soient correctement remplacés dans le cadre du processus de mise à niveau.

Pour plus d’informations, consultez Mettre à niveau un cluster AKS.

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 qui gère le cluster, par exemple l’accès à l’équilibreur de charge, la communication avec le plan de contrôle et 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, utilisezMicrosoft 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.

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.

  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. Lorsque 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’aux 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 manifeste secrets bruts contiennent les données secrètes au format base64 (consultez la documentation officielle pour plus d’informations). 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 de clés-valeurs distribué. Le magasin etcd est entièrement managé par AKS et les données sont chiffrées au repos sur 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 :