Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Comment sécuriser votre software supply chain avec SLSA, Sigstore et Kyverno

Comment sécuriser votre software supply chain avec SLSA, Sigstore et Kyverno

Êtes-vous sûr que le code déployé en production est bien celui que vous pensez être ? Provient-il de votre CI/CD, d'un laptop d'un développeur ou pire, n'aurait-il pas été injecté par un attaquant ? Comment assurez-vous l'intégrité et la traçabilité de vos artefacts ?

Nous allons voir dans ce talk comment répondre à ces questions en utilisant SLSA.

Introduit et open sourcé par Google, SLSA est un cadre de sécurité qui renforce l'intégrité de votre chaîne de production logicielle ou Software Supply Chain. Son principe : améliorer par paliers successifs la protection du code source, sa construction et la distribution des artefacts.

Nous parlerons également de Sigstore, le Let's Encrypt de la signature du code, il nous permettra d’implémenter SLSA en rendant transparente la signature et l’attestation des artefacts.

Et pour faire la part belle à la pratique, nous verrons ensemble comment vérifier l'authenticité d'un container lors du déploiement dans Kubernetes grâce au moteur de règle Kyverno.

Mohamed Abdennebi

April 14, 2023
Tweet

More Decks by Mohamed Abdennebi

Other Decks in Programming

Transcript

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

    View Slide

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

    View Slide

  3. SLSA

    View Slide

  4. 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

    View Slide

  5. 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

    View Slide

  6. La provenance SLSA

    View Slide

  7. 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

    View Slide

  8. 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

    View Slide

  9. 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

    View Slide

  10. Les règles SLSA

    View Slide

  11. 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

    View Slide

  12. 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

    View Slide

  13. 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

    View Slide

  14. 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

    View Slide

  15. Implémentation 🚀

    View Slide

  16. 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

    View Slide

  17. 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

    View Slide

  18. Signature keyless avec
    Sigstore
    Étape 1

    View Slide

  19. 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

    View Slide

  20. 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

    View Slide

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

    View Slide

  22. Construire un container
    SLSA 3 avec
    Github Actions
    Étape 2

    View Slide

  23. 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

    View Slide

  24. 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

    View Slide

  25. 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

    View Slide

  26. 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

    View Slide

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

    View Slide

  28. Validation au déploiement
    avec
    Kyverno
    Étape 3

    View Slide

  29. 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

    View Slide

  30. View Slide

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

    View Slide

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

    View Slide

  33. Questions / Réponses

    View Slide