Vérifier la provenance de la compilation

Les packages Assured OSS sont conçus conformément au niveau 2 de SLSA. La provenance de la compilation est fournie dans les métadonnées de sécurité. Cette page explique comment valider les métadonnées de provenance du build.

Ce document s'applique au niveau sans frais. Pour en savoir plus sur la provenance des compilations dans le niveau Premium, consultez Accéder aux métadonnées de sécurité et valider les packages.

Avant de commencer

  • Installez cosign pour valider la signature dans la provenance de la compilation.

Configurer l'authentification

Pour en savoir plus sur la configuration de l'authentification, consultez Configurer l'authentification.

Vérifier la provenance de la compilation

La provenance de la compilation est signée à l'aide d'une attestation in-toto qui utilise à son tour le format d'enveloppe DSSE. Cela signifie que la signature générée contient la signature encapsulée et les données brutes.

Utiliser l'outil aoss-verifier

  1. Pour vérifier la provenance de la compilation, installez l'outil aoss-verifier.

  2. Exportez $(go env GOPATH)/bin, puis exécutez la commande aoss-verifier verify-package avec l'option --verify_build_provenance.

    aoss-verifier verify-package \
   --language LANGUAGE \
   --package_id PACKAGE_ID \
   --version VERSION \
   --artifact_path ARTIFACT_PATH \
   --verify_build_provenance \
   [--disable_certificate_verification] \
   [--temp_downloads_path TEMP_DOWNLOADS_DIR_PATH] \
   [--disable_deletes]

    Remplacez les éléments suivants :

    • LANGUAGE : langage du package. La valeur doit être en minuscules.
    • PACKAGE_ID : pour Java, le format est groupId:artifactId. Pour Python, le format est packageName. La valeur doit être en minuscules.
    • VERSION : version du package.
    • ARTIFACT_PATH : chemin d'accès au fichier de données dans votre répertoire local que vous souhaitez valider. Utilisez les extensions de nom de fichier suivantes :
      • Extension de fichier jar pour un package Java
      • Extension de fichier whl pour un package Python

    --disable_certificate_verification est un flag facultatif qui permet d'ignorer la mise en correspondance du certificat d'entité finale avec le certificat racine via la chaîne de certificats, le cas échéant.

    --temp_downloads_path est un flag facultatif permettant de définir le chemin d'accès du dossier dans lequel vous souhaitez télécharger les fichiers. Remplacez TEMP_DOWNLOADS_DIR_PATH. Si ce flag n'est pas défini, les fichiers sont téléchargés dans le dossier tmp_downloads du répertoire actuel.

    --disable_deletes est un flag facultatif qui permet de conserver les fichiers téléchargés. Par défaut, l'outil nettoie tous les fichiers téléchargés.

Pour en savoir plus, consultez le fichier README de l'outil.

Validation manuelle

Pour vérifier la provenance du build, procédez comme suit :

  1. Récupérez la provenance du build.

    Selon la façon dont vous accédez aux métadonnées de sécurité, la provenance de la compilation est accessible différemment.

    Pour en savoir plus, consultez l'extrait d'exemple de métadonnées suivant :

    {
  "creationTime": "2023-03-25T05:32:23Z",
  "buildDetails": [
   {
     "packageFileName": "jackson-databind-2.13.3.jar",
     "envelope": {
     "payload": "eyJfdHlwZSI6Imh0d……………",
     "payloadType": "application/vnd.in-toto+json",
     "signatures": [
        "sig": "eyJwYXlsb2FkVHlwZSI6Im……",
        "keyid": "gcpkms://projects/cloud-aoss/locations/global/keyRings/cloud-aoss-ring/cryptoKeys/tekton-chains"
       }
     ]
   },
  "buildProvenance": "{\"_type\":\"https://in-toto.io/Statement/v0.1…"
.....

    Exemple d'extrait de métadonnées :

    {'BuildOccurrence': name: "projects/cloud-aoss/occurrences/06c514bb-1069-4cde-8d68-b1306f19535a"
resource_uri: "jackson-databind-2.13.3.jar@sha256:4c01a14673bc1cd4a2df337a3b4e695af0a6ed8ac6be19c9e4077377fb8adf92"
note_name: "projects/cloud-aoss/notes/tekton-cloudbuild-intoto"
kind: BUILD
create_time {
  seconds: 1665556616
  nanos: 891004000
}
……
……
}
envelope {
  payload: "{\"_type\":\"https://in-toto.io/Statement/v0.1\", ….."
  payload_type: "application/vnd.in-toto+json"
  signatures {
    sig: "{\"payloadType\":\"application/vnd.in-toto+json\",....."
    keyid: "gcpkms://projects/cloud-aoss/locations/global/keyRings/cloud-aoss-ring/cryptoKeys/tekton-chains"
  }
}
,
…

  2. Récupérez la signature de provenance de la compilation.

    La provenance de la compilation contient une section nommée Envelope (Enveloppe) qui contient les signatures sous la forme EnvelopeSignature. Pour récupérer la signature, procédez comme suit :

    1. Stockez les données sig dans un fichier nommé signature.txt.

    2. Vérifiez si les métadonnées sont téléchargées à l'aide du script de métadonnées.

      Si les métadonnées sont téléchargées à l'aide du script de métadonnées, modifiez la signature et stockez-la dans un autre fichier appelé signature.sig.

      Pour modifier la signature, exécutez la commande suivante :

      cat signature.txt | sed -e 's/\\"/"/g' > signature.sig

      Si les métadonnées ne sont pas téléchargées à l'aide du script de métadonnées, décodez la signature et stockez-la dans un autre fichier nommé signature.sig.

      Pour décoder la signature, utilisez la commande suivante :

      cat signature.txt | tr '\-_' '+/' | base64 -d > signature.sig

  3. Récupérez la clé publique de provenance de la compilation.

    La section EnvelopeSignature de la provenance de la compilation contient la référence à la clé utilisée pour signer la provenance de la compilation. La clé est stockée dans l'un des formats suivants :

    1. gcpkms://projects/cloud-aoss/locations/global/keyRings/cloud-aoss-ring/cryptoKeys/KEY_NAME

    2. gcpkms://projects/cloud-aoss/locations/global/keyRings/cloud-aoss-ring/cryptoKeys/KEY_NAME/cryptoKeyVersions/KEY_VERSION

      Où KEY_NAME et KEY_VERSION correspondent au nom et à la version de la clé Cloud Key Management Service.

    La clé publique est stockée dans un bucket Cloud Storage appartenant à Assured OSS.

    Récupérez la clé publique à l'aide de Google Cloud CLI. Utilisez l'une des commandes suivantes :

    • Si seul KEY_NAME est présent :

      gcloud storage cp gs://cloud-aoss/keys/KEY_NAME-public.pem PATH_TO_LOCAL_STORE

    • Si KEY_NAME et KEY_VERSION sont tous les deux présents :

      gcloud storage cp gs://cloud-aoss/keys/KEY_NAME-KEY_VERSION-public.pem PATH_TO_LOCAL_STORE

    Remplacez les éléments suivants :

    • KEY_NAME par le nom de la clé Cloud Key Management Service.
    • KEY_VERSION avec la version de la clé Cloud Key Management Service.
    • PATH_TO_LOCAL_STORE par le nom du chemin d'accès local pour stocker la clé publique.

  4. Vérifiez la signature de provenance.

    1. Pour vérifier la signature, exécutez la commande suivante :

      cosign verify-blob-attestation --insecure-ignore-tlog --key KEY_REF --signature signature.sig --type slsaprovenance --check-claims=false /dev/null

      Remplacez les éléments suivants :

      • KEY_REF : chemin d'accès à la clé publique que vous avez téléchargée à l'étape précédente.
      • signature.sig : fichier contenant la signature récupérée à l'étape précédente.

      Le résultat suivant est renvoyé une fois la commande exécutée :

      Verified OK

    2. Pour vérifier également le hachage de l'artefact associé à la provenance, utilisez la commande suivante :

      cosign verify-blob-attestation --insecure-ignore-tlog --key KEY_REF --signature signature.sig --type slsaprovenance --check-claims=true ARTIFACT_PATH

      Remplacez les éléments suivants :

      • KEY_REF : chemin d'accès à la clé publique que vous avez téléchargée à l'étape précédente.
      • signature.sig : fichier contenant la signature récupérée à l'étape précédente.
      • ARTIFACT_PATH : chemin d'accès à l'artefact.

      Le résultat suivant est renvoyé une fois la commande exécutée :

      Verified OK

Étapes suivantes