Utiliser la vérification d'attestation de signature simple

Cette page explique comment utiliser la vérification des attestations de signature simple à l'aide de la validation continue (CV) de l'autorisation binaire. Elle vérifie les attestations des images de conteneurs associées à des pods exécutés dans un cluster Google Kubernetes Engine (GKE) sur lequel CV est activé.

Coûts

Ce guide utilise les produits Google Cloud suivants :

L'autorisation binaire, mais le CV est disponible sans frais pendant la phase Preview (Aperçu).
GKE
Cloud Key Management Service

Obtenez une estimation des coûts en fonction de votre utilisation prévue à l'aide du simulateur de coût.

Avant de commencer

Connectez-vous à votre compte Google Cloud. Si vous débutez sur Google Cloud, créez un compte pour évaluer les performances de nos produits en conditions réelles. Les nouveaux clients bénéficient également de 300 $ de crédits gratuits pour exécuter, tester et déployer des charges de travail.

Installez Google Cloud CLI.

Pour initialiser gcloudCLI, exécutez la commande suivante :

gcloud init

Remarque : Si vous avez déjà installé gcloud CLI, assurez-vous que vous disposez de la dernière version en exécutant

gcloud components
      update

Créer ou sélectionner un projet Google Cloud

Créez un projet Google Cloud :
```
gcloud projects create PROJECT_ID
```
Sélectionnez le projet Google Cloud que vous avez créé :
```
gcloud config set project PROJECT_ID
```

Vérifiez que la facturation est activée pour votre projet Google Cloud.

Activer les API Binary Authorization, Cloud Key Management Service, Google Kubernetes Engine :

gcloud services enable binaryauthorization.googleapis.com cloudkms.googleapis.com container.googleapis.com

Installez Google Cloud CLI.

Pour initialiser gcloudCLI, exécutez la commande suivante :

gcloud init

Remarque : Si vous avez déjà installé gcloud CLI, assurez-vous que vous disposez de la dernière version en exécutant

gcloud components
      update

Créer ou sélectionner un projet Google Cloud

Créez un projet Google Cloud :
```
gcloud projects create PROJECT_ID
```
Sélectionnez le projet Google Cloud que vous avez créé :
```
gcloud config set project PROJECT_ID
```

Vérifiez que la facturation est activée pour votre projet Google Cloud.

Activer les API Binary Authorization, Cloud Key Management Service, Google Kubernetes Engine :

gcloud services enable binaryauthorization.googleapis.com cloudkms.googleapis.com container.googleapis.com

Assurez-vous que la dernière version de gcloud CLI est installée.
Installez l'outil de ligne de commande "kubectl".
Si vos stratégies d'autorisation binaire et vos clusters GKE se trouvent dans des projets différents, assurez-vous que l'autorisation binaire est activée dans les deux projets.

Rôles requis

Cette section vous explique comment définir des rôles pour cette vérification.

Présentation

Si vous exécutez tous les produits mentionnés dans ce guide dans le même projet, vous n'avez pas besoin de définir d'autorisations. L'autorisation binaire configure correctement les rôles lorsque vous l'activez. Si vous exécutez les produits dans différents projets, vous devez définir les rôles comme décrit dans cette section.

Pour vous assurer que l'agent de service d'autorisation binaire de chaque projet dispose des autorisations nécessaires pour évaluer le contrôle d'attestation de signature simple du CV, demandez à votre administrateur d'accorder à l'agent de service d'autorisation binaire dans chaque projet les rôles IAM suivants:

Si votre projet d'attestation est différent de votre projet de stratégie : Lecteur d'occurrences d'analyse de conteneurs (roles/containeranalysis.occurrences.viewer) sur l'agent de service d'autorisation binaire du projet de stratégie, pour qu'il puisse accéder au projet d'attestation
Si votre projet de cluster est différent du projet de stratégie : Évaluateur de stratégie pour l'autorisation binaire (roles/binaryauthorization.policyEvaluator) sur l'agent de service de l'autorisation binaire du projet de cluster afin qu'il puisse accéder au projet de stratégie

Pour en savoir plus sur l'attribution de rôles, consultez la section Gérer les accès.

Votre administrateur peut également accorder les autorisations requises à l'agent de service de l'autorisation binaire de chaque projet via des rôles personnalisés ou d'autres rôles prédéfinis.

Attribuer des rôles à l'aide de gcloud CLI

Pour vous assurer que l'agent de service de l'autorisation binaire de chaque projet dispose des autorisations nécessaires pour évaluer le contrôle d'attestation de signature simple du CV, accordez à l'agent de service d'autorisation binaire dans chaque projet les rôles IAM suivants:

Autorisez l'agent de service d'autorisation binaire du projet de stratégie à accéder aux attestations de votre projet d'attestation:

Obtenez l'agent de service de l'autorisation binaire du projet de stratégie:

PROJECT_NUMBER=$(gcloud projects list \
  --filter="projectId:POLICY_PROJECT_ID" \
  --format="value(PROJECT_NUMBER)")
SERVICE_ACCOUNT="service-$PROJECT_NUMBER@gcp-sa-binaryauthorization.iam.gserviceaccount.com"

Remplacez POLICY_PROJECT_ID par l'ID du projet contenant votre stratégie.

Attribuez le rôle:

gcloud projects add-iam-policy-binding ATTESTATION_PROJECT_ID \
    --member="serviceAccount:$SERVICE_ACCOUNT" \
    --role='roles/containeranalysis.occurrences.viewer'

Remplacez ATTESTATION_PROJECT_ID par l'ID du projet contenant vos attestations.

Accordez à l'agent de service d'autorisation binaire du projet de cluster l'autorisation d'accéder à la stratégie du projet de stratégie.
1. Obtenez l'agent de service d'autorisation binaire du projet de cluster:
```
PROJECT_NUMBER=$(gcloud projects list --filter="projectId:CLUSTER_PROJECT_ID" \
  --format="value(PROJECT_NUMBER)")
CLUSTER_SERVICE_ACCOUNT="service-$PROJECT_NUMBER@gcp-sa-binaryauthorization.iam.gserviceaccount.com"
```
  Remplacez CLUSTER_PROJECT_ID par l'ID de projet du cluster.
2. Autorisez CV à évaluer la stratégie sur le cluster:
```
gcloud projects add-iam-policy-binding POLICY_PROJECT_ID \
    --member="serviceAccount:$CLUSTER_SERVICE_ACCOUNT" \
    --role='roles/binaryauthorization.policyEvaluator'
```
  Remplacez POLICY_PROJECT_ID par l'ID du projet contenant votre stratégie.

Créer une paire de clés

Dans cette section, vous allez créer une paire de clés asymétriques Elliptic Curve Digital Signature Algorithm (ECDSA).

Vous utilisez la clé privée pour signer l'image, ce qui crée l'attestation. Vous devez inclure la clé publique dans la règle de plate-forme. Lorsque CV vérifie l'attestation, il utilise la clé publique pour valider l'attestation.

Vous pouvez utiliser Cloud Key Management Service ou des clés locales, mais nous vous recommandons d'utiliser des clés Cloud KMS pour la production.

PKIX Cloud KMS

Pour créer la paire de clés dans Cloud KMS, procédez comme suit :

Configurez les variables d'environnement nécessaires à la création de la paire de clés. Pour ce faire, nous vous recommandons de renseigner les espaces réservés dans la commande suivante, puis d'exécuter celle-ci.
```
KMS_KEY_PROJECT_ID=KMS_KEY_PROJECT_ID
KMS_KEYRING_NAME=KMS_KEYRING_NAME
KMS_KEY_NAME=KMS_KEY_NAME
KMS_KEY_LOCATION=global
KMS_KEY_PURPOSE=asymmetric-signing
KMS_KEY_ALGORITHM=ec-sign-p256-sha256
KMS_PROTECTION_LEVEL=software
KMS_KEY_VERSION=1
```
Remplacez les éléments suivants :
- KMS_KEY_PROJECT_ID : ID de votre projet.
- KMS_KEYRING_NAME: nom de votre trousseau de clés Cloud KMS
- KMS_KEY_NAME: nom de votre clé Cloud KMS

Créez le trousseau de clés:

gcloud kms keyrings create ${KMS_KEYRING_NAME} \
    --location=${KMS_KEY_LOCATION} \
    --project=${KMS_KEY_PROJECT_ID}

Créez la clé :

gcloud kms keys create ${KMS_KEY_NAME} \
    --location=${KMS_KEY_LOCATION} \
    --keyring=${KMS_KEYRING_NAME}  \
    --purpose=${KMS_KEY_PURPOSE} \
    --default-algorithm=${KMS_KEY_ALGORITHM} \
    --protection-level=${KMS_PROTECTION_LEVEL} \
    --project=${KMS_KEY_PROJECT_ID}

Exportez le matériel de clé publique dans un fichier:

gcloud kms keys versions get-public-key 1 \
    --key=${KMS_KEY_NAME} \
    --keyring=${KMS_KEYRING_NAME} \
    --location=${KMS_KEY_LOCATION} \
    --output-file=/tmp/ec_public.pem \
    --project=${KMS_KEY_PROJECT_ID}

Clé locale

Pour créer la paire de clés en local, procédez comme suit:

Créez la clé privée :

PRIVATE_KEY_FILE="/tmp/ec_private.pem"
openssl ecparam -genkey -name prime256v1 -noout -out ${PRIVATE_KEY_FILE}

Obtenez la clé publique à partir de la clé privée:

PUBLIC_KEY_FILE="/tmp/ec_public.pem"
openssl ec -in ${PRIVATE_KEY_FILE} -pubout -out ${PUBLIC_KEY_FILE}

Créer le règlement de la plate-forme

Pour créer la stratégie de plate-forme de CV avec une vérification d'attestation de signature simple, procédez comme suit:

Créez le fichier de stratégie de plate-forme de vérification d'attestation simple de signature:

PKIX Cloud KMS

cat > /tmp/my-policy.yaml <<EOF
gkePolicy:
  checkSets:
    checks:
      simpleSigningAttestationCheck:
        containerAnalysisAttestationProjects:
        - projects/ATTESTATION_PROJECT_ID
        attestationAuthenticators:
          pkixPublicKeySet:
            pkixPublicKeys:
              publicKeyPem: |
$(awk '{printf "                %s\n", $0}' /tmp/ec_public.pem)
              signatureAlgorithm: ECDSA_P256_SHA256
              keyId: |
                projects/KMS_KEY_PROJECT_ID/locations/${KMS_KEY_LOCATION}/keyRings/${KMS_KEYRING_NAME}/cryptoKeys/${KMS_KEY_NAME}/cryptoKeyVersions/${KMS_KEY_VERSION}
EOF

Remplacez les éléments suivants :

ATTESTATION_PROJECT_ID: ID du projet qui stocke les attestations.
KMS_KEY_PROJECT_ID: ID de projet de votre clé KMS

Clé locale

cat > /tmp/my-policy.yaml <<EOF
gkePolicy:
  checkSets:
    checks:
      simpleSigningAttestationCheck:
        containerAnalysisAttestationProjects:
        - "projects/ATTESTATION_PROJECT_ID"
        attestationAuthenticators:
          pkixPublicKeySet:
            pkixPublicKeys:
              publicKeyPem: |
$(awk '{printf "                %s\n", $0}' /tmp/ec_public.pem)
              signatureAlgorithm: ECDSA_P256_SHA256
              keyId: |
                PUBLIC_KEY_ID
EOF

Remplacez les éléments suivants :

ATTESTATION_PROJECT_ID: ID du projet qui stocke les attestations.
PUBLIC_KEY_ID: ID qui identifie de manière unique votre clé locale.

Créez la règle de plate-forme:

Avant d'utiliser les données de la commande ci-dessous, effectuez les remplacements suivants :
- POLICY_ID: ID de règle de plate-forme de votre choix. Si la règle se trouve dans un autre projet, vous pouvez utiliser le nom complet de la ressource: projects/POLICY_PROJECT_ID/platforms/gke/policies/POLICY_ID.
- POLICY_PATH: chemin d'accès au fichier de stratégie.
- POLICY_PROJECT_ID: ID du projet de stratégie.
Exécutez la commande suivante:
Linux, macOS ou Cloud Shell

Remarque : Assurez-vous d'avoir initialisé Google Cloud CLI avec l'authentification et un projet en exécutant la commande gcloud init ou gcloud auth login et gcloud config set project.
```
gcloud beta container binauthz policy create POLICY_ID \
    --platform=gke \
    --policy-file=POLICY_PATH \
    --project=POLICY_PROJECT_ID
```
Windows (PowerShell)

Remarque : Assurez-vous d'avoir initialisé Google Cloud CLI avec l'authentification et un projet en exécutant la commande gcloud init ou gcloud auth login et gcloud config set project.
```
gcloud beta container binauthz policy create POLICY_ID `
    --platform=gke `
    --policy-file=POLICY_PATH `
    --project=POLICY_PROJECT_ID
```
Windows (cmd.exe)

Remarque : Assurez-vous d'avoir initialisé Google Cloud CLI avec l'authentification et un projet en exécutant la commande gcloud init ou gcloud auth login et gcloud config set project.
```
gcloud beta container binauthz policy create POLICY_ID ^
    --platform=gke ^
    --policy-file=POLICY_PATH ^
    --project=POLICY_PROJECT_ID
```
Stockez la valeur de l'ID pour une utilisation ultérieure:
```
PUBLIC_KEY_ID="PUBLIC_KEY_ID"
```
Remplacez PUBLIC_KEY_ID par l'ID que vous avez spécifié dans le champ keyId du fichier des règles de plate-forme plus tôt dans ce guide.

La clé privée est utilisée lors de la création des attestations, comme décrit plus loin dans ce guide.

Activer la CV

Vous pouvez créer un cluster ou mettre à jour un cluster existant pour utiliser la surveillance de CV avec des règles de plate-forme basées sur des vérifications.

Créer un cluster utilisant la surveillance de CV

Dans cette section, vous allez créer un cluster qui n'utilise que la surveillance de CV avec des règles de plate-forme basées sur des vérifications.

Avant d'utiliser les données de la commande ci-dessous, effectuez les remplacements suivants :

CLUSTER_NAME: nom de cluster
LOCATION : emplacement, par exemple us-central1 ou asia-south1
POLICY_PROJECT_ID: ID du projet dans lequel la stratégie est stockée
POLICY_ID: ID de la stratégie
CLUSTER_PROJECT_ID: ID du projet du cluster

Exécutez la commande suivante:

Linux, macOS ou Cloud Shell

gcloud beta container clusters create CLUSTER_NAME \
    --location=LOCATION \
    --binauthz-evaluation-mode=POLICY_BINDINGS \
    --binauthz-policy-bindings=name=projects/POLICY_PROJECT_ID/platforms/gke/policies/POLICY_ID \
    --project=CLUSTER_PROJECT_ID

Windows (PowerShell)

gcloud beta container clusters create CLUSTER_NAME `
    --location=LOCATION `
    --binauthz-evaluation-mode=POLICY_BINDINGS `
    --binauthz-policy-bindings=name=projects/POLICY_PROJECT_ID/platforms/gke/policies/POLICY_ID `
    --project=CLUSTER_PROJECT_ID

Windows (cmd.exe)

gcloud beta container clusters create CLUSTER_NAME ^
    --location=LOCATION ^
    --binauthz-evaluation-mode=POLICY_BINDINGS ^
    --binauthz-policy-bindings=name=projects/POLICY_PROJECT_ID/platforms/gke/policies/POLICY_ID ^
    --project=CLUSTER_PROJECT_ID

Créer un cluster qui utilise l'application forcée et la surveillance CV

Dans cette section, vous allez créer un cluster qui utilise à la fois l'application de règles project-singleton et la surveillance de CV avec des règles de plate-forme basées sur des vérifications:

Avant d'utiliser les données de la commande ci-dessous, effectuez les remplacements suivants :

CLUSTER_NAME: nom de cluster
LOCATION : emplacement, par exemple us-central1 ou asia-south1
POLICY_PROJECT_ID: ID du projet dans lequel la stratégie est stockée
POLICY_ID: ID de la stratégie
CLUSTER_PROJECT_ID: ID du projet du cluster

Exécutez la commande suivante:

Linux, macOS ou Cloud Shell

gcloud beta container clusters create CLUSTER_NAME \
    --location=LOCATION \
    --binauthz-evaluation-mode=POLICY_BINDINGS_AND_PROJECT_SINGLETON_POLICY_ENFORCE \
    --binauthz-policy-bindings=name=projects/POLICY_PROJECT_ID/platforms/gke/policies/POLICY_ID \
    --project=CLUSTER_PROJECT_ID

Windows (PowerShell)

gcloud beta container clusters create CLUSTER_NAME `
    --location=LOCATION `
    --binauthz-evaluation-mode=POLICY_BINDINGS_AND_PROJECT_SINGLETON_POLICY_ENFORCE `
    --binauthz-policy-bindings=name=projects/POLICY_PROJECT_ID/platforms/gke/policies/POLICY_ID `
    --project=CLUSTER_PROJECT_ID

Windows (cmd.exe)

gcloud beta container clusters create CLUSTER_NAME ^
    --location=LOCATION ^
    --binauthz-evaluation-mode=POLICY_BINDINGS_AND_PROJECT_SINGLETON_POLICY_ENFORCE ^
    --binauthz-policy-bindings=name=projects/POLICY_PROJECT_ID/platforms/gke/policies/POLICY_ID ^
    --project=CLUSTER_PROJECT_ID

Mettre à jour un cluster pour utiliser la surveillance de CV

Dans cette section, vous allez mettre à jour un cluster pour qu'il utilise la surveillance de CV avec des règles de plate-forme basées sur des vérifications uniquement. Si l'application de règles de singleton par projet est déjà activée sur le cluster, l'exécution de cette commande la désactive. Envisagez plutôt de mettre à jour le cluster avec l'application forcée et la surveillance du CV activées.

Avant d'utiliser les données de la commande ci-dessous, effectuez les remplacements suivants :

CLUSTER_NAME: nom du cluster
LOCATION : emplacement, par exemple us-central1 ou asia-south1
POLICY_PROJECT_ID: ID du projet dans lequel la stratégie est stockée
POLICY_ID: ID de la stratégie
CLUSTER_PROJECT_ID: ID du projet du cluster

Exécutez la commande suivante:

Linux, macOS ou Cloud Shell

gcloud beta container clusters update CLUSTER_NAME \
    --location=LOCATION \
    --binauthz-evaluation-mode=POLICY_BINDINGS \
    --binauthz-policy-bindings=name=projects/POLICY_PROJECT_ID/platforms/gke/policies/POLICY_ID \
    --project=CLUSTER_PROJECT_ID

Windows (PowerShell)

gcloud beta container clusters update CLUSTER_NAME `
    --location=LOCATION `
    --binauthz-evaluation-mode=POLICY_BINDINGS `
    --binauthz-policy-bindings=name=projects/POLICY_PROJECT_ID/platforms/gke/policies/POLICY_ID `
    --project=CLUSTER_PROJECT_ID

Windows (cmd.exe)

gcloud beta container clusters update CLUSTER_NAME ^
    --location=LOCATION ^
    --binauthz-evaluation-mode=POLICY_BINDINGS ^
    --binauthz-policy-bindings=name=projects/POLICY_PROJECT_ID/platforms/gke/policies/POLICY_ID ^
    --project=CLUSTER_PROJECT_ID

Mettre à jour un cluster pour utiliser l'application forcée et la surveillance CV

Dans cette section, vous allez mettre à jour un cluster pour utiliser à la fois l'application de règles de singleton de projet et la surveillance de CV avec des règles de plate-forme basées sur des vérifications.

Avant d'utiliser les données de la commande ci-dessous, effectuez les remplacements suivants :

CLUSTER_NAME: nom de cluster
LOCATION : emplacement, par exemple us-central1 ou asia-south1
POLICY_PROJECT_ID: ID du projet dans lequel la stratégie est stockée
POLICY_ID: ID de la stratégie
CLUSTER_PROJECT_ID: ID du projet du cluster

Exécutez la commande suivante:

Linux, macOS ou Cloud Shell

gcloud beta container clusters update CLUSTER_NAME \
    --location=LOCATION \
    --binauthz-evaluation-mode=POLICY_BINDINGS_AND_PROJECT_SINGLETON_POLICY_ENFORCE \
    --binauthz-policy-bindings=name=projects/POLICY_PROJECT_ID/platforms/gke/policies/POLICY_ID \
    --project=CLUSTER_PROJECT_ID

Windows (PowerShell)

gcloud beta container clusters update CLUSTER_NAME `
    --location=LOCATION `
    --binauthz-evaluation-mode=POLICY_BINDINGS_AND_PROJECT_SINGLETON_POLICY_ENFORCE `
    --binauthz-policy-bindings=name=projects/POLICY_PROJECT_ID/platforms/gke/policies/POLICY_ID `
    --project=CLUSTER_PROJECT_ID

Windows (cmd.exe)

gcloud beta container clusters update CLUSTER_NAME ^
    --location=LOCATION ^
    --binauthz-evaluation-mode=POLICY_BINDINGS_AND_PROJECT_SINGLETON_POLICY_ENFORCE ^
    --binauthz-policy-bindings=name=projects/POLICY_PROJECT_ID/platforms/gke/policies/POLICY_ID ^
    --project=CLUSTER_PROJECT_ID

Créer la note Artifact Analysis

Dans cette section, vous allez créer un exemple de note d'analyse d'artefacts pour associer des attestations. Pour créer la note, procédez comme suit:

Créez les variables de note:

NOTE_PROJECT_ID=NOTE_PROJECT_ID
NOTE_ID="test-note"
NOTE_URI="projects/${NOTE_PROJECT_ID}/notes/${NOTE_ID}"
DESCRIPTION="CV test note"

Remplacez NOTE_PROJECT_ID: l'ID du projet qui contient la note.

Créez le fichier de contenu de la note:

cat > /tmp/note_payload.json << EOM
{
  "name": "${NOTE_URI}",
  "attestation": {
    "hint": {
      "human_readable_name": "${DESCRIPTION}"
    }
  }
}
EOM

Créez la note :

curl -X POST \
    -H "Content-Type: application/json" \
    -H "Authorization: Bearer $(gcloud auth print-access-token)"  \
    -H "x-goog-user-project: ${NOTE_PROJECT_ID}" \
    --data-binary @/tmp/note_payload.json "https://containeranalysis.googleapis.com/v1/projects/${NOTE_PROJECT_ID}/notes/?noteId=${NOTE_ID}"

Remplacez NOTE_PROJECT_ID: l'ID du projet qui contient la note.

Facultatif: Pour vérifier que vous avez créé la note, procédez comme suit:

curl \
    -H "Authorization: Bearer $(gcloud auth print-access-token)"  \
    -H "x-goog-user-project: NOTE_PROJECT_ID" \
"https://containeranalysis.googleapis.com/v1/projects/NOTE_PROJECT_ID/notes/"

Remplacez NOTE_PROJECT_ID par l'ID du projet contenant la note.

Test de CV

Dans cette section, vous allez tester le CV en déployant l'image pour laquelle vous créez une attestation. Dans ce cas, la vérification d'attestation de signature simple du CV vérifie l'attestation et ne produit aucune entrée de journal.

Vous tentez ensuite de déployer une image différente sans attestation. Dans ce cas, la vérification du CV ne trouve pas l'attestation et consigne l'infraction dans Cloud Logging.

Créez un certificat

Pour satisfaire à cette vérification, l'image a besoin d'une attestation valide. Pour créer l'attestation, procédez comme suit:

Créez les variables que vous utilisez pour créer l'attestation:

IMAGE_PATH=us-docker.pkg.dev/google-samples/containers/gke/hello-app
IMAGE_DIGEST=sha256:37e5287945774f27b418ce567cd77f4bbc9ef44a1bcd1a2312369f31f9cce567
IMAGE_TO_ATTEST="${IMAGE_PATH}@${IMAGE_DIGEST}"

Créez un fichier de charge utile de signature :

cat > /tmp/generated_payload.json << EOM
{
  "critical": {
    "identity": {
      "docker-reference": "${IMAGE_PATH}"
    },
    "image": {
      "docker-manifest-digest": "${IMAGE_DIGEST}"
    },
    "type": "Google cloud binauthz container signature"
  }
}
EOM

Créez l'attestation :

Signez la charge utile:

PKIX Cloud KMS

gcloud kms asymmetric-sign \
    --version=${KMS_KEY_VERSION} \
    --key=${KMS_KEY_NAME} \
    --keyring=${KMS_KEYRING_NAME} \
    --location=${KMS_KEY_LOCATION} --digest-algorithm sha256 \
    --input-file=/tmp/generated_payload.json \
    --signature-file=/tmp/ec_signature \
    --project=${KMS_KEY_PROJECT_ID}

Clé locale

openssl dgst -sha256 -sign ${PRIVATE_KEY_FILE} /tmp/generated_payload.json > /tmp/ec_signature

Créez le contenu de l'attestation:

cat > /tmp/attestation.json << EOM
{
  "resourceUri": "${IMAGE_TO_ATTEST}",
  "note_name": "${NOTE_URI}",
  "attestation": {
    "serialized_payload": "$(base64 --wrap=0 /tmp/generated_payload.json)",
    "signatures": [{
      "public_key_id": "${PUBLIC_KEY_ID}",
      "signature": "$(base64 --wrap=0 /tmp/ec_signature)"
    }]
  }
}
EOM

Créez l'attestation :

curl -X POST "https://containeranalysis.googleapis.com/v1/projects/${NOTE_PROJECT_ID}/occurrences/" \
    -H "Content-Type: application/json" \
    -H "X-Goog-User-Project: ${NOTE_PROJECT_ID}" \
    -H "Authorization: Bearer $(gcloud auth print-access-token)" \
    --data-binary @/tmp/attestation.json

Remplacez NOTE_PROJECT_ID par l'ID du projet contenant la note.

Déployer l'image associée à une attestation

Pour déployer une image pour laquelle aucune attestation n'a été créée, procédez comme suit:

Configurez kubectl:
```
gcloud container clusters get-credentials CLUSTER_NAME \
    --location=LOCATION \
    --project=CLUSTER_PROJECT_ID
```
Remplacez les éléments suivants :
- CLUSTER_NAME : nom du cluster
- LOCATION: emplacement du cluster
- CLUSTER_PROJECT_ID: ID du projet du cluster
Déployez un service et vérifiez le déploiement par rapport à la stratégie d'autorisation binaire:
```
kubectl run hello-app --image=$IMAGE_PATH@$IMAGE_DIGEST
```
Le pod a été déployé. Comme l'image possède une attestation, le CV ne génère pas d'entrées de journal liées à ce pod.

Déployer une image sans attestation

Dans cette section, vous allez déployer une image sans attestation associée.

Comme la stratégie nécessite des attestations, mais que cette image n'en possède pas, CV consigne régulièrement le cas de non-respect lorsque le conteneur est en cours d'exécution.

Pour déployer l'image, exécutez la commande suivante:

kubectl run hello-app-no-attestation \
    --image=gcr.io/google-samples/hello-app@sha256:845f77fab71033404f4cfceaa1ddb27b70c3551ceb22a5e7f4498cdda6c9daea

Le pod a été déployé. Comme l'image ne possède pas d'attestation, le CV génère des entrées de journal pendant l'exécution du pod.

Afficher les journaux des entrées de CV

CV consigne les cas de non-respect des règles de la plate-forme dans Cloud Logging dans un délai de 24 heures. Les entrées s'affichent généralement au bout de quelques heures.

Si aucune image n'enfreint les règles de plate-forme que vous avez activées, aucune entrée n'apparaît dans les journaux.

Pour afficher les entrées du journal CV des sept derniers jours, exécutez la commande suivante:

gcloud logging read \
     --order="desc" \
     --freshness=7d \
     --project=CLUSTER_PROJECT_ID \
    'logName:"binaryauthorization.googleapis.com%2Fcontinuous_validation" "policyName"'

Remplacez CLUSTER_PROJECT_ID par l'ID de projet du cluster.

Types de vérifications

Les journaux CV vérifient les informations concernant les cas de non-respect dans checkResults. Dans l'entrée, la valeur checkType indique le contrôle. Les valeurs de chaque vérification sont les suivantes:

ImageFreshnessCheck
SimpleSigningAttestationCheck
SlsaCheck
TrustedDirectoryCheck
VulnerabilityCheck

Exemple de journal

L'exemple d'entrée de journalisation CV suivant décrit une image non conforme qui enfreint une vérification d'un annuaire de confiance:

{
  "insertId": "637c2de7-0000-2b64-b671-24058876bb74",
  "jsonPayload": {
    "podEvent": {
      "endTime": "2022-11-22T01:14:30.430151Z",
      "policyName": "projects/123456789/platforms/gke/policies/my-policy",
      "images": [
        {
          "result": "DENY",
          "checkResults": [
            {
              "explanation": "TrustedDirectoryCheck at index 0 with display name \"My trusted directory check\" has verdict NOT_CONFORMANT. Image is not in a trusted directory",
              "checkSetName": "My check set",
              "checkSetIndex": "0",
              "checkName": "My trusted directory check",
              "verdict": "NON_CONFORMANT",
              "checkType": "TrustedDirectoryCheck",
              "checkIndex": "0"
            }
          ],
          "image": "gcr.io/my-project/hello-app:latest"
        }
      ],
      "verdict": "VIOLATES_POLICY",
      "podNamespace": "default",
      "deployTime": "2022-11-22T01:06:53Z",
      "pod": "hello-app"
    },
    "@type": "type.googleapis.com/google.cloud.binaryauthorization.v1beta1.ContinuousValidationEvent"
  },
  "resource": {
    "type": "k8s_cluster",
    "labels": {
      "project_id": "my-project",
      "location": "us-central1-a",
      "cluster_name": "my-test-cluster"
    }
  },
  "timestamp": "2022-11-22T01:44:28.729881832Z",
  "severity": "WARNING",
  "logName": "projects/my-project/logs/binaryauthorization.googleapis.com%2Fcontinuous_validation",
  "receiveTimestamp": "2022-11-22T03:35:47.171905337Z"
}

Effectuer un nettoyage

Cette section explique comment nettoyer la surveillance CV que vous avez configurée précédemment dans ce guide.

Vous pouvez désactiver la surveillance des CV ou l'autorisation binaire et le CV dans votre cluster.

Désactiver l'autorisation binaire dans un cluster

Pour désactiver l'application de l'autorisation binaire et CV dans votre cluster, exécutez la commande suivante:

gcloud beta container clusters update CLUSTER_NAME \
    --binauthz-evaluation-mode=DISABLED \
    --location=LOCATION \
    --project=CLUSTER_PROJECT_ID

Remplacez les éléments suivants :

CLUSTER_NAME : nom du cluster
LOCATION: emplacement du cluster
CLUSTER_PROJECT_ID: ID du projet du cluster

Désactiver la surveillance des règles basée sur les vérifications dans un cluster

Pour désactiver la CV avec des stratégies basées sur la vérification dans le cluster et réactiver l'application à l'aide de la stratégie d'application de l'autorisation binaire, exécutez la commande suivante:

gcloud beta container clusters update CLUSTER_NAME  \
    --binauthz-evaluation-mode=PROJECT_SINGLETON_POLICY_ENFORCE \
    --location=LOCATION \
    --project="CLUSTER_PROJECT_ID"

Remplacez les éléments suivants :

CLUSTER_NAME : nom du cluster
LOCATION: emplacement du cluster
CLUSTER_PROJECT_ID: ID du projet du cluster

Notez que --binauthz-evaluation-mode=PROJECT_SINGLETON_POLICY_ENFORCE équivaut à l'ancien indicateur --enable-binauthz.

Supprimer la stratégie

Pour supprimer la règle, exécutez la commande suivante. Il n'est pas nécessaire de supprimer la règle de plate-forme basée sur des vérifications pour désactiver l'audit.

gcloud beta container binauthz policy delete POLICY_ID \
    --platform=gke \
    --project="POLICY_PROJECT_ID"

Remplacez les éléments suivants :

POLICY_ID: ID de la stratégie
POLICY_PROJECT_ID: ID du projet de stratégie

Utiliser la vérification d'attestation de signature simple

Coûts

Avant de commencer

Rôles requis

Présentation

Attribuer des rôles à l'aide de gcloud CLI

Créer une paire de clés

PKIX Cloud KMS

Clé locale

Créer le règlement de la plate-forme

PKIX Cloud KMS

Clé locale

Linux, macOS ou Cloud Shell

Windows (PowerShell)

Windows (cmd.exe)

Activer la CV

Créer un cluster utilisant la surveillance de CV

Linux, macOS ou Cloud Shell

Windows (PowerShell)

Windows (cmd.exe)

Créer un cluster qui utilise l'application forcée et la surveillance CV

Linux, macOS ou Cloud Shell

Windows (PowerShell)

Windows (cmd.exe)

Mettre à jour un cluster pour utiliser la surveillance de CV

Linux, macOS ou Cloud Shell

Windows (PowerShell)

Windows (cmd.exe)

Mettre à jour un cluster pour utiliser l'application forcée et la surveillance CV

Linux, macOS ou Cloud Shell

Windows (PowerShell)

Windows (cmd.exe)

Créer la note Artifact Analysis

Test de CV

Créez un certificat

PKIX Cloud KMS

Clé locale

Déployer l'image associée à une attestation

Déployer une image sans attestation

Afficher les journaux des entrées de CV

Types de vérifications

Exemple de journal

Effectuer un nettoyage

Désactiver l'autorisation binaire dans un cluster

Désactiver la surveillance des règles basée sur les vérifications dans un cluster

Supprimer la stratégie

Étapes suivantes