1. INTERVENANTS

DJEBBOURI Younes
Architecte Azure et DevOps 🚀💻✨

2. PROBLÉMATIQUE

Tu as sécurisé ce que tu construis (build, registry).
Tu as renforcé ce que tu exécutes (nœuds, réseau, pods).

Mais il reste une zone critique, souvent négligée : la gouvernance de la sécurité elle-même.

• ➡️ Qui définit les règles ?
• ➡️ Comment s’assurer qu’elles sont respectées sans dépendre d’un oubli humain ?
• ➡️ Et surtout : comment prouver, à tout moment, que le cluster est conforme, traçable et résilient aux audits ?

Dans le monde AKS, la sécurité ne repose pas que sur des firewalls et des scans. Elle vit aussi dans :

• Les secrets que tu exposes (ou pas)
• Les contrôles automatisés à chaque déploiement
• Les politiques qui doivent s’imposer à tous, sans exception
• Et les exigences réglementaires (RGPD, HDS, ISO…) que ton architecture doit pouvoir justifier

🎯 C’est ici que la sécurité devient un sujet de gouvernance, pas juste d’ingénierie.

Et c’est ce que cette partie va adresser, en explorant :

• La gestion industrielle des secrets avec Azure Key Vault + CSI
• L’application automatique de règles via OPA Gatekeeper ou Kyverno
• L’usage de Azure Policy pour piloter la conformité sans effort manuel
• Le rôle de Defender for Containers comme pilier transversal de pilotage
• Et l’intégration des exigences réglementaires et certificats (avec Cert-Manager)

💡 L’objectif : passer d’un cluster sécurisé à un cluster gouverné, où les bonnes pratiques ne sont pas des options, mais des standards, vérifiés en continu

4. PÉRIMÈTRES DE SÉCURITÉ

4.5 Sécurité Kubernetes

Gestion native des Secrets Kubernetes

Dans Kubernetes, la gestion des secrets est un sujet sensible. Et comme souvent avec les configurations par défaut, ce que fait la plateforme « toute seule » est fonctionnel, mais pas suffisant d’un point de vue sécurité

Le comportement natif : simple, mais limité

Par défaut, quand on déclare un Secret dans un manifeste Kubernetes :

• Les données sont encodées en base64, pas chiffrées
• Le secret est stocké dans etcd
• Il est associé à un namespace, ce qui évite qu’un pod d’un autre namespace y accède
• Et quand un pod a besoin de ce secret, il est monté en mémoire (tmpfs), jamais écrit sur le disque
• Lorsqu’il n’est plus utilisé (pod supprimé), le secret est effacé automatiquement de la mémoire du nœud

Ce fonctionnement, assez propre d’un point de vue technique, permet de limiter la persistance et l’exposition des données sensibles.
Mais il ne protège pas le secret à la source : etcd conserve les secrets sans chiffrement fort, ce qui est vulnérable

Des limitations connues

Ce système de gestion native ne chiffre pas réellement les secrets. Il les encode simplement ce qui ne protège pas contre un accès non autorisé à la base etcd
Par ailleurs :

• Il n’y a pas de rotation automatique
• Pas de journalisation native de l’accès ou de la consommation des secrets
• Et pas d’intégration avec un système d’autorisation externe (comme Azure Key Vault)

👉 En clair : pour des données réellement sensibles (credentials, tokens d’API, certificats…), la gestion native ne suffit pas

🚨 Limitations critiques

Ce modèle natif montre vite ses limites dans un environnement de production :

Ce modèle est donc adapté à des charges simples ou à des environnements non sensibles, mais devient rapidement insuffisant pour :

• Les clés d’API critiques
• Les identifiants de base de données en production
• Les secrets OAuth ou JWT
• Ou tout artefact sécurisé partagé entre plusieurs équipes ou services

ETCD Encryption

Il est possible d’activer le chiffrement d’etcd dans AKS, via des clés gérées dans Azure Key Vault
Ce chiffrement s’appuie sur encryption at rest, et doit être explicitement activé sur les clusters existants via ARM ou Azure CLI

Gestion avancée des secrets avec Azure

On l’a vu : la gestion native des secrets Kubernetes remplit le minimum fonctionnel.
Mais dès qu’on parle de production, de compliance ou de cycle de vie long, ça ne tient plus.

Et dans un environnement Azure, la réponse la plus robuste et la plus naturelle, c’est Azure Key Vault, associé au CSI Driver pour Kubernetes

Le CSI Driver : interface native entre AKS et Key Vault

La pierre angulaire de cette intégration, c’est le CSI (Container Storage Interface) Secrets Store Driver

Son rôle : monter dynamiquement des secrets, clés ou certificats depuis Key Vault en tant que volume éphémère dans un pod

🟢 Avantage clé :

L’application n’a aucune connaissance du vault.
Aucun SDK à intégrer, aucun endpoint externe à appeler

Côté cluster, le CSI Driver s’occupe de :

• Authentifier le pod (via Workload Identity ou Managed Identity)
• Aller chercher le secret dans le Key Vault correspondant
• Le monter en RAM, sur un volume temporaire (tmpfs)
• Et le retirer dès que le pod disparaît

📌 À retenir : le secret n’apparaît jamais dans etcd, ni dans les manifestes, ni dans le kubectl describe

Workload Identity

Pour faire ce lien, deux options existent :

• Managed Identity liée au nœud (VMSS)
• Ou Workload Identity, associée à un pod donné

👉 La Workload Identity est le choix recommandé, car elle permet :

• Une séparation stricte entre workloads
• Une traçabilité granulaire dans Azure (logs d’audit)
• Une gestion fine des droits : chaque pod peut être autorisé à un secret précis, rien de plus.

Concrètement, on mappe un ServiceAccount Kubernetes à une identité Azure, ce qui permet une politique RBAC bien plus lisible et maîtrisée

Rotation et synchronisation des secrets

Autre avantage crucial : la rotation automatique.

Dès qu’un secret est mis à jour dans Azure Key Vault, le cluster peut :

• Soit le détecter automatiquement (si la synchro périodique est activée)
• Soit l’appliquer au prochain redémarrage de pod

Sinon, une relance du pod (via kubectl rollout restart) reste nécessaire

➡️ Cas concret : un certificat TLS renouvelé automatiquement côté Key Vault peut être mis à jour côté application sans redéploiement complet un vrai gain en agilité

Séparation des accès : au-delà du CSI Driver

Par défaut, tous les pods d’un même node pool partagent l’identité Azure de ce pool
Ce qui veut dire qu’un pod mal configuré pourrait accéder à un secret qui ne le concerne pas

Pour éviter ça dans un contexte sensible :

• Crée un node pool dédié par application critique
• Attribue une identité Azure propre à chaque node pool
• Restreins les droits d’accès à Key Vault via des rôles Azure au niveau du secret

🎯 Résultat : même en cas d’erreur de manifeste ou de privilège trop large, la séparation est garantie par l’infrastructure

Gouvernance, audit, conformité

Un des apports majeurs de Key Vault, c’est l’alignement avec les exigences de sécurité :

4.6 Contrôleurs d’admission

Un contrôleur d’admission, c’est quoi exactement ?

« Un contrôleur d’admission intercepte les requêtes envoyées au serveur API Kubernetes juste avant qu’elles ne soient enregistrées dans etcd, une fois que l’authentification et l’autorisation ont été validées. »

Derrière cette définition se cache une fonctionnalité clé de la gouvernance AKS : la capacité d’imposer des règles de sécurité et de conformité de façon automatique, cohérente et non intrusive.

Vue générale

Dans Kubernetes, être authentifié et autorisé ne suffit pas : on peut encore créer un objet mal configuré, risqué ou non conforme.

C’est ici que les contrôleurs d’admission entrent en jeu :

• Ils s’insèrent directement dans le Control Plane
• Ils agissent avant que la ressource ne soit stockée dans etcd
• Et surtout, ils peuvent bloquer, valider ou modifier une requête à la volée

Deux types existent :

• Validateurs : ils bloquent les objets non conformes (ex : une image tirée depuis Docker Hub)
• Mutateurs : ils enrichissent ou corrigent un objet avant son enregistrement (ex : ajout d’un label ou de limites de ressources)

Ils se branchent au cœur du Control Plane. Et dans AKS, deux approches principales s’imposent : OPA via Azure Policy ou Kyverno.

OPA + Azure Policy

Dans AKS, la sécurité ne se limite pas à l’infrastructure ou aux workloads, elle passe aussi par la capacité à faire respecter des règles automatiquement.

C’est ici qu’intervient Azure Policy for Kubernetes, qui s’appuie sur Gatekeeper, un contrôleur d’admission basé sur Open Policy Agent (OPA)

⚠️ Contrairement à une idée reçue, OPA n’est pas intégré “nativement” à AKS

C’est l’add-on Azure Policy qui déploie et configure automatiquement Gatekeeper dans les clusters. Cela permet d’appliquer des politiques de conformité sans installer OPA manuellement, mais uniquement via ce cadre supporté par Microsoft

Pourquoi cette solution est recommandée dans AKS

• Déploiement simplifié : activable via CLI, portail ou Terraform.
• Règles prêtes à l’emploi : Microsoft propose un catalogue complet (privileged, registry, labels, namespace…).
• Gouvernance unifiée : traçabilité via Azure Policy, Defender for Cloud, Log Analytics.

🎯 Résultat : tu appliques la même gouvernance sur ton cluster AKS que sur tes VM, tes réseaux ou tes Key Vault

Des cas d’usage concrets

OPA dans AKS permet d’imposer des règles comme :

Ce sont des règles simples, mais qui changent tout : elles transforment la gouvernance en mécanisme automatique, et non plus en contrôle manuel a posteriori

Terraform friendly

Autre point fort : OPA dans AKS est pilotable via Terraform.

resource "azurerm_kubernetes_cluster" "aks" {
  ...
  azure_policy_enabled = true
}

Et tu peux ensuite déployer des definitions de politiques avec des scopes clairs (subscription, resource group) et un mode :

• Audit (non bloquant, observabilité)
• Enforced (bloquant, sécurité active)

Tout est journalisé automatiquement (logs d’audit, éventuelles dérogations), et corrélable avec Sentinel ou un autre SIEM

Kyverno

OPA n’est pas seul sur le terrain.
Dans l’univers des contrôleurs d’admission, Kyverno s’est rapidement imposé comme l’alternative la plus naturelle pour les environnements Kubernetes purs.

Et pour cause : Kyverno parle le langage natif de Kubernetes.

Une intégration au plus proche de l’ADN Kubernetes

Là où OPA repose sur un moteur externe (et sur un langage dédié comme Rego), Kyverno fonctionne entièrement dans le cluster.
Ses politiques sont des objets Kubernetes à part entière (des CustomResourceDefinitions), rédigés en YAML, déclarés comme n’importe quel déploiement.

Pas besoin de connaître Rego. Pas besoin de s’extraire du modèle déclaratif.

➡️Pour un ingénieur Kubernetes, écrire une règle Kyverno, c’est comme écrire un manifeste :

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: enforce-image-source
spec:
  validationFailureAction: enforce
  rules:
    - name: check-image-registry
      match:
        resources:
          kinds:
            - Pod
      validate:
        message: "Seules les images du registre ACR sont autorisées"
        pattern:
          spec:
            containers:
              - image: "myacr.azurecr.io/*"

👉 C’est lisible, clair, versionnable. Et ça fait exactement ce qu’on attend.

🟢 Les avantages de Kyverno

• Pas de langage à apprendre : YAML, point.
• Déploiement natif : tout se gère comme un ensemble de ressources Kubernetes.
• Supporté officiellement par la CNCF : Kyverno est un projet gradué, avec une communauté active.
• Règles dynamiques : tu peux injecter des labels automatiquement, muter des manifestes à la volée, ou refuser des objets malformés.

Bref, Kyverno est taillé pour les clusters Kubernetes “from scratch”, où chaque composant est déployé et contrôlé manuellement.

🛑Mais dans AKS… on y réfléchit à deux fois

Dans un contexte Azure et en particulier sur AKS Kyverno a quelques points faibles :

• 🔴 Pas d’intégration native avec Azure Policy : on sort du modèle “as code” unifié Azure
• 🔴 Pas de gouvernance centralisée : chaque cluster gère ses règles, sans portail commun pour l’audit ou la conformité.
• 🔴 Déploiement et maintenance manuels : il faut installer Kyverno, gérer les CRDs, maintenir le cycle de vie des policies

C’est faisable, bien sûr. Mais dans un environnement Azure à grande échelle, où la priorité est souvent la standardisation, l’alignement et l’audit, OPA garde une longueur d’avance.

Pourquoi nous restons sur OPA

Le choix entre OPA et Kyverno n’est pas une question d’idéologie.
C’est une question de contexte et d’alignement :

🎯 Dans un écosystème Azure, OPA coche toutes les cases : il est prêt, intégré, traçable, et supporté par Microsoft.
OPA couvre déjà 95 % des besoins dans la majorité des projets

💡 Ce qu’il faut retenir

Kyverno est un excellent choix dans des clusters Kubernetes autonomes, où l’on cherche la souplesse et la proximité avec le YAML natif

Mais dans un environnement managé comme AKS, avec des enjeux de conformité, de traçabilité, et de standardisation, OPA reste la solution la plus alignée avec l’écosystème Azure.

La sécurité efficace ne repose pas toujours sur la techno la plus “pure”, mais sur celle qui s’intègre le mieux à la chaîne de valeur existante

PROCHAIN ARTICLE

Dans la Partie 4, on changera de prisme :
➡️ Comment passer d’une sécurité présumée à une sécurité prouvée ?

On parlera conformité, mais pas au sens bureaucratique.
On verra comment industrialiser la sécurité avec des outils qui appliquent et justifient les bonnes pratiques :

• Azure Policy + OPA pour imposer des règles sans friction,
• Regulatory Compliance pour cartographier les exigences RGPD, ISO, HDS…
• Static Policies pour avoir des preuves audibles, traçables, et prêtes à montrer aux auditeurs.

📎 Pour aller plus loin (docs Microsoft) :

• Azure Key Vault integration with AKS via CSI
• Workload Identity in AKS
• Etcd Encryption in AKS
• Azure Policy for Kubernetes (with OPA Gatekeeper)
• Install Kyverno on Kubernetes
• OPA Gatekeeper official docs
• Azure RBAC for Key Vault