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
  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
  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
  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)
  5. 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
  6. 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éé.
  7. 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 :)
  8. 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
  9. 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
  10. 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
  11. 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.
  12. 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.
  13. 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
  14. 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.
  15. 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
  16. 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
  17. 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
  18. 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.
  19. 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
  20. Démo 1 #KCDFrance 2023 Signature keyless avec Sigstore Repo git

    : https://github.com/albasystems/hello-slsa
  21. Démo 2 #KCDFrance 2023 Générer un container SLSA Build L3

    (avec provenance signée par Sigstore) SLSA
  22. 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.
  23. 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
  24. 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
  25. 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
  26. Démo 3 #KCDFrance 2023 Déployer le container dans un cluster

    Kubernetes et vérifier sa provenance par Kyverno SLSA