1. INTERVENANTS
DJEBBOURI Younes
Architecte Azure et DevOps 🚀💻✨
2. PROBLÉMATIQUE
Tu as sécurisé le code.
Tu as renforcé les nœuds.
Tu as limité les failles dans les pods et contrôlé les accès réseau
Mais est-ce que ton cluster est vraiment gouverné ?
Et surtout : est-ce que tu peux le prouver, à tout moment, à n’importe quel auditeur, RSSI ou client exigeant ?
👉C’est là qu’intervient un sujet souvent oublié dans la sécurité AKS : la conformité automatisée.
Parce qu’un cluster peut être bien configuré aujourd’hui… mais dégradé demain.
Parce qu’un Dev peut contourner une règle… sans même le vouloir.
Parce qu’un audit RGPD ou HDS n’attend pas que tu mettes de l’ordre.
Dans cette partie, on va découvrir comment transformer les règles de sécurité en garde-fous codés et audités :
- avec Azure Policy for Kubernetes, pour appliquer des standards à tous les environnements,
- avec OPA et Gatekeeper, pour dire non quand il le faut,
- avec Regulatory Compliance, pour mapper automatiquement les exigences ISO/NIST/RGPD à tes politiques,
- et avec les Static Policies, pour disposer de preuves solides, traçables et prêtes à auditer.
🧠 La sécurité, ce n’est pas qu’une histoire de technique.
C’est aussi une histoire de règles… qui tiennent dans le temps.
5. Conformité aux politiques
La sécurité ne se décrète pas, elle s’impose.
Et dans un environnement cloud comme Azure, c’est justement cette capacité à imposer les bonnes pratiques, à grande échelle et de manière vérifiable, qui fait toute la différence.
Dans Kubernetes, tu peux documenter des règles.
Mais sans mécanisme d’exécution automatique, elles restent des vœux pieux
| La vraie sécurité, c’est quand les règles sont codées, appliquées, et auditées — sans avoir besoin de rappeler manuellement ce qu’il “faudrait faire” |
C’est là que Azure Policy for Kubernetes, couplé à Open Policy Agent (OPA), devient un pilier de la gouvernance.
5.1 Conformité avec les politiques Azure
Dès le départ, notre objectif était simple :
👉 unifier la gouvernance de tous les clusters, qu’ils soient dans AKS, on-premise (via Azure Arc), ou même dans d’autres clouds.
Et pour y parvenir, nous avons fait un choix clair :
Activer l’Add-on Azure Policy pour Kubernetes, basé sur OPA, sur tous les clusters de l’organisation.
Pourquoi ce choix ?
Parce qu’il apporte trois bénéfices clés :
- Standardisation des politiques : une seule source de vérité, définie dans Terraform.
- Support natif Azure : les mises à jour, correctifs et intégrations sont assurés par Microsoft.
- Compatibilité multi-environnements : AKS, clusters Arc-enabled, ou même hybrides.
En d’autres termes :
Peu importe où tourne le cluster
Les règles sont les mêmes. Les alertes sont les mêmes. Les mécanismes de contrôle sont les mêmes
Deux niveaux de politiques à connaître
Quand on parle de conformité dans AKS via Azure Policy, il faut distinguer deux cibles de politiques :
1️⃣ Politiques au niveau Azure Resource (le cluster AKS en tant que ressource)
Ces politiques s’appliquent à la couche “infrastructure” Azure.
Elles permettent de contrôler des paramètres comme :
- L’activation ou non de Private Link,
- Le SKU autorisé pour l’ACR,
- Le chiffrement des disques persistants,
- Ou encore la configuration réseau (VNet, Subnet…).
Ces politiques disposent de trois modes d’application :
| Mode | Fonction | Cas d’usage |
|---|---|---|
Audit | Surveille sans bloquer | Détection, reporting |
Deny | Empêche la non-conformité | Sécurité forte |
DeployIfNotExists | Crée l’objet si manquant | Automatisation corrective |
⚠️ Attention au piège DeployIfNotExists :Ce mode crée automatiquement des ressources correctives. ➡️ Problème : ces ressources ne sont pas connues de Terraform, ce qui provoque des incohérences et des erreurs dans les plans futurs. 🎯 Notre choix : ne pas l’utiliser dans une architecture GitOps/IaC stricte |
2️⃣ Politiques dans le cluster Kubernetes (via l’OPA add-on)
Ici, on parle des règles de conformité appliquées à ce qui vit à l’intérieur du cluster : pods, services, namespaces, volumes…
Quelques exemples de règles :
- Interdire les conteneurs avec privilèges élevés
- Obliger l’usage d’un registre privé
- Refuser les images non signées
- Vérifier la présence de labels de classification…
Ces règles sont portées par OPA, mais pilotées depuis Azure Policy, ce qui offre :
- Une vue centralisée dans Azure,
- Une audibilité standardisée (Defender, Purview…)
- Et une traçabilité automatique via Azure Monitor
5.2 Politiques a appliquées
Définir des politiques, c’est bien. Les mettre en œuvre concrètement, c’est mieux.
Voici un exemple d’un état des lieux des politques que nous avons déjà appliquées au niveau des ressources AKS, via Azure Policy
| Politique | Mode | Commentaire |
|---|---|---|
| Définir des plages IP autorisées | Non requis | Tous les clusters sont privés, donc la restriction IP est implicite. |
| Restreindre les images à des sources approuvées | Deny | Les manifestes pointant vers un registre non approuvé sont bloqués. |
| Utiliser des identités managées | Audit | Détection active, avec migration progressive prévue. |
| Activer les clusters AKS privés | Deny | Toute création de cluster public est bloquée. |
| Désactiver SSH | Audit | L’accès SSH reste activé à titre exceptionnel pour dépannage. |
| Intégration Microsoft Entra ID | Audit | Contrôle en place, mais non bloquant pour l’instant. |
| Activer Workload Identity | Audit | Suivi de l’adoption, encouragée via nos guidelines. |
| Désactiver l’authentification locale | Deny | Tout cluster doit reposer sur Azure AD, sans credentials statiques. |
5.3 Autres politiques à considérer
Toutes les politiques ne sont pas encore déployées — certaines sont en réflexion, d’autres dépendent de l’évolution des pratiques internes ou du niveau de maturité des équipes.
| Politique | État | Détail |
|---|---|---|
| Désactiver l’invocation de commandes | Non requis | Déjà bloqué via Terraform, inutile de le doubler via policy. |
| Configurer probes readiness/liveness | Non déployé | Nécessite d’embarquer les équipes Dev. Un plan d’acculturation est prévu. |
| Limiter CPU/mémoire | Non déployé | Prévu à moyen terme pour garantir la stabilité et la cohabitation des workloads. |
| Load Balancer internes uniquement | Deny | Par défaut, tout Load Balancer public est interdit sans justification formelle. |
| Activer RBAC Kubernetes | Audit | Vérification en place, adoption quasi généralisée. |
| Installer Azure Policy Add-on | Déployé | Activé sur tous les clusters, AKS et Arc. |
| Activer Defender for Containers | Déployé | Monitoring des clusters non protégés en cours via Azure Security Center. |
Ces politiques ne sont pas oubliées : elles sont juste intégrées progressivement, selon leur impact sur les workflows existants.
Par exemple, imposer des probes trop tôt pourrait bloquer des déploiements critiques.
C’est donc une question de rythme, pas d’importance.
5.4 Politiques appliquées dans le cluster Kubernetes
Enfin, certains aspects sont gérés directement à l’intérieur du cluster, mais hors Azure Policy.
Ils reposent sur Terraform, des scripts internes, ou des choix d’architecture spécifiques
| Politique | Implémentation | Remarques |
|---|---|---|
| Activer le profil Defender | Géré via Terraform | Intégré au moment de la création du cluster. |
| Intégration Entra ID + accès admin | Géré via Terraform | Ajout des groupes AD dès la phase de provisionnement. |
| Mises à jour automatiques OS | Géré via Terraform | Repos sur les mécanismes Ubuntu + Kured. |
| Logs vers Log Analytics | Géré finement | Collecte ciblée (Diagnostic Settings) pour éviter les coûts excessifs. |
| Image Cleaner | Prévu à terme | En cours d’étude pour éviter l’accumulation d’images obsolètes. |
| Maintenance planifiée AKS | À planifier | Ajout futur dans les pipelines CI/CD |
| ⚠️ Attention aux logs : Les clusters AKS peuvent produire énormément de données. Une configuration trop large de la collecte peut faire exploser les coûts dans Log Analytics ➡️ La collecte est donc ciblée sur les flux utiles (audit, réseau, erreurs critiques) |
5.5 Cartographier les contrôles aux régulations
Dans un environnement critique comme la PROD , sécuriser ne suffit plus :
➡️ Il faut pouvoir prouver que l’on sécurise
Et cette preuve ne se résume pas à un discours rassurant. Elle doit s’ancrer dans des référentiels officiels : ISO 27001, RGPD, SecNumCloud, NIST, CIS…
C’est ce que les auditeurs ou les clients les plus exigeants finiront toujours par demander.
Avant : des tableaux Excel et de l’huile de coude
Pendant longtemps, ce lien entre exigence réglementaire et implémentation technique passait par… un bon vieux tableau croisé dynamique :
- Colonne A : “Exigence ISO 27001 A.9.2.3”
- Colonne B : “Policy Azure – Authentification MFA activée”
- Colonne C : “Commentaire : Activée via Blueprint RG-prod”
🧠 C’était utile, mais :
- C’était manuel,
- Non scalable,
- Et surtout, impossible à maintenir dès qu’on dépasse quelques dizaines de ressources.
Maintenant : Regulatory Compliance, by design
Microsoft a fini par industrialiser ce besoin en l’intégrant directement dans Azure Policy, via un module dédié :
➡️ Regulatory Compliance (en preview)
Concrètement, ce module fait deux choses majeures :
- Il fait la cartographie à votre place :
Chaque Azure Policy est automatiquement reliée aux contrôles d’un standard (NIST, ISO, PCI, etc.) - Il fournit un tableau de bord synthétique :
Par subscription, groupe de ressources ou environnement, vous obtenez :- Le pourcentage de conformité par standard,
- La liste des écarts (non-compliances),
- Et les recommandations pour corriger.
🎯 Résultat :
Fini les justifications floues.
Tu peux pointer une policy codée, active dans le cluster, et l’associer automatiquement à une exigence RGPD ou SecNumCloud.
Static Policy : fiabilité et auditabilité
Pour aller plus loin, Microsoft a aussi introduit un nouveau type de règle :
➡️ Static Policy
Ce sont des policies Azure :
- Écrites et maintenues par Microsoft,
- Liées de façon explicite à un contrôle réglementaire,
- Et figées dans le temps, ce qui est crucial pour l’audit.
👉 Le principe est simple :
“Cette règle respecte tel point du référentiel X. Elle ne change pas sans préavis. Et elle est documentée.”
🧠 Ça change tout :
- Tu n’as plus à inventer une traduction entre sécurité et conformité,
- Tu peux démontrer que la règle vient d’un acteur reconnu (Microsoft),
- Et tu offres une preuve audit-ready, sans bricolage.
Kubernetes n’est pas un cas à part
Longtemps, les clusters Kubernetes ont été les oubliés de ces dispositifs.
Mais ce n’est plus le cas.
Dès lors que :
- Le Policy Add-on est activé dans le cluster AKS,
- Et que les politiques sont assignées au bon périmètre (ressource, groupe, subscription),
Alors le module Regulatory Compliance peut intégrer AKS dans le même tableau de bord que le reste de ton cloud
5.6 Standards et régulations pris en charge
Appliquer des politiques de sécurité, c’est une chose.
➡️ Prouver qu’elles sont conformes à un standard reconnu, c’en est une autre.
Et c’est précisément à cette intersection entre technique et gouvernance que se situe Azure Policy – Regulatory Compliance
Grâce à cette brique, la conformité devient une fonction native de l’infrastructure, et plus un tableau Excel bricolé à la dernière minute
Des packs de conformité prêts à l’emploi
La bonne nouvelle ?
Pas besoin de tout reconstruire.
Microsoft met à disposition des ensembles de politiques (Policy Initiatives), déjà alignées avec les standards du marché :
- Maintenues par Microsoft,
- Documentées dans le Trust Center
- Directement assignables à vos subscriptions ou clusters AKS via l’Azure Policy Add-on.
🧠 En clair :
La conformité devient un artefact d’infra-as-code, et non plus une tâche manuelle séparée.
Standards industriels couverts
Voici un aperçu des benchmarks et référentiels pris en charge nativement dans Azure Policy :
| Standard | Description |
|---|---|
| CIS Microsoft Azure Foundations Benchmark | Référentiel de bonnes pratiques cloud, largement reconnu. Versions 1.1.0, 1.3.0, 1.4.0. |
| Microsoft Cloud Security Benchmark (MCSB) | Le standard de sécurité recommandé par Microsoft lui-même. |
| Microsoft Cloud for Sovereignty | Ensemble de règles spécifiques à la souveraineté des données (secteur public, Europe, etc.). |
| SOC 2 / SOC TSP | Très utilisé dans les audits de sécurité et d’organisation aux US. |
| SWIFT CSP-CSCF v2021 | Obligatoire pour les réseaux de paiement interbancaires. |
| NIST SP 800-171 / 800-53 Rev. 4 et Rev. 5 | Standards fédéraux américains pour la protection des données sensibles. |
| CMMC Level 3 | Certification cybersécurité destinée aux fournisseurs du Département de la Défense US. |
Chaque policy est déjà mappée à ses exigences réglementaires, avec des contrôles prêts à l’usage.
Régulations locales et sectorielles supportées
Azure Policy intègre également des frameworks propres à certains pays ou secteurs :
| Régulation | Pays / Secteur |
|---|---|
| FedRAMP High / Moderate | États-Unis (secteur public) |
| HIPAA / HITRUST 9.2 | Santé (États-Unis) |
| Spain ENS | Administration publique (Espagne) |
| Reserve Bank of India – IT Framework | Finance (Inde) |
| RMIT Malaysia | Régulation bancaire (Malaisie) |
| NL BIO Cloud Theme | Protection des données (Pays-Bas) |
👉 Cela permet aux entreprises opérant à l’international de centraliser la conformité dans un seul cadre, même avec des contraintes multiples.
La responsabilité est partagée, mais bien balisée
Tous les standards n’impliquent pas les mêmes responsabilités entre Microsoft et ses clients.
Par exemple :
- HIPAA (US) : Microsoft est audité pour la couche d’infrastructure. Les rapports sont disponibles sur le Trust Center.
- HDS (France) : Microsoft couvre les 5 premiers domaines (hébergement, sécurité physique, etc.). L’éditeur ou l’exploitant de l’app couvre le dernier (accès applicatif et usage).
Et s’il reste des trous dans la raquette ?
Microsoft publie pour chaque standard :
- Un mapping détaillé entre policies et contrôles réglementaires,
- La liste des écarts connus (non encore couverts ou à implémenter manuellement),
- Et les politiques en cours de développement.
Par exemple, sur le Microsoft Cloud Security Benchmark, une documentation dédiée liste :
- Les contrôles couverts par les politiques existantes,
- Les règles à venir (avec ETA),
- Et les workarounds possibles via des politiques custom ou des pratiques internes.
Ce qu’il faut retenir
Gouvernance unifiée avec Azure Policy + OPA
- Une seule source de vérité pour toutes les politiques de sécurité, quels que soient les clusters (AKS, Arc, multicloud)
- Déploiement pilotable via Terraform, CLI ou portail Azure
- Intégration directe avec Defender for Cloud, Log Analytics et Sentinel
Des politiques codifiées, versionnées, traçables
- Fini les contrôles manuels : les règles sont appliquées automatiquement, sans intervention humaine.
- Chaque écart est audité, documenté et visualisable dans Azure Policy.
- Les politiques dans AKS se comportent comme des garde-fous dynamiques, activables en mode audit ou enforced.
Cartographie de la conformité automatisée
- Le module Regulatory Compliance lie chaque policy à une exigence réglementaire (ISO, NIST, RGPD…).
- Le tableau de bord fournit une vision synthétique de la conformité par environnement ou subscription.
- Les Static Policies assurent une stabilité juridique : elles sont maintenues par Microsoft et auditables.
Une conformité pensée pour l’international
- Des packs de politiques prêts à l’emploi alignés sur les standards sectoriels (HDS, HIPAA, SWIFT, etc.).
- Support des environnements souverains avec Microsoft Cloud for Sovereignty.
- Gouvernance centralisée, même dans des contextes multi-pays ou multi-normes.
En résumé :
La conformité dans Azure ne se raconte plus
Elle s’automatise, se démontre, et s’industrialise directement dans l’infrastructure
PROCHAIN ARTICLE
Dans cette 5ᵉ partie, on entre dans le monde du runtime
➡️ Là où les comportements anormaux apparaissent
➡️ Là où une configuration imprévue peut exposer ton cluster
➡️ Là où une attaque peut se jouer — et où il faut réagir vite
On verra comment Microsoft Defender for Containers te donne :
- Une posture de sécurité en continu (analyse des pods et des clusters)
- Une détection des vulnérabilités sans agent
- Une surveillance comportementale grâce à eBPF
- Et une corrélation automatique avec Sentinel pour déclencher les bonnes actions.
