Policy Controller Sigstore sur Kubernetes : signer et vérifier les images en cluster — tutoriel 2026

Méta-description : Sigstore Policy Controller permet de garantir qu’aucune image conteneur non signée n’entre dans ton cluster Kubernetes. Tutoriel complet 2026 avec cosign, k3s, Hetzner CX22 et exemples concrets pour PME ouest-africaines.

Pourquoi signer ses images conteneurs en 2026

L’attaque SolarWinds de 2020 et l’incident xz-utils de 2024 ont changé la posture sécurité de toute l’industrie. Aujourd’hui, plus aucune équipe sérieuse ne déploie une image conteneur sans en vérifier l’origine cryptographique. La supply-chain logiciel est devenue le vecteur d’attaque numéro un. Pour une PME basée à Dakar, Abidjan, Bamako, Conakry ou Ouagadougou, héberger un cluster Kubernetes sans politique de signature, c’est ouvrir la porte à n’importe quelle image compromise tirée depuis Docker Hub ou un registre tiers.

Sigstore est un projet de la Linux Foundation, sponsorisé par Google, Red Hat et la communauté CNCF, qui propose une infrastructure publique de signature et vérification cryptographique d’artefacts logiciels — sans gestion manuelle de clés privées grâce au keyless signing. Son composant Kubernetes, Policy Controller, agit comme admission webhook qui inspecte chaque image avant qu’elle soit créée et la rejette si la signature ne correspond pas à la politique définie.

Ce tutoriel suit le format guide général Sécurité supply-chain logiciel : SBOM, signing, scanning (2026). Tu vas y apprendre à installer Policy Controller sur un cluster k3s léger, configurer une politique réaliste, signer une image avec cosign en mode keyless, et vérifier que les images non signées sont bien rejetées.

Prérequis

• Un VPS Hetzner Cloud CX22 (2 vCPU, 4 Go RAM, 40 Go SSD) à 4,15 € HT/mois — soit environ 2 700 F CFA/mois. Tu peux aussi tourner sur une machine locale Ubuntu 22.04+.
• Un cluster k3s ou kind fonctionnel. Si tu n’en as pas, suis d’abord notre guide self-hosting Coolify + Hetzner qui couvre l’installation k3s.
• Outils en ligne de commande : kubectl v1.28+, helm v3.14+, cosign v2.2+.
• Un compte GitHub OU Google (pour l’authentification OIDC keyless).
• Un registre conteneur où pousser tes images : GitHub Container Registry (ghcr.io) gratuit suffit.
• Connexion 3G+ stable. Compte 30 minutes pour la partie pull/push d’images en zone à faible débit.

Architecture cible

Voici comment les pièces s’articulent une fois la solution déployée :

1. Tu construis ton image avec docker build ou buildah (vois notre tutoriel containers sans Docker).
2. Tu pousses l’image vers ghcr.io/ton-org/ton-app:tag.
3. Tu signes l’image avec cosign sign en mode keyless. Sigstore enregistre la signature dans un journal public transparent (Rekor).
4. Sur le cluster, Policy Controller s’exécute en tant qu’admission webhook. Il intercepte chaque Pod avant création.
5. Si l’image n’a pas de signature valide selon la ClusterImagePolicy active, le Pod est rejeté avec un message clair.

Cette architecture protège contre trois scénarios concrets : un développeur qui pousse par erreur une image construite localement non auditée, un attaquant qui aurait obtenu un accès kubectl mais pas la chaîne de signature, et un compromis en amont d’un registre tiers (docker.io/image-malveillante).

Installation pas-à-pas

Étape 1 — Préparer le cluster k3s

Sur ton VPS CX22, installe k3s en mode léger sans Traefik (on n’en a pas besoin pour ce tutoriel) :

curl -sfL https://get.k3s.io | INSTALL_K3S_EXEC="--disable=traefik" sh -
sudo cat /etc/rancher/k3s/k3s.yaml > ~/.kube/config
sed -i "s/127.0.0.1/$(curl -s ifconfig.me)/" ~/.kube/config
kubectl get nodes

Tu dois voir un nœud en état Ready. Sur un CX22 frais, ça prend moins de 2 minutes même en connexion 4G partagée depuis Dakar.

Étape 2 — Installer cosign localement

Sur ta machine de développement (laptop ou même le VPS) :

curl -O -L "https://github.com/sigstore/cosign/releases/download/v2.2.4/cosign-linux-amd64"
sudo mv cosign-linux-amd64 /usr/local/bin/cosign
sudo chmod +x /usr/local/bin/cosign
cosign version

Le binaire pèse environ 80 Mo. En zone 3G, c’est ~5 minutes. Vérifie ensuite avec cosign version — tu dois voir 2.2.4 ou plus récent.

Étape 3 — Installer Policy Controller via Helm

Le déploiement officiel se fait via le chart Helm policy-controller :

helm repo add sigstore https://sigstore.github.io/helm-charts
helm repo update
kubectl create namespace cosign-system
helm install policy-controller sigstore/policy-controller \
  --namespace cosign-system \
  --version 0.10.0 \
  --set webhook.replicas=1 \
  --set webhook.resources.requests.cpu=100m \
  --set webhook.resources.requests.memory=128Mi

Sur un CX22 (2 vCPU, 4 Go RAM), ces réglages garantissent que Policy Controller ne consomme jamais plus de 10 % des ressources du nœud. Pour un cluster de production avec plus de 50 Pods/heure, augmente webhook.replicas à 2 et passe sur un CX32.

Étape 4 — Activer la politique sur un namespace

Policy Controller ne s’active pas globalement. Tu dois explicitement labeller chaque namespace concerné. C’est un choix de design intelligent qui permet une migration progressive :

kubectl create namespace prod
kubectl label namespace prod policy.sigstore.dev/include=true

À partir de ce moment, tout Pod créé dans le namespace prod sera vérifié.

Signer une image avec cosign keyless

Le mode keyless de Sigstore est l’innovation majeure : tu n’as pas de clé privée à gérer, sauvegarder ou faire fuiter. À la place, Sigstore utilise une identité OIDC (Google, GitHub, Microsoft, GitLab) couplée à un certificat éphémère valable 10 minutes, le tout enregistré dans le journal public Rekor.

# Construis et pousse une image de test
echo "FROM alpine:3.19" > Dockerfile
docker build -t ghcr.io/mon-org/hello-its:1.0 .
docker push ghcr.io/mon-org/hello-its:1.0

# Signe en mode keyless
COSIGN_EXPERIMENTAL=1 cosign sign ghcr.io/mon-org/hello-its:1.0

Cosign ouvre une page d’authentification OIDC dans ton navigateur. Tu confirmes avec ton compte GitHub. La signature est ajoutée au registre comme une OCI artifact référence (sufix .sig), et l’entrée correspondante apparaît sur search.sigstore.dev en moins de 30 secondes.

Configurer une ClusterImagePolicy stricte

La pièce maîtresse de Policy Controller est la ressource Kubernetes ClusterImagePolicy. Voici une politique réaliste pour une PME qui n’autorise que les images signées par son équipe (identité GitHub @dev@maboite.sn) ET les images officielles Docker Library (alpine, postgres, nginx) :

apiVersion: policy.sigstore.dev/v1beta1
kind: ClusterImagePolicy
metadata:
  name: prod-images-must-be-signed
spec:
  images:
  - glob: "ghcr.io/mon-org/*"
  authorities:
  - keyless:
      url: https://fulcio.sigstore.dev
      identities:
      - issuer: https://github.com/login/oauth
        subject: dev@maboite.sn

Applique avec kubectl apply -f policy.yaml. Teste maintenant le rejet :

kubectl run -n prod test-bad --image=docker.io/library/nginx:latest
# Error from server (BadRequest): admission webhook denied the request:
# image docker.io/library/nginx:latest does not match any policy

Parfait. Le cluster bloque effectivement toute image non couverte par une politique. À toi d’ajouter une seconde ClusterImagePolicy qui autorise les images Docker Library officielles, en utilisant leur signature de référence Sigstore (déjà publiée par Docker depuis 2023).

Adaptation au contexte ouest-africain

Trois éléments méritent une attention particulière pour un déploiement en Sénégal, Côte d’Ivoire, Burkina Faso, Mali ou Guinée :

• Bande passante limitée — chaque vérification keyless interroge fulcio.sigstore.dev et rekor.sigstore.dev (USA/Europe). Latence typique depuis Dakar : 180 ms ; depuis Bamako : 250 ms. Pour 100 Pods démarrés/heure, ça reste négligeable. Si ton trafic dépasse 1 000 Pods/heure, active le cache Rekor local.
• Coût de l’hébergement — k3s + Policy Controller + cosign tournent confortablement sur un Hetzner CX22 à 2 700 F CFA/mois, paiement Wave ou Orange Money via reseller local possible.
• Conformité légale — la loi 2008-08 sénégalaise et la loi 2013-451 ivoirienne sur la cybercriminalité imposent un devoir de diligence en matière de sécurité logicielle. Documenter une politique de signature d’images aide à prouver cette diligence en cas d’incident.

Erreurs fréquentes à éviter

• Activer la politique en production sans phase de test — labelle d’abord un namespace staging avec mode warn pendant 7 jours pour identifier les images orphelines.
• Oublier les images d’infrastructure — k3s déploie nativement coredns, metrics-server, etc. Inclus-les dans une ClusterImagePolicy dédiée ou via un namespace exclu.
• Confondre signature et SBOM — la signature prouve l’origine, le SBOM décrit le contenu. Tu as besoin des deux. Utilise cosign attest pour attacher un SBOM SPDX à l’image signée.
• Accepter la signature mais pas la chaîne de confiance — vérifie toujours l’identité OIDC (subject + issuer). Une signature valide d’un attaquant n’apporte rien.

FAQ

Sigstore est-il vraiment gratuit ?

Oui. Le service public (Fulcio CA et Rekor log) est financé par la Linux Foundation. Aucun paiement n’est jamais demandé. Pour des besoins offline ou souverains, tu peux héberger ta propre instance Sigstore.

Que se passe-t-il si Sigstore est indisponible ?

Policy Controller refuse alors l’admission par défaut (fail-closed). Tu peux changer ce comportement en fail-open via l’annotation policy.sigstore.dev/mode: warn, mais ce n’est pas recommandé en production.

Est-ce compatible avec ArgoCD et Flux ?

Totalement. Policy Controller agit au niveau de l’API Kubernetes, donc tout outil GitOps qui crée des Pods est intercepté de la même façon.

Peut-on l’utiliser avec un cluster managé OVHcloud ou Scaleway ?

Oui. L’admission webhook est standard. Vérifie juste que le plan managé autorise l’installation de webhooks (la plupart le permettent).

Pour aller plus loin

• 📖 Retour au guide général Sécurité supply-chain logiciel : SBOM, signing, scanning (2026)
• 🛡️ Article complémentaire : Intégration Falco + OpenTelemetry pour la corrélation runtime security et observabilité
• 🐳 Containers sans Docker : Podman, Buildah, distroless (2026) pour construire des images minimales avant signature
• 🌍 Documentation officielle Sigstore

Besoin d’aide pour sécuriser ta supply-chain Kubernetes ?

Tu opères un cluster k3s ou managé en Afrique de l’Ouest et tu veux mettre en place une vraie politique de signature d’images ? ITSkillsCenter propose un audit gratuit de 30 minutes pour identifier les risques supply-chain de ton infra. Contacte-nous via WhatsApp +221 78 226 83 77 ou demande directement ton audit gratuit en ligne.

Approfondissement : journal Rekor et auditabilité

Le journal de transparence Rekor est l’un des piliers techniques de Sigstore. Chaque signature produite avec cosign sign y dépose une entrée immuable, horodatée par autorité publique, qui peut être interrogée par n’importe qui. Pour une PME ouest-africaine soumise à un audit de conformité ISO 27001 ou SOC 2, c’est un atout considérable : on peut prouver qu’une image déployée à un instant T avait bien été signée par tel développeur identifié OIDC à telle date, sans dépendre d’un fournisseur de logging centralisé.

Pour interroger Rekor en ligne de commande :

rekor-cli search --email dev@maboite.sn
rekor-cli get --uuid <uuid-de-l-entree>

Tu peux aussi vérifier qu’aucune signature n’a été produite à ton insu en surveillant régulièrement Rekor pour ton domaine email et en alertant via une simple tâche cron qui interroge l’API JSON. C’est un mécanisme léger, gratuit, et qui s’intègre parfaitement avec un dashboard Grafana auto-hébergé sur le même CX22.

Cas d’usage concrets pour une PME francophone

Voici trois scénarios réels rencontrés dans des missions de conseil ITSkillsCenter en 2025-2026 :

1. Une fintech basée à Abidjan qui opère une plateforme de paiement mobile money. L’équipe a 4 développeurs et un cluster k3s sur un Hetzner CX32. Avant Policy Controller, n’importe quel push vers ghcr.io entraînait un déploiement automatique via ArgoCD. Après mise en place, seules les images signées par les 4 développeurs identifiés (OIDC GitHub Enterprise) sont déployées. Une tentative d’injection via un compte stagiaire compromis a été détectée et bloquée en septembre 2025.
2. Un éditeur SaaS de gestion scolaire à Dakar qui distribue son application à 80 écoles. Chaque release passe désormais par un pipeline GitHub Actions qui construit, signe et publie l’image. Le cluster Kubernetes de chaque école n’accepte que les images signées par l’identité OIDC release@editeur.sn. Un fork malveillant ne pourrait jamais se déployer chez un client.
3. Une coopérative agricole au Burkina Faso qui héberge un Odoo + un site WooCommerce. Bien qu’elle n’ait pas d’équipe DevOps, elle utilise Policy Controller en mode warn et reçoit des alertes Slack/Mattermost lorsqu’une image inhabituelle est détectée. Approche pragmatique pour structure de 3 personnes IT.

Sigstore vs alternatives propriétaires

Plusieurs solutions concurrentes existent : Notary v2 (CNCF), Docker Content Trust, Aqua Security KubeArmor, Snyk Container. Notre recommandation pour une PME francophone d’Afrique de l’Ouest reste Sigstore pour cinq raisons concrètes : licence open-source Apache 2.0 sans verrouillage commercial, mode keyless qui élimine la gestion de clés (un casse-tête majeur pour les petites équipes), intégration native avec GitHub Actions et GitLab CI sans configuration supplémentaire, communauté active de plus de 2 500 contributeurs, et aucune limite ni quota côté service public. Les solutions commerciales restent pertinentes uniquement si tu as déjà investi dans leur écosystème (Aqua, Prisma Cloud) ou si tu opères un volume hors normes (10 000+ images/jour).

Checklist post-déploiement

• ✅ Policy Controller installé en namespace cosign-system avec ressources limitées
• ✅ Au moins un namespace test labellé policy.sigstore.dev/include=true
• ✅ Une ClusterImagePolicy active avec scope glob précis
• ✅ Cosign installé sur les machines des développeurs et dans le pipeline CI
• ✅ Test de rejet réussi (image non signée → erreur claire)
• ✅ Documentation interne mise à jour avec procédure de signature
• ✅ Surveillance Rekor activée pour les identités email autorisées
• ✅ Plan de rotation OIDC documenté (départ d’un développeur, etc.)

Compte 3 à 5 heures de travail effectif pour passer de zéro à une politique de signature opérationnelle, plus 1 à 2 semaines de mode warn avant bascule en enforce. Cet investissement est largement rentabilisé dès le premier blocage automatique d’une image suspecte.

[ITS] ITSkillsCenter — formations IT et conseil pour PME d’Afrique de l’Ouest. Dakar · Abidjan · Ouagadougou · Bamako · Conakry. Tous nos contenus sont audités selon notre charte éditoriale Ahl-Sunna.