Signature d'images et SBOMs¶

AKKO signe chaque image qu'elle publie sur harbor.akko-ai.com/akko/*:2026.04 avec cosign (projet Sigstore, Apache 2.0, gouvernance Linux Foundation). Chaque image porte également un SBOM CycloneDX 1.5 attaché comme attestation in-toto, généré par syft (Anchore, Apache 2.0).

Cette page explique aux opérateurs comment vérifier que les images en exécution sur leur cluster sont bien celles publiées par AKKO, et comment alimenter les SBOMs vers leur scanner d'entreprise préféré (Anchore Enterprise, Snyk, JFrog Xray, Dependency-Track, etc.).

La justification complète du design vit dans l'ADR-032 (docs/adr/adr-032-image-signing-sbom.md dans le repo source).

Vérifier qu'une image est authentique¶

La clé publique AKKO se trouve dans le repo à helm/akko/charts/akko-cockpit/files/cosign.pub et est également publiée dans Harbor à côté de chaque artéfact. N'importe qui peut vérifier n'importe quelle image sans contacter AKKO.

Vérification rapide (une image)¶

# 1. Récupérer la clé publique (one-shot)
curl -sSfLo cosign.pub \
  https://raw.githubusercontent.com/AKKO-p/akko/main/helm/akko/charts/akko-cockpit/files/cosign.pub

# 2. Vérifier la signature
cosign verify --key cosign.pub harbor.akko-ai.com/akko/cockpit:2026.04

Une exécution réussie affiche un objet JSON par signature correspondante avec le digest de l'image, l'identité signataire et la preuve d'inclusion Rekor. Un échec (pas de signature ou clé incorrecte) renvoie un code de sortie non nul et le message Error: no matching signatures.

Vérifier toutes les images en une fois¶

for img in cockpit ai-service mlflow airflow trino aden akko-rag \
           postgres spark catalog-manager dbt \
           mcp-trino mcp-openmetadata docs notebook-slim notebook-full; do
  echo "=== $img ==="
  cosign verify --key cosign.pub "harbor.akko-ai.com/akko/${img}:2026.04" \
    >/dev/null 2>&1 \
    && echo "OK-signe" \
    || echo "ECHEC-non-signe"
done

Vérifier avant le pull (politique d'admission)¶

Le Sprint 47 livre une ClusterPolicy Kyverno qui refuse de programmer tout pod dont l'image référence harbor.akko-ai.com/akko/ et ne porte pas de signature valide. En attendant, la posture recommandée est d'exécuter cosign verify dans le pipeline de déploiement (06-trivy.yml le fait déjà à chaque push sur main).

Inspecter le SBOM¶

Chaque image signée porte un SBOM CycloneDX 1.5 JSON comme attestation in-toto. Récupérez-le avec :

cosign download attestation harbor.akko-ai.com/akko/cockpit:2026.04 \
  | jq -r .payload \
  | base64 -d \
  | jq '.predicate' > sbom-cockpit.cdx.json

La sortie est un document CycloneDX 1.5 standard. Pour lister rapidement chaque paquet :

jq -r '.components[] | "\(.name)@\(.version) (\(.type))"' sbom-cockpit.cdx.json

Transmettre à un scanner SBOM d'entreprise¶

CycloneDX est le format par défaut de l'industrie depuis 2025. Tous les outils SBOM commerciaux l'ingèrent nativement.

Anchore Enterprise :

anchorectl image add --sbom sbom-cockpit.cdx.json \
  harbor.akko-ai.com/akko/cockpit:2026.04

Snyk :

snyk container monitor harbor.akko-ai.com/akko/cockpit:2026.04 \
  --sbom=sbom-cockpit.cdx.json \
  --org=VOTRE_ORG_ID

OWASP Dependency-Track (open source, recommande) :

curl -X POST \
  -H "X-API-Key: $DT_API_KEY" \
  -H "Content-Type: application/vnd.cyclonedx+json" \
  --data-binary @sbom-cockpit.cdx.json \
  https://votre-dependency-track/api/v1/bom

JFrog Xray :

jf xr c sbom-import \
  --format cyclonedx \
  --file sbom-cockpit.cdx.json \
  --project-key akko

Export en lot : le pipeline Woodpecker 10-image-sign.yml archive chaque SBOM dans akko-sboms-2026.04.tar.gz. Téléchargez-le depuis l'UI Woodpecker dans l'onglet artéfacts du dernier build vert.

FAQ opérateur¶

Puis-je vérifier une image hors-ligne ?¶

Oui. cosign verify --key cosign.pub est entièrement hors-ligne — il ne contacte ni Sigstore, ni Rekor, ni aucun service réseau. La clé publique est le seul artéfact nécessaire. Les clusters air-gapped peuvent également désactiver entièrement le pipeline de signature en posant le secret Woodpecker AKKO_SIGN_IMAGES=false.

Puis-je amener ma propre clé ?¶

Oui. Surchargez la paire de clés cosign en remplaçant helm/akko/charts/akko-cockpit/files/cosign.pub et en stockant votre clé privée comme Secret/akko-cosign-keys dans le namespace harbor :

bash helm/scripts/cosign-init.sh --rotate

Le script génère une nouvelle paire de clés, écrit le Secret, et synchronise cosign.pub dans les fichiers du chart. Relancez le pipeline Woodpecker ensuite pour re-signer chaque image publiée avec la nouvelle clé.

Pourquoi CycloneDX et pas SPDX ?¶

CycloneDX 1.5 est le format que tous les scanners SBOM commerciaux ingèrent nativement en 2025+. SPDX est un excellent second choix (notamment pour les audits de distributions Linux) ; cosign supporte d'attacher les deux côte à côte sur le même digest, et nous pourrons publier une attestation SPDX parallèle dans un sprint ultérieur. Aujourd'hui le predicate cyclonedx est le seul que nous émettons. Voir ADR-032 pour le compromis.

Que se passe-t-il si le pipeline de signature est en panne ?¶

Le pipeline 10-image-sign.yml fonctionne en best-effort : une panne de Sigstore Fulcio ou un hoquet Harbor émet un avertissement et sort en 0 pour ne pas faire échouer le build lui-même. La porte cosign-verify dans 06-trivy.yml est la couche d'application stricte — une signature manquante sur une image poussée vers main bloque le merge. Les opérateurs peuvent aussi relancer manuellement le pipeline de signature depuis l'UI Woodpecker pour réessayer la signature sans reconstruire.

Comment faire tourner la clé de signature ?¶

bash helm/scripts/cosign-init.sh --rotate

Cela génère une nouvelle paire de clés, l'écrit dans Secret/akko-cosign-keys et met à jour la clé publique du chart. Toute signature existante devient invalide — la prochaine exécution du pipeline re-signera chaque image avec la nouvelle identité. Planifiez les rotations en heures creuses : la porte de vérification échouera pendant ~10-15 minutes entre la rotation et la fin du pipeline.

Comment prouver la provenance à un auditeur banque / santé ?¶

Combinez trois artéfacts :

Signature — cosign verify --key cosign.pub <image>. Prouve l'origine.
SBOM — cosign download attestation <image>. Prouve le graphe de dépendances.
Log de pipeline — UI Woodpecker, historique de build de 10-image-sign.yml. Prouve la chaîne de custody.

La combinaison satisfait DORA Article 6 (intégrité de la supply chain ICT), NIS2 Annexe II (SBOM pour entités essentielles) et HDS Section 6.7 (vérification de provenance) lue conjointement avec docs/docs/admin/compliance-matrix.fr.md.

Liens connexes¶

ADR-032 — Signature d'images + SBOM (docs/adr/adr-032-image-signing-sbom.md dans le repo source)
ADR-022 — Stratégie CI (docs/adr/ADR-022-ci-strategy.md dans le repo source)
ADR-029 — Gouvernance avant licence (docs/adr/adr-029-governance-over-license.md dans le repo source)
Matrice de conformité
Playbook d'audit
Audit de licences