This tutorial shows how to configure and test a Binary Authorization policy that requires attestations. This type of policy secures your container-based software supply chain by verifying that a container image has a signed attestation before allowing deployment of the image.
At deploy time, Binary Authorization uses attestors to verify digital signatures in attestations. The attestations are created by signers, usually as part of a continuous integration (CI) pipeline.
In this tutorial, the GKE cluster, attestations, and attestors are all located in a single project. A single-project configuration is mostly useful for testing or experimenting with the service. For a more real-world example, see multi-project configuration.
The following steps describe tasks that you perform at the command line. To follow these steps using Google Cloud console, see Get started using the Google Cloud console.
Objectives
In this tutorial, you do the following:
- Create a Google Kubernetes Engine (GKE) cluster with Binary Authorization enabled
- Create an attestor that the Binary Authorization enforcer uses to verify the signature on an attestation
- Configure a policy that requires an attestation
- Create a cryptographic key pair to sign attestations and later verify them
- Sign a container image digest, creating a signature
- Create an attestation using the signature
- Test the policy by deploying a container image to GKE
Costs
In this document, you use the following billable components of Google Cloud:
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.
-
In the Google Cloud console, on the project selector page, select or create a Google Cloud project.
Roles required to select or create a project
- Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
-
Create a project: To create a project, you need the Project Creator role
(
roles/resourcemanager.projectCreator), which contains theresourcemanager.projects.createpermission. Learn how to grant roles.
-
Verify that billing is enabled for your Google Cloud project.
-
Install the Google Cloud CLI.
-
If you're using an external identity provider (IdP), you must first sign in to the gcloud CLI with your federated identity.
-
To initialize the gcloud CLI, run the following command:
gcloud init -
In the Google Cloud console, on the project selector page, select or create a Google Cloud project.
Roles required to select or create a project
- Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
-
Create a project: To create a project, you need the Project Creator role
(
roles/resourcemanager.projectCreator), which contains theresourcemanager.projects.createpermission. Learn how to grant roles.
-
Verify that billing is enabled for your Google Cloud project.
-
Install the Google Cloud CLI.
-
If you're using an external identity provider (IdP), you must first sign in to the gcloud CLI with your federated identity.
-
To initialize the gcloud CLI, run the following command:
gcloud init - Install
kubectlfor interacting with GKE.
Enable Binary Authorization
Before you use Binary Authorization, set your default project and enable the required Google Cloud APIs.
Set the default project
The first step is to set the default Google Cloud project used by the
gcloud command:
PROJECT_ID=PROJECT_ID
gcloud config set project ${PROJECT_ID}
Replace PROJECT_ID with the name of your project.
Enable required APIs
Enable the following APIs:
Artifact Registry
gcloud --project=${PROJECT_ID} \
services enable\
container.googleapis.com\
artifactregistry.googleapis.com\
binaryauthorization.googleapis.com
Create a cluster with Binary Authorization enabled
To set up your Kubernetes environment, create a cluster with Binary Authorization
enabled and configure kubectl to interact with it.
Create the cluster
Create a GKE cluster with Binary Authorization
enabled. This is the cluster where you want your deployed container images to
run. When you create the cluster, you pass the --binauthz-evaluation-mode=PROJECT_SINGLETON_POLICY_ENFORCE flag to the
gcloud container clusters create command.
To create the cluster, follow these steps:
gcloud container clusters create \
--binauthz-evaluation-mode=PROJECT_SINGLETON_POLICY_ENFORCE \
--zone us-central1-a \
test-cluster
Here, you create a cluster named test-cluster in the
GKE zone us-central1-a.
Configure kubectl
You must also update the local kubeconfig file for your kubectl
installation. This provides the credentials and endpoint information required to
access the cluster in GKE.
To update the local kubeconfig file, run the following command:
gcloud container clusters get-credentials \
--zone us-central1-a \
test-cluster
View the default policy
A policy in Binary Authorization is a set of rules that govern the deployment of container images. You can have one policy per project. By default, the policy is configured to allow all container images to be deployed.
Binary Authorization lets you export and import a policy file in
YAML format. This format reflects the structure of a policy as it is stored by
the service. When you configure a policy using gcloud commands, you edit this
file.
To view the default policy, export the policy YAML file:
gcloud container binauthz policy export
By default, the file has the following contents:
defaultAdmissionRule: enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG evaluationMode: ALWAYS_ALLOW globalPolicyEvaluationMode: ENABLE name: projects/PROJECT_ID/policy
The default rule is defined in the defaultAdmissionRule
node. evaluationMode specifies that
the policy allows all attempts at image deployment. In this tutorial, you update
the default rule to require attestations.
globalPolicyEvaluationMode
exempts Google-managed system images from Binary Authorization enforcement.
To add an exempt image to the allowlist, add the following to the policy file:
admissionWhitelistPatterns: - namePattern: EXEMPT_IMAGE_PATH
Replace EXEMPT_IMAGE_PATH with the path to am image to exempt. To exempt additional images, add additional - namePattern entries. Learn more about admissionWhitelistPatterns.
For more information on the structure of a policy, see the Policy YAML reference.
Create an attestor
An attestor is the verification authority that the Binary Authorization enforcer uses at deploy time to decide whether to allow GKE to deploy the corresponding signed container image. The attestor contains the public key and is typically managed by personnel in your organization who are responsible for software supply chain security.
To create an attestor, follow these steps:
- Create a note in Artifact Analysis to store trusted metadata used in the authorization process.
- Create the attestor itself in Binary Authorization and associate the note you created.
For this tutorial, you have one attestor named test-attestor and a
Artifact Analysis note named test-attestor-note. In a real-world
scenario, you can have any number of attestors, each one representing a party
that participates in the authorization process for a container image.
Create the Artifact Analysis note
Set variables that store the name of your attestor and Artifact Analysis note:
ATTESTOR_NAME=test-attestor NOTE_ID=test-attestor-note
Replace the following:
- test-attestor: attestor name of your choice.
- attestor-note: attestor note name of your choice.
Create a JSON file in
/tmp/note_payload.jsonthat describes the Artifact Analysis note:cat > /tmp/note_payload.json /tmp/policy.yaml /tmp/generated_payload.json
The payload JSON file has the following contents:
{ "critical": { "identity": { "docker-reference": "us-docker.pkg.dev/google-samples/containers/gke/hello-app" }, "image": { "docker-manifest-digest": "sha256:c62ead5b8c15c231f9e786250b07909daf6c266d0fcddd93fea 882eb722c3be4" }, "type": "Google cloud binauthz container signature" } }To sign the payload with your PKIX private key and generate a signature file, run the following command:
openssl dgst -sha256 -sign ${PRIVATE_KEY_FILE} /tmp/generated_payload.json > /tmp/ec_signatureThe signature file is the signed version of the payload JSON file you created earlier in this guide.
Create and validate the attestation:
gcloud container binauthz attestations create \ --project="${PROJECT_ID}" \ --artifact-url="${IMAGE_TO_ATTEST}" \ --attestor="projects/${PROJECT_ID}/attestors/${ATTESTOR_NAME}" \ --signature-file=/tmp/ec_signature \ --public-key-id="${PUBLIC_KEY_ID}" \ --validateReplace
PUBLIC_KEY_IDwith the public key ID that you found in Generate a key pair.The
validateflag checks that the attestation can be verified by the attestor you configured in your policy.
Verify that the attestation was created:
gcloud container binauthz attestations list \
--attestor=$ATTESTOR_NAME --attestor-project=$PROJECT_ID
For more information about creating attestations, see Creating Attestations.
Retest the policy
Again, test the policy by deploying a sample container image to the cluster.
This time, you must deploy the image using the digest rather than a tag like
1.0 or latest, as Binary Authorization will use the digest to look up
attestations. Here, Binary Authorization allows the image to be deployed because
the required attestation has been made.
To deploy the image, follow these steps:
Deploy the image:
kubectl run hello-server --image ${IMAGE_TO_ATTEST} --port 8080Verify that the image was deployed:
kubectl get pods
The command prints a message similar to the following, which indicates that deployment was successful:
NAME READY STATUS RESTARTS AGE hello-server-579859fb5b-h2k8s 1/1 Running 0 1m
Clean up
To avoid incurring charges to your Google Cloud account for the resources used in this tutorial, either delete the project that contains the resources, or keep the project and delete the individual resources.
Delete the cluster that you created in GKE:
gcloud container clusters delete \
--zone=us-central1-a \
test-cluster