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

Sécurisez votre software supply chain avec SLSA, Sigstore et Kyverno

Sécurisez votre software supply chain avec SLSA, Sigstore et Kyverno

Lien vers la démo : https://github.com/albasystems/hello-slsa

Lien de la conf : https://www.kcdfrance.fr/programme/securisez-votre-software-supply-chain-avec-slsa-sigstore-et-kyverno

Si vous tombez un jour sur une clé USB posée négligemment sur la table d'une salle de réunion, la brancheriez-vous dans votre portable ? "Jamais !" me diriez-vous.

Pourtant, c'est ce que nous faisons presque tout le temps avec les dépendances logicielles que nous récupérons d'Internet.

Ces dépendances ou artefacts sont devenus si complexes que nous ne maîtrisons plus leur contenu ou leurs dépendances transitives. Cette complexité s’étend à nos chaînes de production logicielle qui peuvent être corrompues à des endroits multiples : le référentiel de code source, le système de build ou le registre d'artefacts.Pour sécuriser notre chaîne de build ou "software supply chain", nous devons être capables de vérifier l'authenticité et l'intégrité des dépendances. De même, en tant que producteurs d'artefacts, nous devons garantir un niveau équivalent de sécurité et de transparence à nos consommateurs. Mais comment faire sans alourdir la chaîne CI/CD ni nuire à la productivité du développeur ?

La réponse ? C’est la communauté open source qui l’a apportée avec SLSA et Sigstore, principaux sujets de ce talk.

Pour commencer, nous parlerons de SLSA dont le but est de vous accompagner dans l’amélioration de votre chaîne de build en appliquant de bonnes pratiques de sécurité par paliers successifs.

Nous parlerons également de Sigstore et de la manière avec laquelle il permet d’implémenter SLSA en rendant transparente la signature et l’attestation des artefacts.

Nous clôturerons le talk par une démo sur la protection des déploiements dans Kubernetes à l'aide du moteur de règles "Kyverno".

Mohamed Abdennebi

March 07, 2023
Tweet

More Decks by Mohamed Abdennebi

Other Decks in Programming

Transcript

  1. Sécurisez votre software supply chain
    avec SLSA, Sigstore et Kyverno
    Speaker :
    Mohamed Abdennebi, @abdennebi
    SFEIR
    #KCDFrance 2023

    View Slide

  2. Les attaques sur la supply chain
    #KCDFrance 2023
    Source : https://www.sonatype.com/state-of-the-software-supply-chain/introduction
    Attaques
    Confusion de dépendance
    Typosquatting
    Injection de code
    malicieux

    View Slide

  3. La supply chain logicielle
    Source
    Repo
    Build
    System
    Package
    Repo
    Dépendances
    (C)
    Build à partir
    d'un autre
    source repo
    (B)
    Compromission
    du source repo
    (D)
    Compromission
    du process de
    build
    (F)
    Upload de
    package modifié
    (G)
    Compromission
    du package
    repo
    (A)
    Soumettre des
    changements
    non autorisés
    (H)
    Utilisation d'un
    package vérolé
    (E)
    Utilisation d'une
    dépendance
    vérolée

    View Slide

  4. Best Practices & Frameworks
    #KCDFrance 2023
    ● OWASP : Top 10 CI/CD Security Risks, 2022
    ● CNCF : Software Supply Chain Best Practices, 2021
    ● NIST SSDF : Secure Software Development Framework, 2022
    ● CIS Software Supply Chain Security Guide, 2022
    ● SLSA : (1.0 RC1 février 2023)

    View Slide

  5. SLSA

    View Slide

  6. SLSA
    #KCDFrance 2023
    ● Security Levels for Software Artifacts
    ● Objectif : assurer l'intégrité de la supply chain
    ● Projet de l'Open Source Security Foundation (OpenSSF)
    ● Inspiré par « Binary Authorization for Borg » au sein de Google
    Borg et SLSA : https://cloud.google.com/docs/security/binary-authorization-for-borg

    View Slide

  7. SLSA
    #KCDFrance 2023
    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éé.

    View Slide

  8. Qu'est-ce une attestation ?
    #KCDFrance 2023
    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 contenues dans l'attestation.
    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
    ● Inventer la vôtre :)

    View Slide

  9. Provenance SLSA
    #KCDFrance 2023
    subject:
    - name: ghcr.io/albasystems/hello-slsa
    digest:
    sha256: 278ca5a875482d3321235a0a3d3b9307fa0701c99228accf0168acb6d62cf183
    predicate:
    buildType: https://github.com/slsa-framework/slsa-github-generator/container@v1
    builder:
    id: https://github.com/albasystems/slsa-generator/.github/workflows/slsa3.yml@refs/tags/v1.5.0
    invocation:
    configSource:
    entryPoint: ".github/workflows/build.yml"
    environment:
    github_actor: abdennebi
    github_actor_id: '787057'
    github_event_name: push
    ...
    materials:
    - uri: git+https://github.com/albasystems/hello-slsa@refs/heads/main
    digest:
    sha1: 7a9d468e70d401ceebaf9e2b22496f62c0656c0b

    View Slide

  10. Provenance SLSA
    #KCDFrance 2023
    À quoi servira la provenance ?
    ● Remonter du binaire au code source (lien fort entre les deux)
    ● Garantir l'intégrité du binaire
    ● Rejouer le build pour recréer l'artéfact

    View Slide

  11. Les règles SLSA
    #KCDFrance 2023
    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

    View Slide

  12. Build Track L1 : Provenance
    #KCDFrance 2023
    Description : Provenance publiée
    1. Le mainteneur documente les valeurs que doit avoir la provenance.
    2. Le mainteneur produit à 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.

    View Slide

  13. Build Track L2 : Build Service
    #KCDFrance 2023
    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.
    ⚠ Postulat de base : le système de build est correctement
    sécurisé.
    2. Le consommateur vérifie l'authenticité de la provenance ainsi que
    les informations qu'elle contient.

    View Slide

  14. Build Track L3 : Hardened Builds
    #KCDFrance 2023
    Description : Build renforcé + provenance non-falsifiable
    1. Les jobs contrôlés par l'utilisateur ne peuvent pas accéder à la clé de
    signature pour é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 éphémères

    View Slide

  15. En résumé
    #KCDFrance 2023
    Si vous avez un système de build capable :
    - De lancer des jobs isolés les un des autres
    - D'assurer qu'il sont éphémères
    - Générer et signer des provenance automatiquement sans l'intervention ni
    l'influence des jobs utilisateurs.
    Alors il est éligible au niveau SLSA 3 et vous avez la garantie que ce que vous
    déployez a été protégé contre toute modification.

    View Slide

  16. SLSA Build Track
    Source Build Package
    Dépendances
    (C)
    Build à partir
    d'un autre
    source repo
    (B)
    Compromission
    du source repo
    (D)
    Compromission
    du process de
    build
    (F)
    Upload de
    package modifié
    (G)
    Compromission
    du package
    repo
    (A)
    Soumettre des
    changements
    non autorisés
    (H)
    Utilisation d'un
    package vérolé
    (E)
    Utilisation d'une
    dépendance
    vérolée

    View Slide

  17. Implémentation de SLSA
    #KCDFrance 2023
    Objectif : Construire un container et atteindre le niveau SLSA Build L3
    En utilisant
    1. Github Actions et Github Workflows comme système de build
    2. Sigstore pour la signature des provenances

    View Slide

  18. Sigstore
    Le «Let's Encrypt» de la signature
    de code

    View Slide

  19. Sigstore
    #KCDFrance 2023
    Service d'utilité publique 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 certificats et les signatures

    View Slide

  20. Sigstore
    #KCDFrance 2023
    Principes de la signature keyless :
    ● On s'authentifie auprès de son provider OIDC (OpenId Connect)
    ● 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.

    View Slide

  21. Démo time !
    #KCDFrance 2023
    Démo 1 : Signature keyless avec Sigstore
    Démo 2 : Générer un container estampillé SLSA
    Build L3
    Démo 3 : Déployer le container dans un cluster
    Kubernetes en vérifiant sa provenance par Kyverno

    View Slide

  22. Démo 1
    #KCDFrance 2023
    Signature keyless avec Sigstore
    Repo git :
    https://github.com/albasystems/hello-slsa

    View Slide

  23. Démo 2
    #KCDFrance 2023
    Générer un container SLSA Build L3 (avec provenance signée
    par Sigstore)
    SLSA

    View Slide

  24. Démo 2
    #KCDFrance 2023
    Nous utilisons Github Actions comme système de build.
    Pour générer une provenance non falsifiable, il nous faut :
    1. Isoler la génération de provenance contre toute interférence
    externe (y compris les développeurs)
    2. Le générateur de provenance doit avoir une identité OIDC
    pour pouvoir signer la provenance.

    View Slide

  25. Démo 2
    #KCDFrance 2023
    Les "Reusable Workflows" répondent aux exigences précédentes :
    ● Sont séparés du repo de l'utilisateur
    ● Sont appelés par les workflow de l'utilisateur mais sans aucune
    interférence (Isolation)
    ● Ont leur propre identité OIDC 👉 Ils peuvent signer les
    provenance en utilisant Sigstore
    ● Se lancent dans une nouvelle VM éphémère

    View Slide

  26. Démo 2
    #KCDFrance 2023
    rekor
    container
    registry
    publier
    signature
    publier
    provenance
    signée
    Provenance generator
    workflow
    Build workflow
    Project Repo
    "Hello SLSA"
    Provenance generator
    repo
    Trigger
    Dev
    DevSecOps
    Push
    Alba
    Systems

    View Slide

  27. Autorisation binaire avec
    Kyverno

    View Slide

  28. Kyverno
    #KCDFrance 2023
    ● « Policy Engine » pour Kubernetes
    ● Open Source, fait partie des projets CNCF
    ● Il peut :
    ○ valider
    ○ muter
    ○ générer et nettoyer les ressources Kubernetes
    👉 Nous allons l'utiliser pour valider la provenance des
    pods

    View Slide

  29. Démo 3
    #KCDFrance 2023
    Déployer le container dans un cluster
    Kubernetes et vérifier sa provenance par Kyverno
    SLSA

    View Slide

  30. #KCDFrance 2023
    Merci !

    View Slide