Toute la chaîne de preuves construite en amont (signature, provenance, SBOM) ne sert à rien si personne ne la vérifie au moment d'entrer en production. Le domaine Déploiement & admission (DPL) est ce dernier rempart.
Signer et attester en amont n'a de valeur que si un point de contrôle les
vérifie avant la production. C'est le rôle du contrôleur d'admission
(Kyverno, OPA Gatekeeper) : à l'entrée du cluster, il intercepte chaque
déploiement et applique des règles bloquantes, n'autorisant que les artefacts
signés, à la provenance vérifiée (contre un builder et une source
attendus, pas la simple présence d'une attestation), à la configuration sûre
(pas de privileged), au digest immuable, déployés au moindre privilège,
segmentés et réversibles. Ce qui ne passe pas est rejeté.
Concrètement, ces exigences parent : l'artefact non vérifié déployé faute de contrôle d'admission, le CI à l'accès prod permanent compromis, la configuration dangereuse (privileged) admise, le mouvement latéral sans segmentation réseau, et l'impossibilité de revenir en arrière sans rollback. Cette page couvre les 15 exigences SOCLE du domaine, des fondamentales (R1) aux souveraines (R3).
L'admission est le dernier filtre avant la production : ce qui passe s'exécute.
Les pièges à éviter
Section intitulée « Les pièges à éviter »Les erreurs les plus fréquentes sur ce périmètre :
Les exigences essentielles
Section intitulée « Les exigences essentielles »Quatre exigences forment la base : n'admettre que le signé et conforme, séparer les privilèges de déploiement, imposer une configuration sûre, et vérifier la provenance contre les sources attendues.
contrôle d'admission : seuls les artefacts signés et conformes sont déployés.#
Sans contrôle d'admission, le cluster déploie n'importe quel artefact, y compris non vérifié ou piégé. N'admettre que les artefacts signés et conformes garantit que seul ce qui a passé les contrôles amont s'exécute : c'est la barrière finale qui relie la chaîne de confiance jusqu'à l'exécution réelle.
- Preuve attendue
- Politique d'admission : seuls les artefacts signés et conformes sont déployés.
- Outillage
- Kyverno Gatekeeper
Correspondances & menaces parées 6 standards · 3 menaces
Le consommateur n'utilise ni la signature ni la provenance avant de consommer un artefact, annulant tout le bénéfice de leur génération. La chaîne de confiance ne tient que si le dernier maillon vérifie SLSA (verification). Un artefact non signé, non scanné ou hors politique passe le contrôle d'admission et entre en production. Le dernier filtre avant l'exécution laisse passer ce qu'il devait bloquer CICD-SEC-9. La politique d'admission (vérification de signature, provenance, conformité) est contournée ou désactivée, laissant déployer des artefacts non vérifiés. Une exception ou une faille de configuration neutralise le garde-fou SLSA (verification).
séparation des privilèges de déploiement ; pas d'accès prod non contrôlé depuis le CI.#
Un CI disposant d'un accès prod permanent devient, compromis, un chemin direct vers la production. Séparer les privilèges de déploiement et interdire l'accès prod non contrôlé depuis le CI cloisonnent : une compromission du pipeline n'emporte pas automatiquement la production, qui exige un passage contrôlé et distinct.
- Preuve attendue
- Séparation des privilèges de déploiement ; absence d'accès prod non contrôlé depuis le CI.
- Outillage
- Kyverno Gatekeeper
Correspondances & menaces parées 7 standards · 2 menaces
Le manifeste de déploiement est mal configuré (privilèges excessifs, montages sensibles, réseau ouvert), exposant la charge dès sa mise en service. La faiblesse n'est pas dans l'artefact mais dans la façon dont il est déployé (CIS Kubernetes) CIS K8s. Un jeton d'accès de longue durée est volé et réutilisé tant qu'il n'est pas révoqué, sans nouvelle authentification. La durée de vie sans rotation maximise la valeur du vol CICD-SEC-6.
politiques de configuration sécurisée à l'admission (pas de privileged, etc.).#
Un déploiement aux réglages dangereux (privileged, hostPath) passe si rien ne l'en empêche. Appliquer des politiques de configuration sécurisée à l'admission refuse ces configurations à risque avant exécution : la sécurité de la charge est vérifiée au moment du déploiement, pas constatée après coup en production.
- Preuve attendue
- Politiques d'admission de configuration sécurisée (pas de privileged, etc.).
- Outillage
- Kyverno Gatekeeper
Correspondances & menaces parées 6 standards · 1 menace
Le manifeste de déploiement est mal configuré (privilèges excessifs, montages sensibles, réseau ouvert), exposant la charge dès sa mise en service. La faiblesse n'est pas dans l'artefact mais dans la façon dont il est déployé (CIS Kubernetes) CIS K8s.
vérification de provenance à l'admission contre un builder et une source attendus (allowlist), pas la simple présence d'une attestation.#
La simple présence d'une attestation ne prouve rien : un attaquant peut en joindre une. Vérifier la provenance contre un builder et une source attendus (allowlist) à l'admission garantit que l'artefact vient bien de votre chaîne, pas seulement qu'il porte une attestation quelconque, fermant l'angle du faux justificatif.
- Preuve attendue
- Politique d'admission vérifiant la provenance contre builder/source attendus (allowlist).
- Outillage
- Kyverno Gatekeeper
Correspondances & menaces parées 6 standards · 6 menaces
Le build est lancé depuis une source ou un fork non officiel, produisant un artefact d'apparence légitime à partir de code non vérifié. L'origine du build n'est pas garantie sans provenance liant artefact et source SLSA (D) SLSA (E). L'attestation de provenance est forgée ou altérée pour faire croire qu'un artefact provient d'un build légitime. Sans provenance non falsifiable (build isolé, signature), la traçabilité est trompeuse SLSA (verification). Le build est compromis en amont, si bien que la provenance est techniquement valide mais atteste d'un artefact malveillant. La provenance prouve l'origine, pas l'innocuité : un build corrompu produit une attestation correcte d'un mauvais résultat SLSA (D) SLSA (E). Le consommateur n'utilise ni la signature ni la provenance avant de consommer un artefact, annulant tout le bénéfice de leur génération. La chaîne de confiance ne tient que si le dernier maillon vérifie SLSA (verification). L'attaquant publie avec des identifiants d'éditeur valides (volés ou détournés), rendant la publication indistinguable d'une légitime côté registre. La détection repose alors sur le comportement, pas sur l'authentification CNCF Publishing. La politique d'admission (vérification de signature, provenance, conformité) est contournée ou désactivée, laissant déployer des artefacts non vérifiés. Une exception ou une faille de configuration neutralise le garde-fou SLSA (verification).
Vérifier signature et provenance
Section intitulée « Vérifier signature et provenance »Le premier devoir de l'admission est de vérifier l'origine : signature de l'image (avec un policy controller type Cosign) et provenance conforme. Sur les charges sensibles, on n'admet que les artefacts à provenance non falsifiable (build isolé L3).
vérification de signature de l'image/artefact avant déploiement.#
Déployer une image sans vérifier sa signature, c'est faire confiance au registre sans contrôle. Vérifier la signature avant déploiement garantit que l'image n'a pas été substituée ou altérée depuis sa publication : seul l'artefact authentique et intègre atteint l'exécution, dernière vérification côté consommateur.
- Preuve attendue
- Vérification de signature à l'admission (cosign/policy-controller).
- Outillage
- Kyverno Gatekeeper
Correspondances & menaces parées 3 standards · 2 menaces
Le build est compromis en amont, si bien que la provenance est techniquement valide mais atteste d'un artefact malveillant. La provenance prouve l'origine, pas l'innocuité : un build corrompu produit une attestation correcte d'un mauvais résultat SLSA (D) SLSA (E). Un artefact non signé, non scanné ou hors politique passe le contrôle d'admission et entre en production. Le dernier filtre avant l'exécution laisse passer ce qu'il devait bloquer CICD-SEC-9.
admission restreinte aux artefacts à provenance non falsifiable (L3) pour les charges sensibles.#
Pour une charge sensible, une provenance falsifiable ne suffit pas. Restreindre l'admission aux artefacts à provenance non falsifiable (SLSA L3) garantit que seul du code dont l'origine est prouvée de façon infalsifiable s'exécute, écartant tout artefact dont la chaîne de production n'offre pas ce niveau de garantie.
- Preuve attendue
- Admission restreinte aux artefacts à provenance L3 pour les charges sensibles.
- Outillage
- Kyverno Gatekeeper
Correspondances & menaces parées 2 standards · 2 menaces
Le build est compromis en amont, si bien que la provenance est techniquement valide mais atteste d'un artefact malveillant. La provenance prouve l'origine, pas l'innocuité : un build corrompu produit une attestation correcte d'un mauvais résultat SLSA (D) SLSA (E). Un artefact non signé, non scanné ou hors politique passe le contrôle d'admission et entre en production. Le dernier filtre avant l'exécution laisse passer ce qu'il devait bloquer CICD-SEC-9.
Imposer une configuration sécurisée
Section intitulée « Imposer une configuration sécurisée »Au-delà de l'origine, l'admission durcit la configuration : un contrôleur de
politiques bloquant (pas en simple avertissement), des network policies
en default-deny, et des profils d'exécution durcis (seccomp, AppArmor, FS
en lecture seule).
contrôleur d'admission de politiques (OPA Gatekeeper / Kyverno) en mode bloquant.#
Des politiques en mode avertissement sont ignorées : seul le blocage protège réellement. Un contrôleur d'admission (OPA Gatekeeper, Kyverno) en mode bloquant refuse les déploiements non conformes avant exécution, appliquant vos règles de façon non contournable plutôt que de produire un rapport que personne ne traite.
- Preuve attendue
- Contrôleur d'admission (OPA Gatekeeper/Kyverno) en mode bloquant.
- Outillage
- Checkov KICS Conftest
Correspondances & menaces parées 2 standards · 2 menaces
Un artefact non signé, non scanné ou hors politique passe le contrôle d'admission et entre en production. Le dernier filtre avant l'exécution laisse passer ce qu'il devait bloquer CICD-SEC-9. La politique d'admission (vérification de signature, provenance, conformité) est contournée ou désactivée, laissant déployer des artefacts non vérifiés. Une exception ou une faille de configuration neutralise le garde-fou SLSA (verification).
segmentation réseau des charges (network policies, default-deny).#
Par défaut, les charges communiquent librement : une compromise atteint toutes les autres. Une segmentation réseau (network policies, default-deny) cloisonne les flux : chaque charge ne parle qu'à ce dont elle a besoin, contenant un mouvement latéral à son périmètre au lieu de laisser un pied dans la porte ouvrir tout l'environnement.
- Preuve attendue
- Network policies default-deny appliquées.
- Outillage
- Checkov KICS Conftest
Correspondances & menaces parées 2 standards · 1 menace
Après une intrusion initiale, l'attaquant se déplace latéralement et installe des mécanismes de persistance pour conserver l'accès. La compromission s'étend dans le temps et l'espace faute de détection et de segmentation ATT&CK.
profils d'exécution durcis (seccomp, AppArmor, système de fichiers en lecture seule).#
Une charge sans profil d'exécution durci dispose de tous les appels système et d'un système de fichiers inscriptible, facilitant l'évasion et la persistance. Durcir l'exécution (seccomp, AppArmor, FS en lecture seule) réduit ce qu'une charge compromise peut faire au niveau du noyau et du système, limitant l'escalade depuis le conteneur.
- Preuve attendue
- Profils seccomp/AppArmor et FS lecture seule appliqués.
- Outillage
- Checkov KICS Conftest
Correspondances & menaces parées 2 standards · 1 menace
Le manifeste de déploiement est mal configuré (privilèges excessifs, montages sensibles, réseau ouvert), exposant la charge dès sa mise en service. La faiblesse n'est pas dans l'artefact mais dans la façon dont il est déployé (CIS Kubernetes) CIS K8s.
Séparer les privilèges de déploiement
Section intitulée « Séparer les privilèges de déploiement »Le pipeline ne doit jamais détenir un accès prod permanent. Le déploiement passe par une identité courte ou une approbation, idéalement en GitOps (déclaratif, tracé, réconcilié), avec un RBAC de cluster au moindre privilège.
déploiement par identité courte / approbation ; aucun credential prod de longue durée dans le pipeline.#
Un credential prod de longue durée dans le pipeline est une cible : fuité, il donne un accès permanent à la production. Le déploiement par identité courte/approbation, sans secret prod durable, supprime cet actif critique : l'accès n'existe que le temps du déploiement, validé, et ne traîne pas dans le CI.
- Preuve attendue
- Déploiement par identité courte/approbation ; pas de credential prod longue durée dans le pipeline.
Correspondances & menaces parées 2 standards · 2 menaces
Le manifeste de déploiement est mal configuré (privilèges excessifs, montages sensibles, réseau ouvert), exposant la charge dès sa mise en service. La faiblesse n'est pas dans l'artefact mais dans la façon dont il est déployé (CIS Kubernetes) CIS K8s. Un jeton d'accès de longue durée est volé et réutilisé tant qu'il n'est pas révoqué, sans nouvelle authentification. La durée de vie sans rotation maximise la valeur du vol CICD-SEC-6.
déploiement déclaratif (GitOps) tracé et réconcilié.#
Un déploiement impératif appliqué à la main est intraçable et dérive. Le déploiement déclaratif (GitOps), tracé et réconcilié, fait de Git la source de vérité : tout changement est revu, historisé et l'état réel est ramené en continu vers l'état désiré, supprimant les modifications sauvages non auditées.
- Preuve attendue
- Déploiement GitOps tracé et réconcilié.
- Outillage
- Argo CD Flux
Correspondances & menaces parées 2 standards · 1 menace
Le manifeste de déploiement est mal configuré (privilèges excessifs, montages sensibles, réseau ouvert), exposant la charge dès sa mise en service. La faiblesse n'est pas dans l'artefact mais dans la façon dont il est déployé (CIS Kubernetes) CIS K8s.
RBAC du cluster / de l'environnement au moindre privilège.#
Un RBAC trop permissif sur le cluster donne à un compte ou une charge bien plus que nécessaire, amplifiant tout compromis. Un RBAC au moindre privilège sur l'environnement limite ce que chaque acteur peut faire : une compromission n'atteint que le périmètre strictement accordé, pas l'ensemble du cluster.
- Preuve attendue
- RBAC cluster/environnement au moindre privilège.
Correspondances & menaces parées 2 standards · 1 menace
Le manifeste de déploiement est mal configuré (privilèges excessifs, montages sensibles, réseau ouvert), exposant la charge dès sa mise en service. La faiblesse n'est pas dans l'artefact mais dans la façon dont il est déployé (CIS Kubernetes) CIS K8s.
Garantir intégrité, dérive et rollback
Section intitulée « Garantir intégrité, dérive et rollback »Enfin, on déploie par digest immuable (jamais un tag mutable), on détecte la dérive entre l'état désiré et l'état réel, et on garde une capacité de rollback et de blocage d'urgence testée.
artefacts déployés par digest immuable (jamais de tag mutable).#
Déployer par tag mutable laisse la référence pointer vers un contenu qui peut changer, piégé, sans qu'on le voie. Déployer par digest immuable (@sha256:) fige exactement l'artefact exécuté : la reproductibilité est garantie et personne ne substitue ce qui tourne en production via une simple réécriture de tag.
- Preuve attendue
- Déploiement par digest immuable.
Correspondances & menaces parées 2 standards · 2 menaces
L'artefact est modifié après sa construction mais avant sa publication ou son déploiement, échappant aux contrôles appliqués au code source. Sans intégrité de bout en bout, l'artefact livré diffère de celui qui a été buildé SLSA (F). Un tag mutable (latest, une version) est réécrit pour pointer vers un artefact malveillant, livré aux consommateurs qui font confiance au tag plutôt qu'au digest. La mutabilité brise l'immuabilité attendue d'une version publiée CNCF Publishing.
détection de dérive (drift) entre l'état désiré et l'état réel.#
Un écart entre l'état désiré et l'état réel (modification manuelle, dérive) crée un angle mort où une altération malveillante peut se cacher. La détection de dérive (drift) signale tout changement non déclaré : on repère une modification hors process, qu'elle soit une erreur ou une intrusion, avant qu'elle ne s'installe.
- Preuve attendue
- Dispositif de détection de dérive (drift).
- Outillage
- Argo CD Flux
Correspondances & menaces parées 2 standards · 2 menaces
L'artefact est modifié après sa construction mais avant sa publication ou son déploiement, échappant aux contrôles appliqués au code source. Sans intégrité de bout en bout, l'artefact livré diffère de celui qui a été buildé SLSA (F). Un artefact non signé, non scanné ou hors politique passe le contrôle d'admission et entre en production. Le dernier filtre avant l'exécution laisse passer ce qu'il devait bloquer CICD-SEC-9.
capacité de rollback et de blocage d'urgence d'un déploiement.#
Quand un déploiement se révèle compromis ou défaillant, l'incapacité à réagir vite prolonge l'incident. Une capacité de rollback et de blocage d'urgence permet de revenir à une version saine ou de stopper net une diffusion dangereuse en minutes, raccourcissant l'exposition au lieu de subir la version fautive le temps d'un correctif.
- Preuve attendue
- Procédure de rollback et de blocage d'urgence testée.
Correspondances & menaces parées 2 standards · 1 menace
Une charge détruit données, dépôts ou systèmes (wiper, suppression) pour saboter ou couvrir ses traces. La résilience (sauvegardes éprouvées, immuabilité) conditionne la capacité de reprise ATT&CK.
Pièges courants
Section intitulée « Pièges courants »- Policy en mode « audit » : un contrôleur qui avertit sans bloquer ne protège pas (DPL-A2-2).
- Vérifier la présence, pas l'origine : une attestation non rattachée au builder/source attendus laisse passer un fork malveillant (DPL-0-4).
- Credentials prod dans le CI : un pipeline avec accès prod permanent est une cible directe (DPL-0-2, DPL-A3-2).
- Déploiement par tag mutable : l'image déployée peut différer de l'image vérifiée (DPL-A4-1).
- Pas de rollback testé : on découvre l'incapacité à revenir en arrière en pleine crise (DPL-A4-3).
À retenir
Section intitulée « À retenir »- L'admission est le dernier rempart : c'est là que la chaîne de preuves est enfin appliquée.
- Les essentielles : n'admettre que signé et conforme, vérifier la provenance contre l'allowlist, séparer les privilèges, durcir la config.
- Le contrôleur (Kyverno, OPA) doit être bloquant, pas en avertissement.
- Déployer au moindre privilège (identité courte, GitOps, RBAC) et par digest immuable.
- Le niveau R3 restreint l'admission aux provenances non falsifiables (L3).