This page shows you how to use the Binary Authorization continuous validation (CV) simple signing attestation check. The check verifies the attestations of container images associated with Pods running in a Google Kubernetes Engine (GKE) cluster where CV is enabled.
Costs
This guide uses the following Google Cloud services:
- Binary Authorization, but CV is available free of charge during the Preview stage
- GKE
- Cloud Key Management Service
To generate a cost estimate based on your projected usage, use the pricing calculator.
Before you begin
- Sign in to your Google Cloud account. If you're new to Google Cloud, create an account to evaluate how our products perform in real-world scenarios. New customers also get $300 in free credits to run, test, and deploy workloads.
- 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.
-
-
Make sure that billing is enabled for your Google Cloud project.
-
Enable the Binary Authorization, Cloud Key Management Service, Google Kubernetes Engine APIs:
gcloud services enable binaryauthorization.googleapis.com
cloudkms.googleapis.com container.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.
-
-
Make sure that billing is enabled for your Google Cloud project.
-
Enable the Binary Authorization, Cloud Key Management Service, Google Kubernetes Engine APIs:
gcloud services enable binaryauthorization.googleapis.com
cloudkms.googleapis.com container.googleapis.com - Ensure that the gcloud CLI is updated to the latest version.
- Install the
kubectl
command-line tool. - If your Binary Authorization policies and GKE clusters are in different projects, make sure that Binary Authorization is enabled in both projects.
Required roles
This section shows you how to set roles for this check.
Overview
If you run all of the products that are mentioned in this guide in the same project, you don't need to set any permissions. Binary Authorization configures the roles correctly when you enable it. If you run the products in different projects, you must set roles as described in this section.
To ensure that the Binary Authorization Service Agent in each project has the necessary permissions to evaluate the CV simple signing attestation check, ask your administrator to grant the Binary Authorization Service Agent in each project the following IAM roles:
-
If your cluster project is different from the policy project:
Binary Authorization Policy Evaluator (
roles/binaryauthorization.policyEvaluator
) on the cluster project Binary Authorization Service Agent, for it to access the policy project -
If your attestation project is different from your policy project:
Container Analysis Occurrences Viewer (
roles/containeranalysis.occurrences.viewer
) on the policy project Binary Authorization Service Agent, for it to access the attestation project
For more information about granting roles, see Manage access to projects, folders, and organizations.
Your administrator might also be able to give the Binary Authorization Service Agent in each project the required permissions through custom roles or other predefined roles.
Grant roles using the gcloud CLI
To ensure that the Binary Authorization Service Agent in each project has the necessary permissions to evaluate the CV simple signing attestation check, grant the Binary Authorization Service Agent in each project the following IAM roles:
Grant permission for the cluster project's Binary Authorization Service Agent to access the policy in the policy project.
Get the cluster project's Binary Authorization service agent:
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"
Replace
CLUSTER_PROJECT_ID
with the project ID of the cluster.Allow CV to evaluate the policy on the cluster:
gcloud projects add-iam-policy-binding POLICY_PROJECT_ID \ --member="serviceAccount:$CLUSTER_SERVICE_ACCOUNT" \ --role='roles/binaryauthorization.policyEvaluator'
Replace
POLICY_PROJECT_ID
with the ID of the project that contains your policy.
Allow the policy project Binary Authorization Service Agent to access the attestations in your attestation project:
Obtain the policy project's Binary Authorization service agent:
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"
Replace
POLICY_PROJECT_ID
with the ID of the project that contains your policy.Grant the role:
gcloud projects add-iam-policy-binding ATTESTATION_PROJECT_ID \ --member="serviceAccount:$SERVICE_ACCOUNT" \ --role='roles/containeranalysis.occurrences.viewer'
Replace
ATTESTATION_PROJECT_ID
with the ID of the project that contains your attestations.
Create a key pair
In this section, you create an Elliptic Curve Digital Signature Algorithm (ECDSA) asymmetric key pair.
You use the private key to sign the image, which creates the attestation. You include the public key in a platform policy. When CV checks the attestation, it uses the public key to verify the attestation.
You can use either Cloud Key Management Service or local keys, but we recommend that you use Cloud KMS keys for production.
PKIX Cloud KMS
To create the key pair in Cloud KMS, do the following:
Set up environment variables needed to create the key pair. To do so, we recommend that you fill in the placeholders in the following command, and then run the command.
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 KEY_FILE=KEY_FILE
Replace the following:
KMS_KEY_PROJECT_ID
: your project IDKMS_KEYRING_NAME
: a name for your Cloud KMS key ringKMS_KEY_NAME
: a name for your Cloud KMS keyKEY_FILE
: a local path to save your Cloud KMS key
Create the key ring:
gcloud kms keyrings create ${KMS_KEYRING_NAME} \ --location=${KMS_KEY_LOCATION} \ --project=${KMS_KEY_PROJECT_ID}
Create the key:
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}
Export the public key material to a file:
gcloud kms keys versions get-public-key ${KMS_KEY_VERSION} \ --key=${KMS_KEY_NAME} \ --keyring=${KMS_KEYRING_NAME} \ --location=${KMS_KEY_LOCATION} \ --output-file=${KEY_FILE} \ --project=${KMS_KEY_PROJECT_ID}
Local key
To create the key pair locally, do the following:
Create the private key:
PRIVATE_KEY_FILE="/tmp/ec_private.pem" openssl ecparam -genkey -name prime256v1 -noout -out ${PRIVATE_KEY_FILE}
Get the public key from the private key:
PUBLIC_KEY_FILE="/tmp/ec_public.pem" openssl ec -in ${PRIVATE_KEY_FILE} -pubout -out ${PUBLIC_KEY_FILE}
Create a platform policy
To create a CV platform policy with a simple signing attestation check, do the following:
Create the simple signing attestation check platform policy YAML file:
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}' ${KEY_FILE}) 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
Replace
ATTESTATION_PROJECT_ID
with the ID of the project that stores attestations that are created using this Cloud KMS key.Local key
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
Replace the following:
ATTESTATION_PROJECT_ID
: the ID of the project that stores attestations that are created using your local keyPUBLIC_KEY_ID
: an ID that uniquely identifies your local key
Create the platform policy:
Before using any of the command data below, make the following replacements:
- POLICY_ID: A platform policy ID
of your choice. If the policy is in another project, you can use the full resource name:
projects/POLICY_PROJECT_ID/platforms/gke/policies/POLICY_ID
. - POLICY_PATH: A path to the policy file.
- POLICY_PROJECT_ID: The policy project ID.
Execute the following command:
Linux, macOS, or 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: A platform policy ID
of your choice. If the policy is in another project, you can use the full resource name:
Store the ID value for later use:
PUBLIC_KEY_ID="PUBLIC_KEY_ID"
Replace
PUBLIC_KEY_ID
with the ID that you specified in thekeyId
field in the platform policy file earlier in this guide.The private key is used when attestations are created, as described later in this guide.
Enable CV
You can create a new cluster or update an existing cluster to use CV monitoring with check-based platform policies.
Create a cluster that uses CV monitoring
In this section, you create a cluster that uses only CV monitoring with check-based platform policies.
Before using any of the command data below, make the following replacements:
CLUSTER_NAME
: a cluster name.LOCATION
: the location—for example,us-central1
orasia-south1
.POLICY_PROJECT_ID
: the ID of the project where the policy is stored.POLICY_ID
: the policy ID.CLUSTER_PROJECT_ID
: the cluster project ID.
Execute the following command:
Linux, macOS, or 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
Create cluster that uses enforcement and CV monitoring
In this section, you create a cluster that uses both project-singleton policy enforcement and CV monitoring with check-based platform policies:
Before using any of the command data below, make the following replacements:
CLUSTER_NAME
: a cluster name.LOCATION
: the location—for example,us-central1
orasia-south1
.POLICY_PROJECT_ID
: the ID of the project where the policy is stored.POLICY_ID
: the policy ID.CLUSTER_PROJECT_ID
: the cluster project ID.
Execute the following command:
Linux, macOS, or 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
Update a cluster to use CV monitoring
In this section, you update a cluster to use CV monitoring with check-based platform policies only. If the cluster already has project-singleton policy enforcement enabled, running this command disables it. Instead, consider updating the cluster with enforcement and CV monitoring enabled.
Before using any of the command data below, make the following replacements:
CLUSTER_NAME
: the cluster nameLOCATION
: the location—for example:us-central1
orasia-south1
POLICY_PROJECT_ID
: the ID of the project where the policy is storedPOLICY_ID
: the policy IDCLUSTER_PROJECT_ID
: the cluster project ID
Execute the following command:
Linux, macOS, or 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
Update a cluster to use enforcement and CV monitoring
In this section, you update a cluster to use both project-singleton policy enforcement and CV monitoring with check-based platform policies.
Before using any of the command data below, make the following replacements:
CLUSTER_NAME
: a cluster nameLOCATION
: the location—for example:us-central1
orasia-south1
POLICY_PROJECT_ID
: the ID of the project where the policy is storedPOLICY_ID
: the policy IDCLUSTER_PROJECT_ID
: the cluster project ID
Execute the following command:
Linux, macOS, or 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
Create the Artifact Analysis note
In this section, you create an example Artifact Analysis note to link attestations. To create the note, do the following:
Create the note variables:
NOTE_PROJECT_ID=NOTE_PROJECT_ID NOTE_ID="test-note" NOTE_URI="projects/${NOTE_PROJECT_ID}/notes/${NOTE_ID}" DESCRIPTION="CV test note"
Replace
NOTE_PROJECT_ID
: the ID of the project that contains the note.Create the note content file:
cat > /tmp/note_payload.json << EOM { "name": "${NOTE_URI}", "attestation": { "hint": { "human_readable_name": "${DESCRIPTION}" } } } EOM
Create the 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}"
Replace
NOTE_PROJECT_ID
: the ID of the project that contains the noteOptional: To verify that you created the note:
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/"
Replace
NOTE_PROJECT_ID
with the ID of the project that contains the note.
Test CV
In this section, you test CV by deploying the image for which you created an attestation. In this case, the CV simple signing attestation check verifies the attestation and produces no log entry.
You then attempt to deploy a different image that has no attestation. In this case, the CV check can't find the attestation and logs the violation to Cloud Logging.
To create the variables you use to test CV, run the following commands:
IMAGE_PATH="us-docker.pkg.dev/google-samples/containers/gke/hello-app"
IMAGE_DIGEST="sha256:37e5287945774f27b418ce567cd77f4bbc9ef44a1bcd1a2312369f31f9cce567"
IMAGE_TO_ATTEST="${IMAGE_PATH}@${IMAGE_DIGEST}"
Create an attestation
To satisfy the simple signing attestation check, the image needs a valid attestation.
You can create an attestation using the gcloud CLI or the REST API.
PKIX Cloud KMS
gcloud
To create an attestation using the gcloud CLI, do the following:
Sign the image and create the attestation using Pre-Authentication Encoding (PAE) (recommended):
gcloud beta container binauthz attestations sign-and-create \ --artifact-url=${IMAGE_TO_ATTEST} \ --keyversion=${KMS_KEY_VERSION} \ --keyversion-key=${KMS_KEY_NAME} \ --keyversion-keyring=${KMS_KEYRING_NAME} \ --keyversion-location=${KMS_KEY_LOCATION} \ --note=${NOTE_URI} \ --pae-encode-payload \ --dsse-type=DSSE_TYPE
Replace
DSSE_TYPE
with the DSSE type for PAE encoding. The flag defaults toapplication/vnd.dev.cosign.simplesigning.v1+json
.
REST API
To create an attestation using the REST API, do the following:
Create a signature payload file:
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
Sign the payload:
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}
Create the attestation content:
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
Create the 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
Replace
NOTE_PROJECT_ID
with the ID of the project that contains the note.
Local key
gcloud
Create a signature payload file:
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
Create the signature payload file:
openssl dgst -sha256 -sign ${PRIVATE_KEY_FILE} /tmp/generated_payload.json > /tmp/ec_signature
Create the attestation:
gcloud container binauthz attestations create \ --project=ATTESTATION_PROJECT_ID \ --artifact-url=${IMAGE_TO_ATTEST} \ --note=${NOTE_URI} \ --signature-file=/tmp/ec_signature \ --public-key-id=PUBLIC_KEY_ID
REST API
Create a signature payload file:
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
Create the signature payload file:
openssl dgst -sha256 -sign ${PRIVATE_KEY_FILE} /tmp/generated_payload.json > /tmp/ec_signature
Create the attestation content:
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
Create the 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
Deploy the image that has an attestation
To deploy an image for which an attestation was created, do the following:
Configure
kubectl
:gcloud container clusters get-credentials CLUSTER_NAME \ --location=LOCATION \ --project=CLUSTER_PROJECT_ID
Replace the following:
CLUSTER_NAME
: the name of your clusterLOCATION
: the cluster locationCLUSTER_PROJECT_ID
: the cluster project ID
Deploy a service and check the deployment against the Binary Authorization policy:
kubectl run hello-app-with-attestation --image=$IMAGE_PATH@$IMAGE_DIGEST
The Pod was deployed. Because the image has an attestation, CV doesn't produce log entries related to this Pod.
Deploy an image without an attestation
In this section, you deploy an image that doesn't have an associated attestation.
Because the policy requires attestations and this image doesn't have one, CV regularly logs the violation while the container is running.
To deploy the image, run the following command:
kubectl run hello-app-without-attestation \
--image=gcr.io/google-samples/hello-app@sha256:845f77fab71033404f4cfceaa1ddb27b70c3551ceb22a5e7f4498cdda6c9daea
The Pod was deployed. Because the image doesn't have an attestation, CV produces log entries while the Pod is running.
View logs for CV entries
You can search Cloud Logging entries to find CV configuration errors and CV platform policy validation violations.
CV logs errors and violations to Cloud Logging within 24 hours. You can usually see entries within a few hours.
View CV configuration error logs
To view CV configuration error logs, run the following command:
gcloud logging read \
--order="desc" \
--freshness=7d \
--project=CLUSTER_PROJECT_ID \
'logName:"binaryauthorization.googleapis.com%2Fcontinuous_validation" "configErrorEvent"'
The following output shows a configuration error in which a CV platform policy isn't found:
{
"insertId": "141d4f10-72ea-4a43-b3ec-a03da623de42",
"jsonPayload": {
"@type": "type.googleapis.com/google.cloud.binaryauthorization.v1beta1.ContinuousValidationEvent",
"configErrorEvent": {
"description": "Cannot monitor cluster 'us-central1-c.my-cluster': Resource projects/123456789/platforms/gke/policies/my-policy does not exist."
}
},
"resource": {
"type": "k8s_cluster",
"labels": {
"cluster_name": "my-cluster",
"location": "us-central1-c",
"project_id": "my-project"
}
},
"timestamp": "2024-05-28T15:31:03.999566Z",
"severity": "WARNING",
"logName": "projects/my-project/logs/binaryauthorization.googleapis.com%2Fcontinuous_validation",
"receiveTimestamp": "2024-05-28T16:30:56.304108670Z"
}
View CV platform policy validation violations
If no images violate the platform policies that you have enabled, no entries appear in the logs.
To view CV log entries for the last seven days, run the following command:
gcloud logging read \
--order="desc" \
--freshness=7d \
--project=CLUSTER_PROJECT_ID \
'logName:"binaryauthorization.googleapis.com%2Fcontinuous_validation" "policyName"'
Replace CLUSTER_PROJECT_ID
with the cluster project ID.
Check types
CV logs check violation information to checkResults
. In the
entry, the value checkType
indicates the check. The values for each check are
as follows:
ImageFreshnessCheck
SigstoreSignatureCheck
SimpleSigningAttestationCheck
SlsaCheck
TrustedDirectoryCheck
VulnerabilityCheck
Example log
The following example CV Logging entry describes a non-conformant image that violates a trusted directory check:
{
"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"
}
Clean up
This section describes how to clean up the CV monitoring you configured earlier in this guide.
You can disable CV monitoring or both Binary Authorization and CV in your cluster.
Disable Binary Authorization in a cluster
To disable both CV and Binary Authorization enforcement in your cluster, run the following command:
gcloud beta container clusters update CLUSTER_NAME \
--binauthz-evaluation-mode=DISABLED \
--location=LOCATION \
--project=CLUSTER_PROJECT_ID
Replace the following:
CLUSTER_NAME
: the name of the clusterLOCATION
: the cluster locationCLUSTER_PROJECT_ID
: the cluster project ID
Disable check-based policy monitoring in a cluster
To disable CV with check-based policies in the cluster, and re-enable enforcement using the Binary Authorization enforcement policy, run the following command:
gcloud beta container clusters update CLUSTER_NAME \
--binauthz-evaluation-mode=PROJECT_SINGLETON_POLICY_ENFORCE \
--location=LOCATION \
--project="CLUSTER_PROJECT_ID"
Replace the following:
CLUSTER_NAME
: the name of the clusterLOCATION
: the cluster locationCLUSTER_PROJECT_ID
: the cluster project ID
Note that --binauthz-evaluation-mode=PROJECT_SINGLETON_POLICY_ENFORCE
is
equivalent to the older flag --enable-binauthz
.
Delete the policy
To delete the policy, run the following command. It is not necessary to delete the check-based platform policy to disable check-based policy auditing.
gcloud beta container binauthz policy delete POLICY_ID \
--platform=gke \
--project="POLICY_PROJECT_ID"
Replace the following:
POLICY_ID
: the ID of the policyPOLICY_PROJECT_ID
: the policy project ID
What's next
- Use the image freshness check
- Use the simple signing attestation check
- Use the Sigstore signature check
- Use the SLSA check
- Use the trusted directory check
- Use the vulnerability check
- View CV logs