Tekton est un puissant framework open source natif de Kubernetes permettant de cr\u00e9er des syst\u00e8mes d’int\u00e9gration continue et de livraison continue (CI\/CD). Il s’ex\u00e9cute sous forme de Custom Resource Definitions (CRDs) sur n’importe quel cluster Kubernetes, vous permettant de d\u00e9finir des pipelines sous forme de YAML d\u00e9claratif, portables d’un environnement \u00e0 l’autre.<\/p>\n
Tekton Chains<\/strong> est un projet compl\u00e9mentaire qui ajoute automatiquement la s\u00e9curit\u00e9 de la cha\u00eene d’approvisionnement \u00e0 vos pipelines Tekton. Une fois install\u00e9, Chains surveille les TaskRuns termin\u00e9s, signe automatiquement leurs r\u00e9sultats \u00e0 l’aide de Cosign ou d’autres outils de signature, et g\u00e9n\u00e8re des attestations de provenance SLSA<\/a> \u2014 le tout sans n\u00e9cessiter aucune modification de vos d\u00e9finitions de pipeline existantes.<\/p>\n Dans ce lab pratique, vous allez :<\/p>\n \u00c0 la fin de ce lab, vous disposerez d’un pipeline de build s\u00e9curis\u00e9 enti\u00e8rement fonctionnel qui produit des images de conteneurs sign\u00e9es et attest\u00e9es avec une provenance v\u00e9rifiable \u2014 atteignant automatiquement la conformit\u00e9 SLSA Level 2.<\/p>\n Avant de commencer ce lab, assurez-vous que les outils suivants sont install\u00e9s sur votre poste de travail :<\/p>\n Ce lab suppose une familiarit\u00e9 avec les bases de Kubernetes (pods, namespaces, configmaps) et les concepts g\u00e9n\u00e9raux de CI\/CD.<\/p>\n Commencez par cr\u00e9er un cluster Kubernetes neuf avec kind :<\/p>\n Confirmez que le cluster est en cours d’ex\u00e9cution :<\/p>\n Installez la derni\u00e8re version de Tekton Pipelines :<\/p>\n Attendez que les pods Tekton Pipelines soient pr\u00eats :<\/p>\n Vous devriez voir les pods Installez Tekton Chains dans son propre namespace :<\/p>\n V\u00e9rifiez que Chains est en cours d’ex\u00e9cution :<\/p>\n \u00c0 ce stade, Tekton Pipelines et Tekton Chains sont tous deux en cours d’ex\u00e9cution sur votre cluster.<\/p>\n Tekton Chains a besoin d’une cl\u00e9 de signature et d’une configuration pour savoir comment et o\u00f9 stocker les signatures et les attestations. Dans cet exercice, vous allez g\u00e9n\u00e9rer une paire de cl\u00e9s Cosign et configurer Chains pour utiliser le stockage OCI avec le format d’attestation in-toto.<\/p>\n Cosign peut g\u00e9n\u00e9rer une paire de cl\u00e9s et la stocker directement comme un Secret Kubernetes dans le namespace Vous serez invit\u00e9 \u00e0 entrer un mot de passe pour la cl\u00e9 priv\u00e9e. Pour ce lab, vous pouvez appuyer sur Entr\u00e9e pour le laisser vide. Cosign cr\u00e9e un Secret nomm\u00e9 V\u00e9rifiez que le secret a \u00e9t\u00e9 cr\u00e9\u00e9 :<\/p>\n Ensuite, configurez Chains pour stocker les signatures dans le registre OCI aux c\u00f4t\u00e9s de l’image et pour g\u00e9n\u00e9rer la provenance au format in-toto :<\/p>\n Cette configuration indique \u00e0 Chains de :<\/p>\n Apr\u00e8s avoir modifi\u00e9 la configuration, red\u00e9marrez le contr\u00f4leur Chains pour qu’il prenne en compte les nouveaux param\u00e8tres :<\/p>\n Avec Chains configur\u00e9, voici ce qui se passe automatiquement chaque fois qu’un TaskRun se termine :<\/p>\n Rien de tout cela ne n\u00e9cessite de modification de vos Tasks ou Pipelines.<\/p>\n Vous allez maintenant cr\u00e9er un Pipeline Tekton qui clone un d\u00e9p\u00f4t Git et construit une image de conteneur \u00e0 l’aide de Kaniko. Commencez par configurer les identifiants du registre pour que Tekton puisse pousser les images.<\/p>\n Cr\u00e9ez un Secret Kubernetes avec vos identifiants de registre. Remplacez les valeurs de substitution par les d\u00e9tails r\u00e9els de votre registre :<\/p>\n Cr\u00e9ez un fichier nomm\u00e9 Appliquez la Task :<\/p>\n Cr\u00e9ez Cr\u00e9ez Appliquez le Pipeline :<\/p>\n Cr\u00e9ez un PipelineRun pour ex\u00e9cuter le pipeline. Remplacez la r\u00e9f\u00e9rence de l’image par votre registre :<\/p>\n Enregistrez ceci sous Surveillez l’ex\u00e9cution du pipeline :<\/p>\n Le build devrait se terminer avec succ\u00e8s. Vous pouvez \u00e9galement v\u00e9rifier le statut du PipelineRun :<\/p>\n Une fois le PipelineRun termin\u00e9, Tekton Chains d\u00e9tecte automatiquement le TaskRun compl\u00e9t\u00e9, signe l’image construite et annote le TaskRun. Tout cela se passe en arri\u00e8re-plan \u2014 aucune modification du pipeline n’est n\u00e9cessaire.<\/p>\n Chains traite les TaskRuns termin\u00e9s de mani\u00e8re asynchrone. Attendez quelques instants, puis v\u00e9rifiez les annotations du TaskRun :<\/p>\n La sortie devrait \u00eatre :<\/p>\n Si elle est encore vide, attendez quelques secondes et r\u00e9essayez \u2014 Chains a besoin de temps pour traiter la signature.<\/p>\n V\u00e9rifiez maintenant la signature de l’image en utilisant la cl\u00e9 publique de la paire de cl\u00e9s Cosign que vous avez g\u00e9n\u00e9r\u00e9e pr\u00e9c\u00e9demment :<\/p>\n Vous devriez voir une sortie confirmant que la v\u00e9rification a r\u00e9ussi :<\/p>\n Chains annote le TaskRun avec des m\u00e9tadonn\u00e9es riches sur l’op\u00e9ration de signature :<\/p>\n Les annotations cl\u00e9s incluent :<\/p>\n L’annotation Au-del\u00e0 des simples signatures, Tekton Chains g\u00e9n\u00e8re des attestations de provenance SLSA compl\u00e8tes. Ces attestations d\u00e9crivent comment<\/em> l’artefact a \u00e9t\u00e9 construit \u2014 quelle source a \u00e9t\u00e9 utilis\u00e9e, quelles \u00e9tapes de build ont \u00e9t\u00e9 ex\u00e9cut\u00e9es et quels outils ont \u00e9t\u00e9 impliqu\u00e9s.<\/p>\n Utilisez Cosign pour v\u00e9rifier et r\u00e9cup\u00e9rer l’attestation in-toto :<\/p>\n L’attestation de provenance suit le format in-toto Statement avec un pr\u00e9dicat SLSA Provenance. Voici une analyse des champs cl\u00e9s :<\/p>\n Passons en revue chaque champ :<\/p>\n Ces donn\u00e9es de provenance satisfont les exigences du SLSA Level 2<\/strong> : le processus de build est d\u00e9fini dans un service de build (Tekton), et la provenance est g\u00e9n\u00e9r\u00e9e automatiquement par Tekton Chains (et non par le script de build lui-m\u00eame). La provenance est sign\u00e9e, fournissant une preuve de non-alt\u00e9ration.<\/p>\n Un pipeline s\u00e9curis\u00e9 ne devrait pas seulement signer les artefacts, mais aussi v\u00e9rifier qu’ils sont exempts de vuln\u00e9rabilit\u00e9s connues avant le d\u00e9ploiement. Dans cet exercice, vous allez ajouter une \u00e9tape d’analyse de vuln\u00e9rabilit\u00e9s Grype au pipeline.<\/p>\n Appliquez la Task d’analyse de vuln\u00e9rabilit\u00e9s que vous avez cr\u00e9\u00e9e pr\u00e9c\u00e9demment :<\/p>\n Mettez \u00e0 jour Appliquez le pipeline mis \u00e0 jour :<\/p>\n Pour d\u00e9montrer la d\u00e9tection de vuln\u00e9rabilit\u00e9s par l’analyse, cr\u00e9ez un Dockerfile qui utilise une image de base connue comme vuln\u00e9rable et poussez un d\u00e9p\u00f4t ou modifiez les param\u00e8tres en cons\u00e9quence. Si l’image contient des vuln\u00e9rabilit\u00e9s critiques, Grype fera \u00e9chouer l’\u00e9tape :<\/p>\n Le pipeline \u00e9choue correctement \u00e0 l’\u00e9tape d’analyse, emp\u00eachant une image vuln\u00e9rable d’\u00eatre promue.<\/p>\n Ex\u00e9cutez maintenant le pipeline avec un d\u00e9p\u00f4t contenant une image de base \u00e0 jour. Lorsqu’aucune vuln\u00e9rabilit\u00e9 critique n’est trouv\u00e9e, l’analyse r\u00e9ussit :<\/p>\n Le flux du pipeline est d\u00e9sormais : git-clone \u2192 build-push \u2192 vulnerability-scan<\/strong>. Seules les images qui passent l’analyse de vuln\u00e9rabilit\u00e9s sont sign\u00e9es par Tekton Chains, car Chains ne traite que les TaskRuns r\u00e9ussis<\/em>.<\/p>\n La gestion de cl\u00e9s de signature \u00e0 longue dur\u00e9e de vie introduit de la complexit\u00e9 op\u00e9rationnelle et des risques de s\u00e9curit\u00e9. Fulcio<\/strong> de Sigstore fournit une signature sans cl\u00e9 en \u00e9mettant des certificats de courte dur\u00e9e li\u00e9s \u00e0 une identit\u00e9 OIDC. Dans cet exercice, vous allez configurer Tekton Chains pour utiliser la signature sans cl\u00e9.<\/p>\n Modifiez la configuration de Chains pour activer la signature sans cl\u00e9 :<\/p>\n Vous devez \u00e9galement supprimer ou renommer le secret Red\u00e9marrez le contr\u00f4leur Chains :<\/p>\n Chains a besoin d’un jeton OIDC pour s’authentifier aupr\u00e8s de Fulcio. Sur un service Kubernetes g\u00e9r\u00e9 (GKE, EKS, AKS), vous pouvez utiliser l’identit\u00e9 de charge de travail (workload identity). Pour un cluster kind local, vous pouvez configurer Spiffe\/SPIRE ou utiliser un fournisseur OIDC ambiant. La documentation de Tekton Chains fournit des instructions de configuration pour chaque environnement.<\/p>\n Pour une configuration de production GKE, le compte de service est automatiquement f\u00e9d\u00e9r\u00e9 :<\/p>\n D\u00e9clenchez un nouveau PipelineRun :<\/p>\n Apr\u00e8s l’ach\u00e8vement, v\u00e9rifiez avec la v\u00e9rification sans cl\u00e9 en sp\u00e9cifiant l’identit\u00e9 attendue et l’\u00e9metteur OIDC :<\/p>\n La v\u00e9rification repose d\u00e9sormais sur la cha\u00eene de certificats de Fulcio plut\u00f4t que sur une paire de cl\u00e9s statique. Cette approche \u00e9limine enti\u00e8rement la gestion des cl\u00e9s : chaque op\u00e9ration de signature obtient un certificat frais et de courte dur\u00e9e, et l’\u00e9v\u00e9nement de signature est enregistr\u00e9 dans le journal de transparence Rekor pour l’auditabilit\u00e9.<\/p>\n Signer les images n’est utile que si vous appliquez<\/em> la v\u00e9rification des signatures au moment du d\u00e9ploiement. Dans cet exercice, vous allez d\u00e9ployer le policy-controller de Sigstore pour rejeter toute image de conteneur qui ne poss\u00e8de pas de signature Tekton Chains valide.<\/p>\n Attendez que le policy controller soit pr\u00eat :<\/p>\n Cr\u00e9ez une Remplacez la cl\u00e9 publique par la cl\u00e9 publique Cosign que vous avez g\u00e9n\u00e9r\u00e9e pr\u00e9c\u00e9demment :<\/p>\n Appliquez la politique :<\/p>\n Labellisez un namespace pour activer l’application de la politique :<\/p>\n D\u00e9ployez l’image qui a \u00e9t\u00e9 sign\u00e9e par Tekton Chains :<\/p>\n Le d\u00e9ploiement r\u00e9ussit car l’image poss\u00e8de une signature et une attestation de provenance valides.<\/p>\n Essayez maintenant de d\u00e9ployer une image qui n’a pas \u00e9t\u00e9 sign\u00e9e :<\/p>\n Le webhook d’admission rejette correctement l’image non sign\u00e9e. Cela boucle la boucle : les images sont automatiquement sign\u00e9es pendant le build, et seules les images sign\u00e9es peuvent \u00eatre d\u00e9ploy\u00e9es.<\/p>\n Lorsque vous avez termin\u00e9 le lab, nettoyez les ressources :<\/p>\n Continuez \u00e0 renforcer vos connaissances en s\u00e9curit\u00e9 de la cha\u00eene d’approvisionnement avec ces guides connexes :<\/p>\n Pr\u00e9sentation Tekton est un puissant framework open source natif de Kubernetes permettant de cr\u00e9er des syst\u00e8mes d’int\u00e9gration continue et de livraison continue (CI\/CD). Il s’ex\u00e9cute sous forme de Custom Resource Definitions (CRDs) sur n’importe quel cluster Kubernetes, vous permettant de d\u00e9finir des pipelines sous forme de YAML d\u00e9claratif, portables d’un environnement \u00e0 l’autre. Tekton Chains … Lire la suite<\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[49,50],"tags":[],"post_folder":[],"class_list":["post-545","post","type-post","status-publish","format-standard","hentry","category-ci-cd-security","category-software-supply-chain"],"_links":{"self":[{"href":"https:\/\/secure-pipelines.com\/fr\/wp-json\/wp\/v2\/posts\/545","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/secure-pipelines.com\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/secure-pipelines.com\/fr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/secure-pipelines.com\/fr\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/secure-pipelines.com\/fr\/wp-json\/wp\/v2\/comments?post=545"}],"version-history":[{"count":2,"href":"https:\/\/secure-pipelines.com\/fr\/wp-json\/wp\/v2\/posts\/545\/revisions"}],"predecessor-version":[{"id":585,"href":"https:\/\/secure-pipelines.com\/fr\/wp-json\/wp\/v2\/posts\/545\/revisions\/585"}],"wp:attachment":[{"href":"https:\/\/secure-pipelines.com\/fr\/wp-json\/wp\/v2\/media?parent=545"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/secure-pipelines.com\/fr\/wp-json\/wp\/v2\/categories?post=545"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/secure-pipelines.com\/fr\/wp-json\/wp\/v2\/tags?post=545"},{"taxonomy":"post_folder","embeddable":true,"href":"https:\/\/secure-pipelines.com\/fr\/wp-json\/wp\/v2\/post_folder?post=545"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}\n
Pr\u00e9requis<\/h2>\n
\n
Mise en Place de l’Environnement<\/h2>\n
\u00c9tape 1 : Cr\u00e9er un Cluster kind<\/h3>\n
kind create cluster --name tekton-lab\nkubectl cluster-info --context kind-tekton-lab<\/code><\/pre>\nkubectl get nodes\n# NAME STATUS ROLES AGE VERSION\n# tekton-lab-control-plane Ready control-plane 30s v1.31.0<\/code><\/pre>\n\u00c9tape 2 : Installer Tekton Pipelines<\/h3>\n
kubectl apply --filename https:\/\/storage.googleapis.com\/tekton-releases\/pipeline\/latest\/release.yaml<\/code><\/pre>\nkubectl get pods -n tekton-pipelines --watch<\/code><\/pre>\ntekton-pipelines-controller<\/code> et tekton-pipelines-webhook<\/code> en cours d’ex\u00e9cution :<\/p>\nNAME READY STATUS RESTARTS AGE\ntekton-pipelines-controller-7f6b9b5b95-xk2rj 1\/1 Running 0 45s\ntekton-pipelines-webhook-6c4f8b7d4f-m9nlp 1\/1 Running 0 45s<\/code><\/pre>\n\u00c9tape 3 : Installer Tekton Chains<\/h3>\n
kubectl apply --filename https:\/\/storage.googleapis.com\/tekton-releases\/chains\/latest\/release.yaml<\/code><\/pre>\nkubectl get pods -n tekton-chains\n# NAME READY STATUS RESTARTS AGE\n# tekton-chains-controller-5f4b7c8d6f-r7t2x 1\/1 Running 0 30s<\/code><\/pre>\nExercice 1 : Configurer Tekton Chains pour la Signature avec Cosign<\/h2>\n
G\u00e9n\u00e9rer une Paire de Cl\u00e9s Cosign<\/h3>\n
tekton-chains<\/code> :<\/p>\ncosign generate-key-pair k8s:\/\/tekton-chains\/signing-secrets<\/code><\/pre>\nsigning-secrets<\/code> contenant la cl\u00e9 priv\u00e9e, la cl\u00e9 publique et le mot de passe.<\/p>\nkubectl get secret signing-secrets -n tekton-chains\n# NAME TYPE DATA AGE\n# signing-secrets Opaque 3 10s<\/code><\/pre>\nConfigurer le Stockage et le Format de Chains<\/h3>\n
kubectl patch configmap chains-config -n tekton-chains \\\n -p='{\"data\":{\"artifacts.oci.storage\":\"oci\",\"artifacts.taskrun.format\":\"in-toto\",\"artifacts.taskrun.storage\":\"oci\"}}'<\/code><\/pre>\n\n
Red\u00e9marrer le Contr\u00f4leur Chains<\/h3>\n
kubectl rollout restart deployment tekton-chains-controller -n tekton-chains\nkubectl rollout status deployment tekton-chains-controller -n tekton-chains<\/code><\/pre>\nFonctionnement de Chains<\/h3>\n
\n
IMAGE_URL<\/code> et IMAGE_DIGEST<\/code>).<\/li>\nsigning-secrets<\/code>.<\/li>\nchains.tekton.dev\/signed=true<\/code>.<\/li>\n<\/ol>\nExercice 2 : Cr\u00e9er un Pipeline de Build<\/h2>\n
Configurer les Identifiants du Registre<\/h3>\n
export REGISTRY_SERVER=ghcr.io\nexport REGISTRY_USER=your-username\nexport REGISTRY_PASSWORD=your-token\n\nkubectl create secret docker-registry registry-credentials \\\n --docker-server=$REGISTRY_SERVER \\\n --docker-username=$REGISTRY_USER \\\n --docker-password=$REGISTRY_PASSWORD\n\nkubectl patch serviceaccount default -p '{\"secrets\": [{\"name\": \"registry-credentials\"}]}'<\/code><\/pre>\nCr\u00e9er la Task de Build<\/h3>\n
build-task.yaml<\/code>. Cette Task accepte une URL de d\u00e9p\u00f4t Git, un nom d’image cible, et utilise Kaniko pour construire et pousser l’image :<\/p>\napiVersion: tekton.dev\/v1\nkind: Task\nmetadata:\n name: git-clone-and-build\nspec:\n params:\n - name: repo-url\n type: string\n description: The Git repository URL to clone\n - name: image\n type: string\n description: The image reference to build and push (e.g., ghcr.io\/user\/app:tag)\n results:\n - name: IMAGE_URL\n description: The image URL that was built\n - name: IMAGE_DIGEST\n description: The digest of the built image\n workspaces:\n - name: source\n steps:\n - name: clone\n image: alpine\/git:2.43.0\n script: |\n #!\/usr\/bin\/env sh\n set -eu\n git clone $(params.repo-url) $(workspaces.source.path)\/src\n echo \"Repository cloned successfully\"\n - name: build-and-push\n image: gcr.io\/kaniko-project\/executor:latest\n args:\n - --dockerfile=$(workspaces.source.path)\/src\/Dockerfile\n - --context=$(workspaces.source.path)\/src\n - --destination=$(params.image)\n - --digest-file=$(results.IMAGE_DIGEST.path)\n securityContext:\n runAsUser: 0\n - name: write-url\n image: alpine:3.19\n script: |\n #!\/usr\/bin\/env sh\n set -eu\n echo -n \"$(params.image)\" > \"$(results.IMAGE_URL.path)\"\n echo \"Image URL written: $(params.image)\"<\/code><\/pre>\nkubectl apply -f build-task.yaml<\/code><\/pre>\nCr\u00e9er la Task d’Analyse de Vuln\u00e9rabilit\u00e9s (Pour Utilisation Ult\u00e9rieure)<\/h3>\n
vuln-scan-task.yaml<\/code> \u2014 vous l’ajouterez au pipeline dans un exercice ult\u00e9rieur :<\/p>\napiVersion: tekton.dev\/v1\nkind: Task\nmetadata:\n name: vulnerability-scan\nspec:\n params:\n - name: image\n type: string\n description: The image reference to scan\n steps:\n - name: scan\n image: anchore\/grype:latest\n args:\n - $(params.image)\n - --fail-on\n - critical\n - --output\n - table<\/code><\/pre>\nCr\u00e9er le Pipeline<\/h3>\n
build-pipeline.yaml<\/code> qui encha\u00eene les \u00e9tapes de clonage et de build :<\/p>\napiVersion: tekton.dev\/v1\nkind: Pipeline\nmetadata:\n name: secure-build\nspec:\n params:\n - name: repo-url\n type: string\n - name: image\n type: string\n workspaces:\n - name: shared-workspace\n tasks:\n - name: build\n taskRef:\n name: git-clone-and-build\n params:\n - name: repo-url\n value: $(params.repo-url)\n - name: image\n value: $(params.image)\n workspaces:\n - name: source\n workspace: shared-workspace<\/code><\/pre>\nkubectl apply -f build-pipeline.yaml<\/code><\/pre>\nEx\u00e9cuter le Pipeline<\/h3>\n
apiVersion: tekton.dev\/v1\nkind: PipelineRun\nmetadata:\n generateName: secure-build-run-\nspec:\n pipelineRef:\n name: secure-build\n params:\n - name: repo-url\n value: \"https:\/\/github.com\/GoogleContainerTools\/kaniko.git\"\n - name: image\n value: \"ghcr.io\/your-username\/tekton-lab:v1\"\n workspaces:\n - name: shared-workspace\n volumeClaimTemplate:\n spec:\n accessModes:\n - ReadWriteOnce\n resources:\n requests:\n storage: 1Gi<\/code><\/pre>\npipelinerun.yaml<\/code> et cr\u00e9ez-le :<\/p>\nkubectl create -f pipelinerun.yaml<\/code><\/pre>\ntkn pipelinerun logs -f --last\n# [build : clone] Cloning into '\/workspace\/source\/src'...\n# [build : clone] Repository cloned successfully\n# [build : build-and-push] INFO[0001] Resolved base image golang:1.22\n# [build : build-and-push] ...\n# [build : build-and-push] INFO[0045] Pushing image to ghcr.io\/your-username\/tekton-lab:v1\n# [build : write-url] Image URL written: ghcr.io\/your-username\/tekton-lab:v1<\/code><\/pre>\ntkn pipelinerun list\n# NAME STARTED DURATION STATUS\n# secure-build-run-x7k2p 1 minute ago 1m 15s Succeeded<\/code><\/pre>\nExercice 3 : V\u00e9rifier la Signature Automatique<\/h2>\n
Attendre la Signature par Chains<\/h3>\n
# Obtenir le nom du TaskRun \u00e0 partir du PipelineRun\nTASKRUN=$(kubectl get taskrun -l tekton.dev\/pipeline=secure-build -o name --sort-by=.metadata.creationTimestamp | tail -1)\necho $TASKRUN\n\n# V\u00e9rifier si Chains l'a sign\u00e9\nkubectl get $TASKRUN -o jsonpath='{.metadata.annotations.chains\\.tekton\\.dev\\\/signed}'<\/code><\/pre>\ntrue<\/code><\/pre>\nV\u00e9rifier la Signature avec Cosign<\/h3>\n
cosign verify \\\n --key k8s:\/\/tekton-chains\/signing-secrets \\\n ghcr.io\/your-username\/tekton-lab:v1<\/code><\/pre>\nVerification for ghcr.io\/your-username\/tekton-lab:v1 --\nThe following checks were performed on each of these signatures:\n - The cosign claims were validated\n - The signatures were verified against the specified public key\n\n[{\"critical\":{\"identity\":{\"docker-reference\":\"ghcr.io\/your-username\/tekton-lab\"},\"image\":{\"docker-manifest-digest\":\"sha256:abc123...\"},\"type\":\"cosign container image signature\"},\"optional\":{}}]<\/code><\/pre>\nInspecter les Annotations du TaskRun<\/h3>\n
kubectl get $TASKRUN -o jsonpath='{.metadata.annotations}' | jq .<\/code><\/pre>\n{\n \"chains.tekton.dev\/signed\": \"true\",\n \"chains.tekton.dev\/transparency\": \"https:\/\/rekor.sigstore.dev\/api\/v1\/log\/entries?logIndex=...\",\n \"chains.tekton.dev\/signature-taskrun-...\": \"...\"\n}<\/code><\/pre>\nchains.tekton.dev\/signed=true<\/code> confirme que Chains a trait\u00e9 et sign\u00e9 ce TaskRun avec succ\u00e8s. Si un journal de transparence est configur\u00e9, vous verrez \u00e9galement une r\u00e9f\u00e9rence vers une entr\u00e9e du journal Rekor.<\/p>\nExercice 4 : Inspecter la Provenance SLSA<\/h2>\n
R\u00e9cup\u00e9rer l’Attestation de Provenance<\/h3>\n
cosign verify-attestation \\\n --key k8s:\/\/tekton-chains\/signing-secrets \\\n --type slsaprovenance \\\n ghcr.io\/your-username\/tekton-lab:v1 | jq -r '.payload' | base64 -d | jq .<\/code><\/pre>\nComprendre la Structure de la Provenance<\/h3>\n
{\n \"_type\": \"https:\/\/in-toto.io\/Statement\/v0.1\",\n \"predicateType\": \"https:\/\/slsa.dev\/provenance\/v0.2\",\n \"subject\": [\n {\n \"name\": \"ghcr.io\/your-username\/tekton-lab\",\n \"digest\": {\n \"sha256\": \"abc123def456...\"\n }\n }\n ],\n \"predicate\": {\n \"builder\": {\n \"id\": \"https:\/\/tekton.dev\/chains\/v2\"\n },\n \"buildType\": \"tekton.dev\/v1beta1\/TaskRun\",\n \"invocation\": {\n \"configSource\": {},\n \"parameters\": {\n \"repo-url\": \"https:\/\/github.com\/GoogleContainerTools\/kaniko.git\",\n \"image\": \"ghcr.io\/your-username\/tekton-lab:v1\"\n }\n },\n \"buildConfig\": {\n \"steps\": [\n {\n \"entryPoint\": \"...\",\n \"arguments\": null,\n \"environment\": {\n \"container\": \"clone\",\n \"image\": \"alpine\/git:2.43.0@sha256:...\"\n }\n },\n {\n \"entryPoint\": \"...\",\n \"environment\": {\n \"container\": \"build-and-push\",\n \"image\": \"gcr.io\/kaniko-project\/executor:latest@sha256:...\"\n }\n }\n ]\n },\n \"materials\": [\n {\n \"uri\": \"oci:\/\/alpine\/git:2.43.0\",\n \"digest\": { \"sha256\": \"...\" }\n },\n {\n \"uri\": \"oci:\/\/gcr.io\/kaniko-project\/executor:latest\",\n \"digest\": { \"sha256\": \"...\" }\n }\n ]\n }\n}<\/code><\/pre>\n\n
https:\/\/tekton.dev\/chains\/v2<\/code>.<\/li>\nExercice 5 : Ajouter une Task d’Analyse de Vuln\u00e9rabilit\u00e9s<\/h2>\n
Appliquer la Task d’Analyse<\/h3>\n
kubectl apply -f vuln-scan-task.yaml<\/code><\/pre>\nMettre \u00e0 Jour le Pipeline<\/h3>\n
build-pipeline.yaml<\/code> pour inclure l’analyse de vuln\u00e9rabilit\u00e9s apr\u00e8s l’\u00e9tape de build :<\/p>\napiVersion: tekton.dev\/v1\nkind: Pipeline\nmetadata:\n name: secure-build\nspec:\n params:\n - name: repo-url\n type: string\n - name: image\n type: string\n workspaces:\n - name: shared-workspace\n tasks:\n - name: build\n taskRef:\n name: git-clone-and-build\n params:\n - name: repo-url\n value: $(params.repo-url)\n - name: image\n value: $(params.image)\n workspaces:\n - name: source\n workspace: shared-workspace\n - name: vulnerability-scan\n runAfter:\n - build\n taskRef:\n name: vulnerability-scan\n params:\n - name: image\n value: $(params.image)<\/code><\/pre>\nkubectl apply -f build-pipeline.yaml<\/code><\/pre>\nTester avec une Image Vuln\u00e9rable<\/h3>\n
tkn pipelinerun logs -f --last\n# [vulnerability-scan : scan] NAME INSTALLED FIXED-IN TYPE VULNERABILITY SEVERITY\n# [vulnerability-scan : scan] libcrypto3 3.0.12 3.0.13 apk CVE-2024-0727 Critical\n# [vulnerability-scan : scan] 1 critical vulnerability found\n# [vulnerability-scan : scan] ERROR: failed to pass severity threshold\n#\n# TaskRun failed: step \"scan\" exited with code 1<\/code><\/pre>\nTester avec une Image Corrig\u00e9e<\/h3>\n
tkn pipelinerun logs -f --last\n# [vulnerability-scan : scan] No critical vulnerabilities found\n# PipelineRun completed successfully<\/code><\/pre>\nExercice 6 : Signature sans Cl\u00e9 avec Fulcio (Avanc\u00e9)<\/h2>\n
Mettre \u00e0 Jour la Configuration de Chains<\/h3>\n
kubectl patch configmap chains-config -n tekton-chains -p='{\"data\":{\n \"signers.x509.fulcio.enabled\": \"true\",\n \"signers.x509.fulcio.address\": \"https:\/\/fulcio.sigstore.dev\",\n \"transparency.enabled\": \"true\",\n \"transparency.url\": \"https:\/\/rekor.sigstore.dev\"\n}}'<\/code><\/pre>\nsigning-secrets<\/code> existant pour que Chains bascule en mode sans cl\u00e9 :<\/p>\nkubectl delete secret signing-secrets -n tekton-chains<\/code><\/pre>\nkubectl rollout restart deployment tekton-chains-controller -n tekton-chains<\/code><\/pre>\nConfigurer OIDC pour Chains<\/h3>\n
# Exemple : liaison d'identit\u00e9 de charge de travail GKE\ngcloud iam service-accounts add-iam-policy-binding \\\n tekton-chains-sa@your-project.iam.gserviceaccount.com \\\n --role roles\/iam.workloadIdentityUser \\\n --member \"serviceAccount:your-project.svc.id.goog[tekton-chains\/tekton-chains-controller]\"<\/code><\/pre>\nEx\u00e9cuter le Pipeline avec la Signature sans Cl\u00e9<\/h3>\n
kubectl create -f pipelinerun.yaml<\/code><\/pre>\ncosign verify \\\n --certificate-identity \"https:\/\/kubernetes.io\/namespaces\/tekton-chains\/serviceaccounts\/tekton-chains-controller\" \\\n --certificate-oidc-issuer \"https:\/\/your-oidc-issuer\" \\\n ghcr.io\/your-username\/tekton-lab:v2<\/code><\/pre>\nExercice 7 : Appliquer les Images Sign\u00e9es au D\u00e9ploiement<\/h2>\n
Installer le Policy Controller de Sigstore<\/h3>\n
helm repo add sigstore https:\/\/sigstore.github.io\/helm-charts\nhelm repo update\n\nhelm install policy-controller sigstore\/policy-controller \\\n --namespace cosign-system \\\n --create-namespace \\\n --set webhook.configMapName=policy-controller-config<\/code><\/pre>\nkubectl get pods -n cosign-system --watch<\/code><\/pre>\nCr\u00e9er une Politique d’Image<\/h3>\n
ClusterImagePolicy<\/code> qui exige que les images soient sign\u00e9es par votre cl\u00e9 Tekton Chains. Enregistrez ceci sous image-policy.yaml<\/code> :<\/p>\napiVersion: policy.sigstore.dev\/v1beta1\nkind: ClusterImagePolicy\nmetadata:\n name: tekton-chains-signed\nspec:\n images:\n - glob: \"ghcr.io\/your-username\/**\"\n authorities:\n - key:\n data: |\n -----BEGIN PUBLIC KEY-----\n YOUR_COSIGN_PUBLIC_KEY_HERE\n -----END PUBLIC KEY-----\n attestations:\n - name: must-have-slsa-provenance\n predicateType: \"https:\/\/slsa.dev\/provenance\/v0.2\"\n policy:\n type: cue\n data: |\n predicateType: \"https:\/\/slsa.dev\/provenance\/v0.2\"<\/code><\/pre>\n# Extraire la cl\u00e9 publique\nkubectl get secret signing-secrets -n tekton-chains -o jsonpath='{.data.cosign\\.pub}' | base64 -d<\/code><\/pre>\nkubectl apply -f image-policy.yaml<\/code><\/pre>\nAppliquer la Politique sur un Namespace<\/h3>\n
kubectl create namespace secure-apps\nkubectl label namespace secure-apps policy.sigstore.dev\/include=true<\/code><\/pre>\nTest : D\u00e9ployer une Image Sign\u00e9e<\/h3>\n
kubectl run signed-app \\\n --image=ghcr.io\/your-username\/tekton-lab:v1 \\\n --namespace=secure-apps\n# pod\/signed-app created<\/code><\/pre>\nTest : D\u00e9ployer une Image Non Sign\u00e9e<\/h3>\n
kubectl run unsigned-app \\\n --image=ghcr.io\/your-username\/unsigned-image:latest \\\n --namespace=secure-apps\n# Error from server (BadRequest): admission webhook \"policy.sigstore.dev\" denied the request:\n# validation failed: failed policy: tekton-chains-signed:\n# spec.containers[0].image ghcr.io\/your-username\/unsigned-image:latest\n# signature key validation failed for authority<\/code><\/pre>\nNettoyage<\/h2>\n
# Supprimer Tekton Chains\nkubectl delete -f https:\/\/storage.googleapis.com\/tekton-releases\/chains\/latest\/release.yaml\n\n# Supprimer Tekton Pipelines\nkubectl delete -f https:\/\/storage.googleapis.com\/tekton-releases\/pipeline\/latest\/release.yaml\n\n# Supprimer le policy controller\nhelm uninstall policy-controller -n cosign-system\nkubectl delete namespace cosign-system\n\n# Supprimer le cluster kind\nkind delete cluster --name tekton-lab<\/code><\/pre>\nPoints Cl\u00e9s \u00e0 Retenir<\/h2>\n
\n
Prochaines \u00c9tapes<\/h2>\n
\n