Devoxx France 2023 Sécurisez votre software supply chain avec SLSA, Sigstore et Kyverno Mohamed Abdennebi @abdennebi SFEIR

Devoxx France 2023 Êtes-vous sûr que le code déployé en prod correspond bien à celui que vous supposez ? 🤔

SLSA

SLSA ● Cadre de sécurité pour la supply chain ● Ensemble de règles : ○ Producteurs : Fournir un logiciel intègre ○ Consommateurs : Vérifier l'intégrité et l'orgine du logiciel avant de l'utiliser ● Projet de l'Open Source Security Foundation (OpenSSF) ● Projet neutre et communautaire : ○ Google, Intel, vmWare, RedHat, Chainguard, Kusari ○ Github, Gitlab, TektonCD, FluxCD, Docker, etc. ○ Fondation Eclipse Devoxx France 2023 Security Levels for Software Artifacts

SLSA Les deux piliers de SLSA : Un ensemble de règles de sécurité, adoptables de manière progressive. Une provenance est une attestation qui décrit le build : où, comment et par qui un artéfact a été créé. Devoxx France 2023

La provenance SLSA

Qu'est-ce qu'une attestation ? C'est un ensemble d'informations sur un artéfact. 👉 Permet au consommateur de décider d'utiliser ou non un artéfact en fonction des informations qui y sont contenues. Une attestation peut fournir : ● Détails sur le build : Provenance SLSA ● Liste des dépendances : SBOM (Software Bill of Materials) ● Liste des vulnérabilités de l'OS ou des dépendances ● Etc... Devoxx France 2023

Provenance SLSA Devoxx France 2023 subject: - name: ghcr.io/albasystems/hello-slsa digest: sha256: 278ca5a875482d3321235a0a3d3b9307fa0701c99228accf0168acb6d62cf183 Artéfact predicate: builder: id: https://github.com/albasystems/slsa-generator/.github/workflows/slsa3.yml@refs/tags/v1.5.0 buildType: https://github.com/slsa-framework/slsa-github-generator/container@v1 Builder invocation: configSource: entryPoint: ".github/workflows/build.yml" Entrypoint environment: github_actor: abdennebi github_actor_id: '787057' github_event_name: push ... Variables d'environnement materials: - uri: git+https://github.com/albasystems/hello-slsa@refs/heads/main digest: sha1: 7a9d468e70d401ceebaf9e2b22496f62c0656c0b Source + dépendances

Provenance SLSA Pourquoi utiliser la provenance ? 1. Garantir l'intégrité de l'artefact 2. Tracer et garantir l'origine de l'artefact : depuis le binaire on peut remonter aux origines du code source 3. Recréer l'artéfact (exigence de sécurité très élevée) en rejouant le build. Devoxx France 2023

Les règles SLSA

Les règles SLSA Les règles sont structuré autour de « tracks » qui sont des aspects particuliers à sécuriser et qui peuvent être traités en parallèle : ● Version actuelle : build ● Versions futures : source, dépendances et autres 👉 Le build track est réparti sur 3 niveaux à appliquer de manière progressive Devoxx France 2023

Build Track L1 : Provenance Description : Provenance publiée 1. Le producteur documente les valeurs que doit avoir la provenance. 2. Le producteur crée à chaque build une attestation de provenance. 3. Les consommateurs vérifient que le package est conforme au contenu de la provenance et aux valeurs documentées par le mainteneur. La provenance n'est pas nécessairement exhaustive. Devoxx France 2023

Build Track L2 : Build Service Description : Service de build existe + provenance signée 1. Le build est hébergé sur un service de build qui génère et signe automatiquement la provenance. 2. Le consommateur vérifie l'authenticité de la provenance ainsi que les informations qu'elle contient. Devoxx France 2023 💡 à partir de SLSA 2 on commence à avoir un niveau de confiance satisfaisant

Build Track L3 : Hardened Builds Description : provenance non-forgeable + build renforcé 1. Provenance non forgeable : Les jobs contrôlés par l'utilisateur ne peuvent pas accéder à la clé de signature afin d'éviter de forger des provenances 2. Isolation des jobs : les jobs de build ne peuvent pas s'influencer les uns les autres, même au sein d'un même projet. 3. VMs, containers de build sont éphémères Devoxx France 2023 💡 Niveau idéal à atteindre

Implémentation 🚀

User Story En tant que : Développeur Je veux : Être conforme à SLSA 3 Afin de pouvoir : Déployer une application en production en étant sûr de son intégrité et de son origine. Devoxx France 2023

Réalisation Étape 1 : Signature keyless avec Sigstore Étape 2 : Créer un container SLSA 3 à l'aide de Github Actions Étape 3 : Déployer le container et vérifier sa provenance à l'aide de Kyverno. Devoxx France 2023

Signature keyless avec Sigstore Étape 1

Sigstore Service internet pour la signature d'artéfacts logiciels. Inspiré de Let's Encrypt. Sous l'égide de l'OpenSSF. C'est une PKI pour livraison de certificat de signature de code ● Cosign : CLI de signature pour les containers et blobs ● Fulcio : CA qui délivre des certificats de signature X.509 ● Rekor : Transparency Log pour stocker certificats et signatures Devoxx France 2023

Sigstore Principes de la signature keyless : 1. On s'authentifie auprès de son provider OIDC (OpenId Connect) 2. On échange son "Identity Token" contre un certificat d'une durée de vie de 10 min 👉 Pas de gestion de clé privée, elle est jetée dès que l'artéfact est signé. 👉 Pas de complexité liée à la révocation car le certificat a une durée de vie très courte. Devoxx France 2023

Démo : étape 1 Signature keyless avec Sigstore 🪄 Repo git : https://github.com/albasystems/hello-slsa Devoxx France 2023

Construire un container SLSA 3 avec Github Actions Étape 2

Github Actions et SLSA 3 Rappel des règles pour atteindre SLSA 3 : 1. Générer et signer des provenance automatiquement sans l'intervention ni l'influence des jobs utilisateurs. 2. Lancer des jobs isolés les un des autres 3. S'assurer que les runners sont éphémères Devoxx France 2023

Github Actions et SLSA 3 La plateform Github Actions répond aux exigences ● Les jobs tournent dans leurs propres containers qui sont détruits aussitôt le job terminé 👉Isolation et éphémérité. ● Les jobs peuvent demander une identité OIDC à Github (utile pour la signature) Devoxx France 2023

Github Actions et SLSA 3 Quid de la génération de la provenance et de la signature non-forgeable ? 🤔 Les reusables workflows à la rescousse : ● Workflows se trouvant dans leur propre repo Git et appelables depuis les autres repos. ○ Utile pour éviter la répétition. ○ On appellera ça le trusted builder. ● Le trusted builder aura sa propre identité OIDC et signera la provenance que le consommateur pourra vérifier. Devoxx France 2023

trigger instantiate workflow git push DevSecOps Provenance generator repo trusted builder generate provenance Dev "Hello SLSA" repo build uses Runner 1 Job : Build Step 1 : checkout Step 2 : docker build Step 3 : docker push oidc subject : hello-slsa publier container Container Registry publier provenance signée Runner 2 Job : Provenance /generator Step 1 : detect-env Step 2 : generator Step 3 : upload-assets oidc subject : provenance-generator trusted builder Démo : étape 2 Devoxx France 2023 Alba Systems

Démo : étape 2 Générer un container SLSA Build L3 🪄 Devoxx France 2023

Validation au déploiement avec Kyverno Étape 3

Kyverno ● « Policy Engine » pour Kubernetes ● Open Source, projet CNCF ● Il peut : ○ valider ○ modifier ○ générer et nettoyer les ressources Kubernetes 👉 Nous allons l'utiliser pour valider la provenance des pods Devoxx France 2023

No content

Démo : étape 3 Déployer le container dans un cluster Kubernetes et vérifier sa provenance Devoxx France 2023

Devoxx France 2023 Êtes-vous sûr que le code déployé en prod correspond bien à celui que vous supposez ? 😉 Et maintenant ?

Questions / Réponses