Cette page explique comment utiliser la méthode de validation continue de type autorisation binaire (CV) Vérification de signature Sigstore. Cette vérification vérifie les signatures générées par Sigstore des images de conteneurs associées aux pods exécutés dans un cluster Google Kubernetes Engine (GKE) sur lequel la CV est activée. La principale différence entre cette vérification et la vérification d'attestation de signature simple est que le workflow de signature Sigstore n'utilise pas les notes Artifact Analysis pour associer des signatures aux images. Toutes les signatures sont stockées avec l'image qu'elles signent.
Cette vérification n'est compatible qu'avec les dépôts Artifact Registry.
Coûts
Ce guide utilise les produits Google Cloud suivants :
- Autorisation binaire, mais la CV est disponible gratuitement pendant la phase bêta
- GKE
- Cloud Key Management Service
- Artifact Registry
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.
- Install the Google Cloud CLI.
-
To initialize the gcloud CLI, run the following command:
gcloud init
-
Create or select a Google Cloud project.
-
Create a Google Cloud project:
gcloud projects create PROJECT_ID
Replace
PROJECT_ID
with a name for the Google Cloud project you are creating. -
Select the Google Cloud project that you created:
gcloud config set project PROJECT_ID
Replace
PROJECT_ID
with your Google Cloud project name.
-
-
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, Artifact Registry :
gcloud services enable binaryauthorization.googleapis.com
cloudkms.googleapis.com container.googleapis.com artifactregistry.googleapis.com - Install the Google Cloud CLI.
-
To initialize the gcloud CLI, run the following command:
gcloud init
-
Create or select a Google Cloud project.
-
Create a Google Cloud project:
gcloud projects create PROJECT_ID
Replace
PROJECT_ID
with a name for the Google Cloud project you are creating. -
Select the Google Cloud project that you created:
gcloud config set project PROJECT_ID
Replace
PROJECT_ID
with your Google Cloud project name.
-
-
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, Artifact Registry :
gcloud services enable binaryauthorization.googleapis.com
cloudkms.googleapis.com container.googleapis.com artifactregistry.googleapis.com - Assurez-vous que gcloud CLI est mis à jour à la dernière version.
- 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.
- Installez l'outil de ligne de commande
cosign
.
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 des 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 des 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 la vérification de la signature Sigstore CV, demandez à votre administrateur d'accorder à l'agent de service d'autorisation binaire de chaque projet les rôles IAM suivants :
-
Si votre projet de cluster est différent de votre projet de règles : Évaluateur de règles d'autorisation binaire (
roles/binaryauthorization.policyEvaluator
) sur l'agent de service d'autorisation binaire du projet de cluster. -
Si votre projet de dépôt d'images est différent de votre projet de règles : Lecteur Artifact Registry (
roles/artifactregistry.reader
) sur l'agent de service d'autorisation binaire du projet de règles.
Pour en savoir plus sur l'attribution de rôles, consultez la section Gérer les accès.
Votre administrateur peut également attribuer à l'agent de service d'autorisation binaire de chaque projet les autorisations requises 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 d'autorisation binaire de chaque projet dispose des autorisations nécessaires pour évaluer la vérification de signature Sigstore de la CV, accordez à chaque agent de service d'autorisation binaire les rôles IAM suivants :
Accordez à l'agent de service d'autorisation binaire du projet de cluster l'accès à la règle dans le projet de règles.
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.Autorisez la CV à évaluer la règle 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 règle.
Autorisez l'agent de service d'autorisation binaire du projet de règles à accéder aux signatures de votre dépôt :
Obtenez l'agent de service d'autorisation binaire du projet de règles :
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 règle.Attribuez le rôle :
gcloud projects add-iam-policy-binding REPOSITORY_PROJECT_ID \ --member="serviceAccount:$SERVICE_ACCOUNT" \ --role='roles/artifactregistry.reader'
Remplacez
REPOSITORY_PROJECT_ID
par l'ID du projet contenant votre dépôt.
Créer une paire de clés
Dans cette section, vous allez créer une paire de clés asymétriques ECDSA (Elliptic Curve Digital Signature Algorithm).
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 la CV vérifie l'attestation, elle utilise la clé publique pour la valider.
Vous pouvez utiliser Cloud Key Management Service (Cloud KMS) ou des clés locales, mais nous vous recommandons d'utiliser des clés Cloud KMS pour la production.
Cosign PKIX Cloud KMS
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 la commande.
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.
Générez la clé avec la CLI Cosign :
cosign generate-key-pair \ --kms gcpkms://projects/${KMS_KEY_PROJECT_ID}/locations/${KMS_KEY_LOCATION}/keyRings/${KMS_KEYRING_NAME}/cryptoKeys/${KMS_KEY_NAME}
Enregistrez l'emplacement de la clé publique :
Cosign enregistre automatiquement la clé publique générée sous le nom
cosign.pub
dans le répertoire dans lequel la commandegenerate-key-pair
a été exécutée. Enregistrez cet emplacement de fichier dans une variable pour les commandes futures.PUBLIC_KEY_FILE="$(pwd)/cosign.pub"
gcloud 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 la commande.
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 :
PUBLIC_KEY_FILE="$(pwd)/cosign.pub" gcloud kms keys versions get-public-key 1 \ --key=${KMS_KEY_NAME} \ --keyring=${KMS_KEYRING_NAME} \ --location=${KMS_KEY_LOCATION} \ --output-file=${PUBLIC_KEY_FILE} \ --project=${KMS_KEY_PROJECT_ID}
Clé locale
Pour créer la paire de clés localement, procédez comme suit :
cosign generate-key-pair
PUBLIC_KEY_FILE="$(pwd)/cosign.pub"
PRIVATE_KEY_FILE="$(pwd)/cosign.key"
Créer la règle de plate-forme
Pour créer la règle de plate-forme CV avec vérification de signature Sigstore, procédez comme suit :
Créez le fichier de règle de plate-forme de vérification de signature Sigstore :
cat > POLICY_PATH <<EOF gkePolicy: checkSets: - checks: - displayName: sigstore-signature-check sigstoreSignatureCheck: sigstoreAuthorities: - displayName: sigstore-authority publicKeySet: publicKeys: publicKeyPem: | $(awk '{printf " %s\n", $0}' ${PUBLIC_KEY_FILE}) EOF
Remplacez
POLICY_PATH
par le chemin d'accès au fichier de règle.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 règle.
- POLICY_PROJECT_ID : ID du projet de règle.
Exécutez la commande suivante :
Linux, macOS ou Cloud Shell
gcloud beta container binauthz policy create POLICY_ID \ --platform=gke \ --policy-file=POLICY_PATH \ --project=POLICY_PROJECT_ID
Windows (PowerShell)
gcloud beta container binauthz policy create POLICY_ID ` --platform=gke ` --policy-file=POLICY_PATH ` --project=POLICY_PROJECT_ID
Windows (cmd.exe)
gcloud beta container binauthz policy create POLICY_ID ^ --platform=gke ^ --policy-file=POLICY_PATH ^ --project=POLICY_PROJECT_ID
- 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 :
Activer la CV
Vous pouvez créer un cluster ou mettre à jour un cluster existant pour utiliser la surveillance CV avec des règles de plate-forme basées sur des vérifications.
Créer un cluster utilisant la surveillance CV
Dans cette section, vous allez créer un cluster qui n'utilise que la surveillance 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 du cluster.LOCATION
: emplacement (par exemple :us-central1
ouasia-south1
).POLICY_PROJECT_ID
: l'ID du projet dans lequel la règle est stockée.POLICY_ID
: ID de la règle.CLUSTER_PROJECT_ID
: ID de 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 utilisant l'application forcée et la surveillance CV
Dans cette section, vous allez créer un cluster qui utilise à la fois l'application des règles Singleton de projet et la surveillance CV avec des règles de plate-forme basées sur les vérifications :
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
ouasia-south1
).POLICY_PROJECT_ID
: l'ID du projet dans lequel la règle est stockée.POLICY_ID
: ID de la règle.CLUSTER_PROJECT_ID
: ID de 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 CV
Dans cette section, vous allez mettre à jour un cluster pour utiliser la surveillance CV avec uniquement des règles de plate-forme basées sur la vérification. Si l'application de la règle Singleton de 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 CV activées.
Avant d'utiliser les données de la commande ci-dessous, effectuez les remplacements suivants :
CLUSTER_NAME
: nom du clusterLOCATION
: emplacement (par exemple :us-central1
ouasia-south1
)POLICY_PROJECT_ID
: ID du projet dans lequel la règle est stockéePOLICY_ID
: ID de la règleCLUSTER_PROJECT_ID
: ID de 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 forcée de la règle Singleton de projet et la surveillance 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 du clusterLOCATION
: emplacement (par exemple :us-central1
ouasia-south1
)POLICY_PROJECT_ID
: ID du projet dans lequel la règle est stockéePOLICY_ID
: ID de la règleCLUSTER_PROJECT_ID
: ID de 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
Tester la CV
Dans cette section, vous allez tester la CV en déployant une image signée. Dans ce cas, la vérification de signature CV Sigstore vérifie la signature et ne produit aucune entrée de journal.
Vous tenterez ensuite de déployer une autre image non signée. Dans ce cas, la vérification CV ne trouve pas de signature valide et consigne la violation dans Cloud Logging.
Signer une image
Pour satisfaire la vérification, l'image doit posséder une attestation valide. Pour créer la signature, procédez comme suit :
Créez les variables que vous utilisez pour signer l'image :
IMAGE_PATH=IMAGE_PATH IMAGE_DIGEST=sha256:IMAGE_DIGEST_SHA IMAGE_TO_SIGN="${IMAGE_PATH}@${IMAGE_DIGEST}"
Remplacez les éléments suivants :
IMAGE_PATH
: chemin d'accès à votre imageIMAGE_DIGEST_SHA
: hachage SHA du condensé de votre image.
Signez l'image et transférez la signature vers Artifact Registry :
PKIX Cloud KMS
Signez l'image avec une clé hébergée dans Cloud KMS, puis transférez la signature vers Artifact Registry :
cosign sign \ --key gcpkms://projects/${KMS_KEY_PROJECT_ID}/locations/${KMS_KEY_LOCATION}/keyRings/${KMS_KEYRING_NAME}/cryptoKeys/${KMS_KEY_NAME} \ ${IMAGE_TO_SIGN}
Clé locale
Signez l'image à l'aide d'une clé privée locale et transférez la signature vers Artifact Registry.
cosign sign --key ${PRIVATE_KEY_FILE} ${IMAGE_TO_SIGN}
Répondez à l'invite Cosign :
Après avoir exécuté la commande
cosign sign
, Cosign vous demande si vous souhaitez importer la signature dans le journal de transparence Rekor. Répondezy
oun
aux invites. Pour en savoir plus sur Rekor, consultez la documentation associée.
Valider manuellement la signature
Pour valider manuellement la signature, procédez comme suit :
Assurez-vous que la signature existe dans Artifact Registry :
console Google Cloud
Accédez à la page "Artifact Registry" dans la console Google Cloud.
Dans la liste des dépôts, cliquez sur le nom du dépôt contenant votre image.
Cliquez sur le nom de l'image que vous avez signée.
Repérez l'élément contenant la signature. Cet élément est associé au tag suivant :
sha256-[image digest].sig
. Un seul élément doit être associé au tag.Cliquez sur Fichier manifeste.
Vous devriez voir un fichier au format JSON comportant différents champs. Chaque signature se trouve dans un élément de la liste
layers
, dans la carteannotations
. Les signatures se trouvent dans la clédev.cosignproject.cosign/signature
.Voici un exemple de fichier manifeste :
{ "schemaVersion": 2, "mediaType": "application/vnd.oci.image.manifest.v1+json", "config": { "mediaType": "application/vnd.oci.image.config.v1+json", "size": SIZE_OF_LAYERS, "digest": "DIGEST_OF_LAYERS" }, "layers": [ { "mediaType": "application/vnd.dev.cosign.simplesigning.v1+json", "size": SIZE_OF_ANNOTATIONS, "digest": "DIGEST_OF_ANNOTATIONS", "annotations": { "dev.cosignproject.cosign/signature": "BASE64_SIGNATURE", "dev.sigstore.cosign/bundle": "BUNDLE" } } ] }
L'exemple de fichier manifeste comprend les éléments suivants :
SIZE_OF_LAYERS
: taille du tableaulayers
en octets.DIGEST_OF_LAYERS
: condensé du tableaulayers
SIZE_OF_ANNOTATIONS
: taille du dictionnaireannotations
en octetsDIGEST_OF_ANNOTATIONS
: condensé du dictionnaireannotations
BASE64_SIGNATURE
: signature brute encodée au format base64. Il s'agit de la signature qui sera utilisée pour la validation.BUNDLE
: métadonnées spécifiques à Sigstore
Pour en savoir plus sur le format du fichier manifeste, consultez les spécifications de signature de cosign de Sigstore.
Ligne de commande
Recherchez l'artefact approprié :
Répertoriez les éléments stockés avec l'image :
gcloud artifacts docker tags list ${IMAGE_PATH}
Voici un exemple de sortie :
Listing items under project PROJECT_ID, location REPOSITORY_LOCATION, repository REPOSITORY_NAME. TAG IMAGE DIGEST latest us-east1-docker.pkg.dev/my-project/my-repo/my-image sha256:abc123 sha256-abc123.sig us-east1-docker.pkg.dev/my-project/my-repo/my-image sha256:def456
Dans le résultat, l'artefact avec le tag
sha256-abc123.sig
contient la signature dans son fichier manifeste.Obtenir le fichier manifeste
Pour obtenir le fichier manifeste de l'artefact avec le tag
sha256-IMAGE_DIGEST_SHA.sig
, exécutez la commande suivante :curl -X GET -H "Content-Type: application/json" \ -H "Authorization: Bearer $(gcloud auth print-access-token)" \ -H "X-Goog-User-Project: REPOSITORY_PROJECT_ID" \ "https://REPOSITORY_LOCATION-docker.pkg.dev/v2/REPOSITORY_PROJECT_ID/REPOSITORY_NAME/IMAGE_NAME/manifests/sha256-IMAGE_DIGEST_SHA.sig"
Remplacez les éléments suivants :
REPOSITORY_PROJECT_ID
: ID du projet contenant le dépôtREPOSITORY_LOCATION
: emplacement du dépôtREPOSITORY_NAME
: nom du dépôtIMAGE_NAME
: nom de l'image.
Vous devriez voir un fichier au format JSON comportant différents champs. Chaque signature se trouve dans un élément de la liste
layers
, dans la carteannotations
. Les signatures se trouvent dans la clédev.cosignproject.cosign/signature
.Voici un exemple de fichier manifeste :
{ "schemaVersion": 2, "mediaType": "application/vnd.oci.image.manifest.v1+json", "config": { "mediaType": "application/vnd.oci.image.config.v1+json", "size": SIZE_OF_LAYERS, "digest": "DIGEST_OF_LAYERS" }, "layers": [ { "mediaType": "application/vnd.dev.cosign.simplesigning.v1+json", "size": SIZE_OF_ANNOTATIONS, "digest": "DIGEST_OF_ANNOTATIONS", "annotations": { "dev.cosignproject.cosign/signature": "BASE64_SIGNATURE", "dev.sigstore.cosign/bundle": "BUNDLE" } } ] }
L'exemple de fichier manifeste comprend les éléments suivants :
SIZE_OF_LAYERS
: taille du tableaulayers
en octets.DIGEST_OF_LAYERS
: condensé du tableaulayers
SIZE_OF_ANNOTATIONS
: taille du dictionnaireannotations
en octetsDIGEST_OF_ANNOTATIONS
: condensé du dictionnaireannotations
BASE64_SIGNATURE
: signature brute encodée au format base64. Il s'agit de la signature qui sera utilisée pour la validation.BUNDLE
: métadonnées spécifiques à Sigstore
Pour en savoir plus sur le format du fichier manifeste, consultez les spécifications de signature de cosign de Sigstore.
Validez manuellement la signature :
Utilisez
cosign verify
pour valider la signature importée :PKIX Cloud KMS
cosign verify --key gcpkms://projects/${KMS_KEY_PROJECT_ID}/locations/${KMS_KEY_LOCATION}/keyRings/${KMS_KEYRING_NAME}/cryptoKeys/${KMS_KEY_NAME} \ ${IMAGE_PATH}@${IMAGE_DIGEST}
Clé locale
cosign verify --key {PUBLIC_KEY_FILE} ${IMAGE_PATH}@${IMAGE_DIGEST}
Le résultat de la commande indique
The signatures were verified against the specified public key
si la validation a réussi.
Déployer l'image signée
Pour déployer une image signé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 clusterLOCATION
: emplacement du clusterCLUSTER_PROJECT_ID
: ID de projet du cluster
Déployez une image et vérifiez le déploiement par rapport à la règle d'autorisation binaire :
kubectl run hello-app-signed --image=${IMAGE_PATH}@${IMAGE_DIGEST}
Le pod a été déployé. Comme l'image est signée, la CV ne produit pas d'entrées de journal associées à ce pod.
Déployer une image non signée
Dans cette section, vous allez déployer une image non signée.
Étant donné que la stratégie nécessite des signatures et que cette image n'en a pas, la CV consigne régulièrement la violation pendant l'exécution du conteneur.
Pour déployer l'image, exécutez la commande suivante :
kubectl run hello-app-unsigned \
--image=UNSIGNED_IMAGE_PATH@UNSIGNED_IMAGE_DIGEST
Le pod a été déployé. Comme l'image n'a pas d'attestation, la CV génère des entrées de journal pendant l'exécution du pod.
Afficher les journaux pour les entrées de CV
La CV consigne les cas de non-respect des règles de plate-forme dans Cloud Logging sous 24 heures. Les entrées sont généralement visibles en 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 de journal de la 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 du projet de cluster.
Types de test
Les journaux de CV vérifient les informations de violation dans checkResults
. Dans l'entrée, la valeur checkType
indique la vérification. Les valeurs pour chaque vérification sont les suivantes :
ImageFreshnessCheck
SigstoreSignatureCheck
SimpleSigningAttestationCheck
SlsaCheck
TrustedDirectoryCheck
VulnerabilityCheck
Exemple de journal
L'exemple d'entrée de journal CV suivant décrit une image non conforme qui enfreint une vérification de répertoire 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 CV ou l'autorisation binaire et la CV dans votre cluster.
Désactiver l'autorisation binaire dans un cluster
Pour désactiver la CV et l'application forcée de l'autorisation binaire 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 clusterLOCATION
: emplacement du clusterCLUSTER_PROJECT_ID
: ID de projet du cluster
Désactiver la surveillance des règles basées sur des vérifications dans un cluster
Pour désactiver la CV avec des règles basées sur la vérification dans le cluster et réactiver l'application forcée à l'aide de la règle 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 clusterLOCATION
: emplacement du clusterCLUSTER_PROJECT_ID
: ID de projet du cluster
Notez que --binauthz-evaluation-mode=PROJECT_SINGLETON_POLICY_ENFORCE
équivaut à l'ancienne option --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 son 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 règlePOLICY_PROJECT_ID
: ID du projet de règles
Étapes suivantes
- Utiliser la vérification de fraîcheur d'image
- Utiliser la vérification d'attestation de signature simple
- Utiliser la vérification de signature Sigstore
- Utiliser la vérification SLSA
- Utiliser la vérification du répertoire de confiance
- Utiliser la vérification des failles
- Afficher les journaux CV