Azure Policy et son intégration avec Azure Kubernetes Service
Azure Policy est un service Azure qui vous permet de gérer votre état de conformité dans différents services Azure. Azure Policy pour Kubernetes vous permet d’utiliser les mêmes stratégies Azure dans vos clusters Kubernetes, et ainsi de pouvoir gérer l’état de conformité des ressources Kubernetes telles que les pods, les déploiements et les services comme s’il s’agissait d’une ressource Azure.
Introduction à Azure Policy
Azure Policy vous permet de gérer l’état de conformité de vos services Azure. Pour ce faire, il compare l’état de vos ressources Azure aux règles métier que vous définissez. Les règles courantes sont la limitation de certaines régions, la présence obligatoire d’étiquettes de ressource ou la limitation des services Azure pouvant être utilisés.
La façon dont vous définissez ces règles métier dans Azure Policy consiste à utiliser des définitions de stratégie. Il existe de nombreuses stratégies intégrées qui couvrent divers scénarios courants. Si l’une des stratégies intégrées ne répond pas à vos besoins, vous pouvez également définir une stratégie personnalisée avec un langage basé sur JSON. Vous pouvez également regrouper plusieurs définitions de stratégie dans une initiative.
Dans une définition de stratégie, vous définissez une condition de conformité de ressource et l’effet à prendre si cette condition est remplie. Une condition compare les propriétés d’une ressource à une valeur requise. Par exemple, une condition peut consister à comparer la localisation d’une ressource par rapport à une liste prédéfinie de localisations autorisées. L’effet d’une stratégie peut être l’audit de la condition, le refus de la création de la ressource ou la modification de la ressource créée. Dans l’exemple de localisation d’une ressource, vous pouvez refuser la création de ressources qui ne sont pas dans la liste des localisations autorisées. Pour une explication plus détaillée des définitions de stratégie, reportez-vous à Structure des définitions Azure Policy.
Azure Policy fonctionne en affectant une définition de stratégie ou une initiative à une étendue spécifique. Une étendue peut être un groupe d’administration, un abonnement ou un groupe de ressources. Les affectations de stratégie sont automatiquement héritées pour toutes les étendues sous l’affectation, sauf si vous effectuez une exclusion. Plusieurs définitions de stratégie peuvent s’appliquer à une certaine étendue. La superposition de définitions de stratégie est considérée comme cumulative et la plus restrictive : Si plusieurs stratégies s’appliquent à une certaine ressource, cette ressource est uniquement conforme si toutes les définitions de stratégie qui s’y appliquent sont conformes.
Les affectations de stratégie sont évaluées lors de la création ou de la mise à jour des ressources Azure. Elles sont également évaluées si la définition ou l’étendue est modifiée, et régulièrement pour une surveillance continue. En pratique, la stratégie prend effet immédiatement lorsque vous créez des ressources. Toutes les ressources historiques sont également analysées, donc vous bénéficiez d’une vue continue de la conformité de toutes vos ressources.
Intégration d’Azure Policy avec AKS
Il existe deux façons d’intégrer Azure Policy à Azure Kubernetes Service (AKS).
- Stratégies qui appliquent la conformité sur le plan de contrôle Azure pour AKS.
- Stratégies qui appliquent la conformité sur la charge de travail exécutée dans votre cluster.
Le premier jeu de stratégies est plus axé sur les ressources Azure qui représentent la conception du cluster, tandis que le second jeu de stratégies est axé sur les charges de travail exécutées dans le cluster.
Un exemple de stratégie axée sur le plan de contrôle Azure pour AKS est la stratégie qui applique l’utilisation de clusters privés. La stratégie évalue si oui ou non un cluster AKS utilise la fonctionnalité de cluster privé. Cette stratégie est une configuration sur l’API Azure qui contrôle la conception du cluster lui-même.
Un exemple du jeu de stratégies axé sur la charge de travail exécutée dans votre cluster est la stratégie qui applique l’utilisation d’images autorisées. La stratégie évalue si une définition de pod dans Kubernetes utilise une image qui correspond à une certaine expression régulière. Cette stratégie est une configuration au sein du cluster lui-même et n’interagit pas avec l’API Azure.
Le premier jeu de stratégies fonctionne sur l’API Azure elle-même. Le second jeu de stratégies interagit avec l’API Kubernetes. Pour appliquer ces stratégies de sécurité intégrées, vous devez configurer le module complémentaire Azure Policy pour AKS dans votre cluster AKS.
Comprendre comment fonctionne Azure Policy pour AKS en coulisses
Pour appliquer des stratégies en plus de l’API Kubernetes, Azure Policy pour Kubernetes utilise de nombreux outils : les webhooks d’admission, OPA (Open Policy Agent), Gatekeeper et enfin un pod Azure Policy.
Azure Policy utilise des webhooks d’admission dans Kubernetes. Les webhooks d’admission sont une fonctionnalité intégrée de l’API Kubernetes. Ils permettent à l’API Kubernetes d’appeler un webhook externe pour valider si une demande de création, de suppression, de modification ou de connexion à une ressource doit être autorisée ou refusée (ValidatingAdmissionWebhook) ou si la demande doit être modifiée (MutatingAdmissionWebhook).
OPA (Open Policy Agent) est un moteur de stratégie open source. OPA fournit un langage général pour définir des stratégies. Vous pouvez utiliser OPA pour appliquer des stratégies dans vos propres microservices, dans des pipelines CI/CD et dans Kubernetes. Azure Policy pour Kubernetes traduit les stratégies Azure en langage OPA à déployer sur votre cluster Kubernetes.
OPA Gatekeeper est une implémentation spécifique à Kubernetes d’OPA qui s’intègre à l’API Kubernetes. Il s’intègre aux webhooks d’admission présentés précédemment. Plutôt que de devoir déployer vos propres gestionnaires de webhooks, vous pouvez utiliser OPA Gatekeeper pour traiter les réponses des webhooks d’admission. Azure Policy pour Kubernetes déploie OPA Gatekeeper sur votre cluster Kubernetes pour obtenir cette fonctionnalité.