Introduction
Kubernetes offre aux équipes de développement une plateforme cohérente pour déployer des charges de travail en conteneur. Cette homogénéité signifie également qu’une seule erreur de configuration dans la sécurité du cluster peut exposer toutes les charges de travail qui y sont exécutées. L'environnement Azure Kubernetes Service (AKS) de Contoso Retail reflète un modèle commun aux organisations qui ont adopté Kubernetes rapidement et résolu la sécurité de manière incrémentielle : les clusters s'exécutent et les vulnérabilités sont silencieuses.
Un test d’intrusion sur l’environnement AKS de production de Contoso Retail a identifié trois lacunes de sécurité indépendantes mais composées dans le même cluster. L’accès au cluster est accordé par le biais d’attributions de rôles permanentes sans expiration ni exigence d’approbation. Les informations d’identification compromises d’un développeur fournissent un accès de cluster persistant sans limite de temps naturelle. Le serveur d’API est accessible publiquement sans restriction d’adresse IP source, afin qu’un attaquant disposant d’informations d’identification valides puisse y accéder n’importe où sur Internet. Les charges de travail s’exécutent sans stratégies de sécurité des pods, laissant ainsi un pod compromis interroger librement le service de métadonnées d’instance du nœud, accéder au système de fichiers hôte ou élever ses privilèges.
Aucune de ces défaillances ne s’affiche comme des erreurs pendant les opérations normales. Ils deviennent visibles uniquement lorsqu’ils sont exploités.
La sécurité AKS fonctionne dans trois couches distinctes. Les contrôles d’identité déterminent qui peut s’authentifier auprès du cluster et quelles actions elles sont autorisées à effectuer. Les contrôles réseau déterminent quel trafic peut atteindre le serveur d’API et quel trafic peut circuler entre les pods. Les contrôles de sécurité de charge de travail déterminent ce que les processus conteneurisés peuvent effectuer au moment de l’exécution, s’ils peuvent s’exécuter en tant que racine, modifier le système de fichiers ou accéder aux ressources hôtes.
Ce module aborde chaque couche successivement, en les faisant correspondre aux lacunes relevées par le test d’intrusion.
À la fin de ce module, vous serez en mesure de configurer l’intégration de Microsoft Entra ID et le RBAC pour l’authentification et l’autorisation du cluster, d’appliquer des stratégies réseau et l’accès privé au cluster, de mettre en œuvre l’identité de charge de travail pour éliminer l’exposition des informations d’identification, et d’utiliser les normes de sécurité des pods pour restreindre les privilèges des conteneurs.
Objectifs d’apprentissage
À l’issue de ce module, vous pourrez :
- Configurer Microsoft Entra ID intégration et RBAC pour l’authentification et l’autorisation du serveur d’API AKS
- Implémenter des contrôles de sécurité réseau, notamment des clusters privés, des plages d’adresses IP autorisées et des stratégies réseau
- Appliquer l’identité de charge de travail et les identités managées afin d’éliminer la gestion des identifiants pour les charges de travail AKS
- Appliquer les normes de sécurité des pods et les restrictions d’accès aux conteneurs