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

  • Article
  • 9 minutes pour lire

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 fournit des composants comme 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.
  • 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

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 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 a son propre maître Kubernetes dédié monolocataire pour fournir le serveur d’API, le planificateur, etc. Pour plus d’informations sur la façon dont Microsoft gère les vulnérabilités de sécurité et sur la publication de mises à jour de sécurité pour les parties managées d’un cluster AKS, 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 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 des versions optimisées d’Ubuntu ou Mariner.
  • 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.

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.

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. Vérifiez 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, 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.

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. 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 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é. AKS gère entièrement le magasin Etcd et les données sont chiffrées au repos dans 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 :