Sécuriser dès le build, pas seulement dans le cluster

Aujourd’hui, je te propose une plongée complète dans la sécurisation d’AKS mais pas au travers d’un simple check des options à activer.
On va aborder les vrais sujets, ceux qui font la différence entre un cluster “qui tourne” et une plateforme sécurisée, résiliente, et gouvernée.

Ce sujet est vaste. Trop vaste pour être traité sérieusement en un seul article.
C’est pourquoi j’ai décidé de le découper en 3 parties :

Sommaire :

👉 Partie 1/6 – Sécuriser dès le build, pas seulement dans le cluster

• Intervenants
• Problématique : sécurité partagée, mais floue
• Risques AKS : intrusion, exfiltration, non-conformité
• Build sécurisé : SBOM, vulnérabilités, Checkov
• Registry sécurisé : ACR privé, signature, RBAC

👉 Partie 2/6 – Durcir l’environnement d’exécution

• Sécurité des nœuds : image, patching, accès
• Isolation des workloads : pools dédiés, sandboxing, confidential containers
• Sécurité réseau : firewall, NSG, Flow Logs

👉 Partie 3/6 – Secrets et contrôleurs d’admission

• Secrets : Kubernetes vs Azure Key Vault + CSI
• Contrôleurs d’admission : OPA, Azure Policy, Kyverno

👉 Partie 4/6 – Conformité aux politiques

• Azure Policy : gouvernance et pilotage centralisé
• Regulatory Compliance : cartographie automatique vers les standards
• Static Policies : traçabilité et auditabilité native

👉 Partie 5/6 – Sécurité runtime avec Defender for Containers

• Posture de sécurité continue
• Analyse des vulnérabilités dans les workloads
• Détection comportementale avec eBPF
• Corrélation Azure (Sentinel, Security Center)

👉 Partie 6/6 – Gestion des certificats et de la confiance

• Cert-Manager : automatisation des certificats TLS dans AKS
• Cas d’usage avancés : rotation, AC internes, Let’s Encrypt
• Intégration avec Azure Key Vault & External Issuer

1. INTERVENANTS

DJEBBOURI Younes
Architecte Azure et DevOps 🚀💻✨

2. PROBLÉMATIQUE

Quand on parle de sécuriser AKS, on pense souvent à ce qui se passe dans le cluster : réseaux, pods, secrets, RBAC…
Mais en réalité, le risque entre bien plus tôt, dès la construction des images. Et c’est souvent là que tout commence… ou dérape

Dans un environnement cloud managé, la promesse de simplicité est tentante : la plateforme gère le cluster, le scaling, l’API…
Mais la sécurité de ce que tu construis et déploies reste entièrement entre tes mains.

Et c’est précisément là que se niche le danger :

• Des chaînes de build opaques, où personne ne sait ce que contient une image
• Des dépendances open source tirées sans vérification
• Des secrets oubliés dans un fichier YAML ou un Dockerfile
• Des scans de vulnérabilités absents ou désactivés
• Et surtout… des outils en place, mais jamais intégrés dans le pipeline CI/CD

Cette première partie se concentre donc sur la base de tout : la chaîne de construction des images.
Parce qu’avant de parler runtime, réseau ou secrets, il faut déjà savoir ce qu’on construit, et avec quoi.

Dans les sections qui suivent, on va :

• Identifier les risques concrets liés au build dans AKS,
• Mettre en place une stratégie de sécurité dès le pipeline CI/CD,
• Découvrir des outils concrets comme Checkov, SBOM, et la signature d’image (Notary v2),
• Et renforcer la sécurité de ton registre ACR, point d’entrée de toute ta production conteneurisée

3. RISQUES A PRENDRE EN COMPTE

Avant de sécuriser un cluster AKS, il faut commencer par identifier ce qui est réellement à protéger. Ce ne sont pas les outils ou les politiques qui dictent la stratégie ce sont les risques métiers, souvent bien plus concrets qu’on ne le pense.

Dans Kubernetes, et plus encore dans AKS, ces risques sont démultipliés par plusieurs facteurs :

• une chaîne de build complexe et peu maîtrisée,
• des configurations par défaut parfois trop permissives,
• une adoption rapide, au détriment de la gouvernance,
• et une illusion de sécurité offerte par l’infrastructure managée.

Or les attaques sur des clusters Kubernetes ne relèvent plus de la science-fiction. Elles exploitent des erreurs simples, mais structurelles :

• Un plan de contrôle exposé à Internet sans restriction,
• Des secrets en clair dans des dépôts Git publics,
• Des images non signées, tirées depuis des registres ouverts,
• Des identités internes avec des privilèges bien trop larges.

Ces failles ne sont pas isolées elles s’inscrivent dans des catégories de risques récurrents, que toute stratégie de sécurité AKS doit adresser en priorité :

Et le vrai défi, ce n’est pas uniquement de les connaître.
➡️ C’est de les adresser collectivement, dans un contexte où la sécurité se répartit entre Dev, Infra, SecOps, Produit, et parfois… personne en particulie

4. PERIMETRES DE SECURITE

4.1 Sécurité du Build

Dans une chaîne CI/CD, le danger ne vient pas toujours de ce qu’on déploie mais bien de ce qu’on construit où chaque composant intégré devient un vecteur potentiel de vulnérabilité

Et c’est précisément là que les chaînes CI/CD laissent encore trop d’angles morts : images non contrôlées, dépendances floues, absence de traçabilité, absence de garde-fous dans les pipelines…

💡 La question n’est donc plus : “Est-ce que mon image fonctionne ?”, mais bien :
“Puis-je garantir que ce que je construis est sécurisé, traçable, et conforme dès la première ligne ?”

Comprendre ce qu’on construit, ligne par ligne

Construire une image de conteneur, c’est hériter de centaines de composants externes :

• bibliothèques open source,
• dépendances systèmes,
• outils utilitaires,
• frameworks de build.

Et chacun de ces éléments peut contenir une faille critique connue (CVE), ou une incompatibilité réglementaire (ex : licence interdite).

C’est pourquoi deux fondations sont indispensables :

• Analyse de vulnérabilités (Vulnerability Scan) : détecter les failles connues dans les composants embarqués ;
• SBOM (Software Bill of Materials) : inventaire clair et versionné de tous les composants utilisés.

💡 Un SBOM bien généré permet de répondre immédiatement à la question :
“Mon image contient-elle log4j-core ? Si oui, dans quelle version, et sur quels pods tourne-t-elle actuellement ?”

Outils de contrôle à la source

Plusieurs outils open source permettent d’intégrer ces contrôles dès le code :

➡️ Checkov est aujourd’hui le choix recommandé dans un contexte Azure/Kubernetes :

• Compatible multi-technos (K8s, Terraform, Helm, Bicep, ARM),
• Intégration facile dans Azure DevOps, GitHub Actions, GitLab CI…

Il permet d’avoir une politique unifiée, quel que soit le langage utilisé

Intégration dans le pipeline CI/CD

La clé, ce n’est pas l’outil.
C’est son intégration systématique dans le pipeline :

Chaque pull request = une analyse automatique de conformité.

Le pipeline devient un pare-feu de conformité, capable de bloquer par exemple :

• une image contenant une faille critique,
• un secret hardcodé dans un YAML,
• un manifeste sans readinessProbe.

Et ce contrôle est automatisé, traçable et biensure documenté

Maîtriser les dépendances

Règle d’or : aucune image ne doit être tirée directement d’un registre public.

✅ Toutes les images doivent être importées dans un ACR privé, scannées, versionnées, validées

Cela permet de :

• Gérer les mises à jour sans surprise,
• Répondre à une alerte vulnérabilité avec une visibilité claire,
• Imposer des règles d’accès par environnement (ex : Dev vs Prod).

💡 Microsoft recommande également de désactiver les pulls directs en configurant des politiques OPA interdisant les registres non approuvés

Gérer les exceptions en production

Il arrivera qu’une vulnérabilité soit présente dans un composant critique… sans alternative immédiate.

Dans ce cas :

• Une tolérance contrôlée peut être mise en place (approbation temporaire, journalisation de la dérogation)
• Accompagnée d’un plan d’action correctif (patch ou migration planifiée)

L’important : ne jamais ignorer une faille la contextualiser, la documenter, et l’encadrer

Surveiller ce qui tourne : Defender for Containers

Scanner à l’entrée, c’est bien.
Surveiller ce qui tourne, c’est indispensable.

Microsoft Defender for Containers permet une double visibilité :

• 🟢 Scan continu des images dans ACR,
• 🟢 Analyse des workloads actifs dans les clusters AKS.

Exemple :
Une image vulnérable est détectée dans ACR → alerte 1
La même image tourne sur un pod en prod ? → alerte 2 prioritaire.

Et tout cela sans agent, ni modification des images

Environnement Dev : flexibilité encadrée

En Dev, on peut assouplir certaines règles :

• Bloquer les pulls directs,
• Autoriser l’import manuel dans ACR (scan automatique),
• Remonter des alertes dès l’import.

L’idée n’est pas de brider, mais de responsabiliser les développeurs sans sacrifier la sécurité

Synchronisation automatique ACR ↔ registres publics

Azure Container Registry permet d’automatiser l’import :

• d’images populaires (ex : alpine, nginx),
• en les scannant immédiatement,
• tout en gardant un historique d’usage.

Plus besoin de gérer les imports à la main, tout est centralisé, sécurisé, historisé.

Choisir des images minimales

Utiliser des images comme Alpine permet :

• une surface d’attaque réduite,
• moins de dépendances implicites,
• une moindre exposition aux vulnérabilités.

💬 Oui, cela demande parfois des efforts supplémentaires.
Mais c’est un gain de sécurité surtout en environnement critique

En sécurisant le build, on évite que des vulnérabilités entrent dans le système
Mais ce n’est que la première moitié du chemin
L’étape suivante ? Le registre. Car entre l’image construite et le pod exécuté, il y a un canal critique qu’il faut, lui aussi, verrouiller

4.2 Sécurité du Registry

Après avoir sécurisé le build, une autre question cruciale se pose :
Peut-on faire confiance au registre qui héberge nos images ?

Dans AKS, le registre de conteneurs est un point central.

C’est lui qui alimente les clusters, propulse les mises à jour, distribue le code. Et s’il est compromis, c’est toute la supply chain qui l’est

Cloisonner le registre : ACR privé uniquement

Le choix standard dans Azure, c’est Azure Container Registry (ACR).
Mais par défaut, il est accessible publiquement ce qui n’est pas acceptable dans un environnement sécurisé

✅ La première étape consiste à isoler le registre sur un réseau privé Azure (VNet) via un Private Endpoint.

Cela permet de garantir que :

• seuls les clusters internes peuvent accéder à ACR
• aucun accès public (même en lecture seule) n’est autorisé
• l’exfiltration via des pull sauvages devient impossible

❇️ Bonus : coupler cela avec un pare-feu réseau sur ACR, en autorisant uniquement les plages IP de vos clusters, renforce l’étanchéité du canal.

Centraliser la source : un seul registre approuvé

Dans un environnement maîtrisé, le cluster AKS ne doit “faire confiance” qu’à un seul registre.

Cela signifie :

• que les manifestes Kubernetes ne doivent référencer que l’URL de votre ACR
• qu’aucun image: ne pointe vers Docker Hub, Quay, ou GitHub Container Registry
• et qu’un contrôle est en place pour bloquer tout autre registre

➡️ Ce verrou est mis en œuvre via OPA Gatekeeper, avec une règle du type :

violation[{"msg": msg}] {
  input.review.object.spec.containers[_].image
  not startswith(input.review.object.spec.containers[_].image, "acrmonorg.azurecr.io/")
  msg := "Les images doivent provenir de l’ACR privé de l’organisation"
}

🎯 Résultat : aucune image non validée ne peut être injectée dans le cluster, même en cas d’erreur humaine

Authentification via Managed Identity

Chaque cluster AKS utilise une Managed Identity (UAMI) pour tirer les images. Cette identité :

• est affectée via Azure RBAC (AcrPull sur l’ACR),
• ne fonctionne que pour les ressources explicitement autorisées,
• permet une traçabilité par cluster, via Azure Activity Logs.

Cela évite :

• la gestion manuelle de credentials ou de secrets Docker,
• les fuites d’identifiants dans les pipelines,
• les accès hors périmètre ou inter-clusters non justifiés.

❇️ Bonus : on peut aller plus loin en associant des permissions conditionnelles (PIM, expirations, scope limité) sur cette identité managée.

Contrôler le contenu : signature d’image avec Notary v2

Sécuriser le canal, c’est bien.
Vérifier le contenu, c’est encore mieux.

C’est là qu’intervient la signature d’image avec Notary v2, désormais intégrée à ACR (SKU Premium). Ce mécanisme permet de :

• signer les images en fin de pipeline (via Sigstore/Cosign ou Notation)
• stocker la signature dans ACR
• et bloquer tout déploiement d’image non signée

AKS peut alors vérifier, au moment du pull, que :

• l’image est bien celle produite et validée en interne,
• elle n’a pas été modifiée,
• sa provenance est prouvée.

📌 Microsoft permet cette vérification via un plugin d’admission compatible avec Gatekeeper ou Kyverno

Pourquoi ce mécanisme n’est-il pas encore généralisé ?

Parce que la signature soulève plus de questions de gouvernance que de technique :

Anticiper les exigences réglementaires

Certaines industries (santé, finance, automobile, défense…) imposent déjà des exigences sur :

• la provenance logicielle (supply chain trust),
• la traçabilité du cycle de build,
• la non-altération du binaire entre build et prod.

Demain, ces exigences seront la norme.

Prévoir la signature dès maintenant, même inactive, permet de :

• anticiper les audits,
• valider les intégrations,
• se conformer plus rapidement quand cela deviendra obligatoire.

En Resumé

La sécurité du registre n’est pas un “plus” :
c’est le point d’entrée de votre chaîne de production logicielle.

Et comme pour toute chaîne de production… si l’entrée est contaminée, tout ce qui en sort l’est aussi

PROCHAIN ARTICLE

Dans la Partie 2, on quittera la supply chain pour descendre d’un cran :
➡️ Comment durcir l’environnement d’exécution ?
Du choix de l’image des nœuds jusqu’à l’isolation des workloads, en passant par la gestion réseau et la sécurité runtime avec Defender for Containers

📎 Pour aller plus loin (docs Microsoft) :

• Bonnes pratiques ACR (Azure Container Registry)
• Présentation de Microsoft Defender for Containers
• Support de Notary v2 dans ACR (Preview)
• Utiliser OPA Gatekeeper avec AKS
• Azure Policy pour Kubernetes (AKS)

🙏 Remerciements

Cet article prolonge des échanges issus de plusieurs workshops conduits par Benoît Sautierre, dont la vision et l’animation ont largement nourri les réflexions présentées ici. Expert engagé et passionné, il a su créer un cadre de réflexion stimulant, pour lequel je lui adresse mes plus vifs remerciements