Intégrer l'analyse des failles avec Kritis Signer

Ce guide explique comment utiliser Kritis Signer afin de créer des attestations pour l'autorisation binaire basées sur l'analyse des failles de Container Analysis.

Présentation de Kritis Signer

Les failles logicielles sont des vulnérabilités pouvant entraîner une défaillance accidentelle du système ou être exploitées intentionnellement. Empêcher le déploiement d'images vulnérables constitue un aspect important de la sécurité de la chaîne d'approvisionnement.

Kritis Signer est un outil de ligne de commande Open Source qui peut créer des attestations pour l'autorisation binaire basées sur des services de pipelines CI/CD, tels que l'analyse des failles. Vous pouvez utiliser Kritis Signer en tant que compilateur personnalisé Cloud Build pour récupérer les résultats de l'analyse des failles de Container Analysis et les comparer à des règles sur les failles que vous configurez.

Si toutes les failles identifiées dans les résultats de l'analyse respectent les règles de signature des failles, Kritis Signer crée une attestation d'autorisation binaire pour l'image associée.

Si l'une des failles identifiées dans les résultats de l'analyse enfreint les règles sur les failles, Kritis Signer ne crée pas d'attestation.

Sans attestation validée, l'outil d'application de l'autorisation binaire refuse le déploiement de l'image.

Objectifs

Dans ce guide, vous allez effectuer les opérations suivantes :

  1. configurer Kritis Signer en tant que compilateur personnalisé Cloud Build ;
  2. afficher les règles de signature des failles ;
  3. exécuter le compilateur personnalisé Kritis Signer pour créer des attestations basées sur les résultats de l'analyse des failles.

Coûts

Ce guide utilise les produits Google Cloud suivants. Des frais peuvent s'appliquer.

  • Container Registry
  • Container Analysis
  • Cloud Build
  • Cloud Key Management Service

Utilisez le simulateur de coût pour générer une estimation des coûts en fonction de votre utilisation prévue.

Avant de commencer

Dans cette section, vous allez effectuer une configuration unique du système.

Configurer votre environnement

  1. Stockez votre projet Google Cloud dans une variable d'environnement.

export PROJECT_ID=project-id

project-id est l'ID du projet Google Cloud.

  1. Stockez le numéro de projet dans une variable d'environnement pour les étapes suivantes :

    export PROJECT_NUMBER=$(gcloud projects list --filter="${PROJECT_ID}" \
     --format="value(PROJECT_NUMBER)")
    
  2. Activez les API :

    Pour vous assurer que les services requis pour ce guide sont activés, exécutez la commande suivante :

    gcloud --project=$PROJECT_ID services enable \
      cloudbuild.googleapis.com \
      containerregistry.googleapis.com \
      containeranalysis.googleapis.com \
      containerscanning.googleapis.com \
      cloudkms.googleapis.com
    

Configurer les rôles IAM

Exécutez les commandes suivantes pour configurer les rôles suivants sur le compte de service Cloud Build :

  • containeranalysis.notes.editor : ajoute le rôle Éditeur de notes Container Analysis pour gérer le certificateur.
  • containeranalysis.notes.occurrences.viewer : ajoute le rôle Lecteur d'occurrences Container Analysis pour les notes afin de gérer à la fois les occurrences de failles et d'attestation.
  • roles/containeranalysis.occurrences.editor : ajoute le rôle Éditeur d'occurrences Container Analysis pour créer des occurrences d'attestation dans Container Analysis.
  • cloudkms.signer : ajoute le rôle Signataire de CryptoKeys Cloud KMS qui permet au compte de service d'accéder au service de signature Cloud KMS.

    gcloud projects add-iam-policy-binding $PROJECT_ID --member serviceAccount:$PROJECT_NUMBER@cloudbuild.gserviceaccount.com --role roles/containeranalysis.notes.editor
    gcloud projects add-iam-policy-binding $PROJECT_ID --member serviceAccount:$PROJECT_NUMBER@cloudbuild.gserviceaccount.com --role roles/containeranalysis.notes.occurrences.viewer
    gcloud projects add-iam-policy-binding $PROJECT_ID --member serviceAccount:$PROJECT_NUMBER@cloudbuild.gserviceaccount.com --role roles/containeranalysis.occurrences.editor
    gcloud projects add-iam-policy-binding $PROJECT_ID --member serviceAccount:$PROJECT_NUMBER@cloudbuild.gserviceaccount.com --role roles/cloudkms.signer
    

Configurer le compilateur personnalisé Kritis Signer

Dans cette section, vous allez effectuer une configuration unique du compilateur personnalisé Kritis Signer. Une fois que vous avez obtenu, compilé et transféré Kritis Signer, vous pouvez ensuite l'utiliser dans n'importe quel pipeline Cloud Build.

Cette section explique comment effectuer les opérations suivantes :

  • cloner le dépôt Kritis ;
  • créer le compilateur personnalisé Cloud Build Kritis Signer ;
  • transférer Kritis Signer vers Container Registry pour le rendre disponible en tant qu'étape de compilation Cloud Build.

Exécutez les commandes suivantes pour obtenir le code et les fichiers de configuration utilisés dans ce guide :

  1. Clonez le dépôt Kritis :

     git clone --branch signer-v1.0.0 https://github.com/grafeas/kritis.git
    

    Ce dépôt contient les éléments suivants :

    • Le code source de Kritis, incluant également Kritis Signer
    • Un fichier de configuration Cloud Build utilisé par Cloud Build pour créer le compilateur personnalisé Kritis Signer
    • Un exemple de règles de signature des failles
    • Des exemples de fichiers de configuration Cloud Build. Chaque fichier de configuration illustre un pipeline d'analyse des failles basé sur Kritis Signer.
  2. Accédez au répertoire kritis/ :

    cd kritis
    
  3. Créez et enregistrez le compilateur personnalisé Kritis Signer.

    Cette étape de configuration unique crée le compilateur personnalisé Kritis Signer et l'enregistre auprès de Cloud Build. Une fois enregistré, le compilateur personnalisé peut être utilisé dans n'importe quel pipeline Cloud Build.

    gcloud --project=$PROJECT_ID builds submit . --config deploy/kritis-signer/cloudbuild.yaml
    

Afficher les règles de signature des failles existantes

Cette section présente un exemple de règles de signature des failles Kritis Signer.

Kritis Signer vérifie les failles identifiées par Container Analysis en fonction de ces règles.

Vous pouvez modifier ces règles pour intégrer une liste d'autorisation pour :

  • Des scores de gravité qualifiés associés à des failles identifiées, comme décrit dans la spécification CVSS
  • Des failles spécifiques (CVE)

Pour afficher les règles de signature des failles :

cat samples/signer/policy.yaml

Le résultat doit se présenter comme ceci :

apiVersion: kritis.grafeas.io/v1beta1
kind: VulnzSigningPolicy
metadata:
  name: my-vsp
spec:
  imageVulnerabilityRequirements:
    maximumFixableSeverity: MEDIUM
    maximumUnfixableSeverity: MEDIUM
    allowlistCVEs:
    - projects/goog-vulnz/notes/CVE-2020-10543
    - projects/goog-vulnz/notes/CVE-2020-10878
    - projects/goog-vulnz/notes/CVE-2020-14155

Où :

  • maximumUnfixableSeverity et maximumFixableSeverity peuvent prendre les valeurs suivantes :

    • CRITICAL : score de valeur Critical, conformément à la spécification CVSS.
    • HIGH : score de valeur High, conformément à la spécification CVSS.
    • MEDIUM : score de valeur Medium, conformément à la spécification CVSS.
    • LOW : score de valeur Low, conformément à la spécification CVSS.
    • BLOCK_ALL : l'attestation n'est pas créée si une faille est détectée.
    • ALLOW_ALL : l'attestation est créée même si des failles sont identifiées.
  • allowlistCVEs est une liste de failles. Chaque entrée doit correspondre exactement au nom de la note.

Créer une clé de signature Cloud KMS

Les clés Cloud Key Management Service sont utilisées pour créer le certificateur et l'attestation.

  1. Créez un trousseau de clés Cloud KMS nommé my-key-ring-1 :

    gcloud --project=$PROJECT_ID kms keyrings create my-key-ring-1 \
       --location global
    
  2. Dans ce trousseau, créez une clé Cloud KMS appelée my-signing-key-1 :

    gcloud --project=$PROJECT_ID kms keys create my-signing-key-1 \
        --keyring my-key-ring-1 \
        --location global \
        --purpose "asymmetric-signing" \
        --default-algorithm "rsa-sign-pkcs1-2048-sha256"
    
  3. Stockez l'algorithme de condensé et la clé Cloud KMS dans une variable d'environnement pour les prochaines étapes :

    export KMS_DIGEST_ALG=SHA256
    export KMS_KEY_NAME=projects/$PROJECT_ID/locations/global/keyRings/my-key-ring-1/cryptoKeys/my-signing-key-1/cryptoKeyVersions/1
    

Définir un nom de note

Toutes les attestations font référence à une note Container Analysis. Kritis Signer crée automatiquement une note pour un nom donné. Vous pouvez également réutiliser des noms de notes existants.

export NOTE_ID=my-signer-note
export NOTE_NAME=projects/${PROJECT_ID}/notes/${NOTE_ID}

Créer des attestations à l'aide de Kritis Signer dans un pipeline Cloud Build

Cette section explique comment utiliser le compilateur personnalisé Kritis Signer pour créer des attestations d'autorisation binaire basées sur les résultats de l'analyse des failles.

Les étapes suivantes montrent comment Kritis Signer utilise les exemples de fichiers de configuration de compilation du dépôt Kritis Signer. Chaque exemple de fichier de configuration contient les étapes de compilation suivantes :

  1. Une étape docker build qui crée une image de conteneur Docker
  2. Une étape docker push qui transfère l'image de conteneur nouvellement créée vers Container Registry
  3. Une étape vulnsign qui vérifie et signe l'image du conteneur en effectuant les opérations suivantes :

    1. Elle attend que Container Analysis renvoie les résultats des failles sur la nouvelle image de conteneur.
    2. Elle vérifie les résultats en fonction des règles sur les failles.
    3. Elle crée l'attestation si les résultats respectent les règles sur les failles.

Vous envoyez chacun de ces exemples de compilation à Cloud Build. Chaque compilation produit un résultat de faille :

  • Exemple d'échec : dans la première compilation, le résultat de faille enfreint les règles de signature des failles. Cette compilation va échouer.
  • Exemple de réussite : dans la deuxième compilation, le résultat de faille ne doit pas enfreindre les règles de signature des failles. Cette compilation va réussir.

Envoyer l'exemple d'échec de la compilation

Cet exemple crée une image de conteneur basée sur Debian 9. Actuellement, le conteneur présente une faille qui n'est pas autorisée par les règles de signature des failles décrites ci-dessus. Le compilateur personnalisé Kritis Signer ne produit pas d'attestation.

  1. (Facultatif) Affichez le fichier de configuration de compilation pour le cas d'échec.

    cat samples/signer/cloudbuild-bad.yaml
    
  2. Envoyez la compilation :

    gcloud --project=$PROJECT_ID builds submit \
      --substitutions=_KMS_KEY_NAME=$KMS_KEY_NAME,_KMS_DIGEST_ALG=$KMS_DIGEST_ALG,_NOTE_NAME=$NOTE_NAME \
      --config=samples/signer/cloudbuild-bad.yaml samples/signer
    

    Vous devriez voir une sortie semblable à ce qui suit.

    "ERROR: (gcloud.builds.submit) build build-id completed with status "FAILURE"
    
  3. Notez l'élément Build ID dans le résultat de la compilation.

    Définissez la variable d'environnement $BUILD_ID sur build-id :

    export BUILD_ID=build-id
    

    Cette variable est utilisée à l'étape suivante.

  4. Vous pouvez également trouver l'ID de la dernière compilation en exécutant la commande suivante :

    gcloud builds list --limit 1
    

    L'ID de compilation correspond au premier champ renvoyé. Modifiez la valeur --limit pour afficher plus de compilations ou supprimez complètement l'option pour afficher toutes les compilations.

  5. Vérifiez le résultat :

     gsutil cat gs://${PROJECT_NUMBER}.cloudbuild-logs.googleusercontent.com/log-${BUILD_ID}.txt | grep "does not pass VulnzSigningPolicy"
    

Envoyer l'exemple de réussite de la compilation

Cet exemple crée une image de conteneur contenant des failles qui n'enfreignent pas les règles de signature des failles. Le compilateur personnalisé Kritis Signer doit produire une attestation.

Pour envoyer l'exemple de réussite de la compilation dans Cloud Build, procédez comme suit :

  1. (Facultatif) Affichez le fichier de configuration de compilation pour le cas de réussite.

    cat samples/signer/cloudbuild-good.yaml
    
  2. Envoyez la compilation :

    gcloud --project=$PROJECT_ID builds submit \
      --substitutions=_KMS_KEY_NAME=$KMS_KEY_NAME,_KMS_DIGEST_ALG=$KMS_DIGEST_ALG,_NOTE_NAME=$NOTE_NAME \
      --config=samples/signer/cloudbuild-good.yaml samples/signer
    
  3. Là encore, notez l'ID de compilation et stockez-le dans la variable d'environnement $BUILD_ID :

    export BUILD_ID=build-id
    
  4. Enfin, pour vérifier le résultat, saisissez la commande suivante :

    gcloud --project=$PROJECT_ID builds describe $BUILD_ID | grep status
    

Étapes suivantes