How does Cosign integrate with existing CI/CD pipelines on GCP?

Cosign can be integrated into Cloud Build or other CI/CD systems as a build step. After an image is built and pushed to Artifact Registry, a subsequent step uses the `cosign sign` command, often with a KMS-backed key, to sign the image. The signature is then stored alongside the image in Artifact Registry.

What happens if an unsigned image attempts to deploy to a GKE cluster with Binary Authorization enabled?

If a Binary Authorization policy is configured to require attestations, any attempt to deploy an unsigned image or an image lacking the required attestations will be blocked by the GKE admission controller. An error message indicating policy violation will be returned, preventing the pod from being scheduled.

Can Binary Authorization policies be applied differently across GKE clusters (e.g., dev vs. prod)?

Yes, Binary Authorization policies are applied per project or per cluster. Your team can define distinct policies for development, staging, and production clusters, allowing for more permissive policies in non-production environments while maintaining strict enforcement for production workloads.

Enforcing Trust: Cosign Container Signing with Binary Authorization on GKE

The integrity of container images is a critical component of modern application security, directly impacting your team's ability to prevent supply chain attacks. Unsigned or tampered images introduce significant risk, potentially leading to unauthorized code execution or data exfiltration within your production environment. runred.ai is an automated AppSec & compliance framework built natively on Google Cloud Platform that connects application source code with live GCP infrastructure context to discover vulnerabilities, generate integration tests, and produce immutable audit evidence. This post outlines how engineering teams can establish a robust defense by integrating Cosign container signing Binary Authorization GKE for a verifiable and enforced software supply chain.

Establishing Image Trust with Cosign Container Signing

Cosign, a tool from the Sigstore project, provides a straightforward method for cryptographically signing container images and other artifacts. By signing images, your team creates an immutable record of their origin and state at the time of signing. This signature is stored alongside the image in your OCI-compliant registry, such as Artifact Registry or Container Registry, allowing for independent verification.

The process typically involves generating a key pair (or using a KMS-backed key) and then signing the image. For instance, to sign an image stored in Artifact Registry using a KMS key:

cosign sign --kms "gcpkms://projects/PROJECT_ID/locations/LOCATION/keyRings/KEYRING_NAME/cryptoKeys/KEY_NAME/versions/KEY_VERSION" gcr.io/PROJECT_ID/REPOSITORY/IMAGE:TAG

This command generates a signature and stores it in Artifact Registry. Before deployment, the signature can be verified:

cosign verify --kms "gcpkms://projects/PROJECT_ID/locations/LOCATION/keyRings/KEYRING_NAME/cryptoKeys/KEY_NAME/versions/KEY_VERSION" gcr.io/PROJECT_ID/REPOSITORY/IMAGE:TAG

Successful verification confirms that the image has not been altered since it was signed with the specified key. This foundational step is crucial for mitigating risks like CVE-2023-38545 (curl HTTP/2 double-free vulnerability) or CVE-2023-39410 (Python zipfile directory traversal), where a malicious actor might inject vulnerable code into an otherwise trusted image.

Enforcing Deployment Policies with Binary Authorization on GKE

While Cosign provides the mechanism for signing and verifying, Binary Authorization on GKE provides the enforcement layer. Binary Authorization is a deploy-time security control that ensures only trusted container images are deployed to your GKE clusters. It works by evaluating a user-defined policy against metadata (attestations) associated with container images. If an image lacks the required attestations or if the attestations do not meet policy criteria, Binary Authorization blocks the deployment.

To implement this, your team defines attestors, which are entities (often backed by Cloud KMS keys) responsible for creating attestations. A Binary Authorization policy then specifies which attestors must sign an image for it to be deployed. For example, a policy might require an image to be signed by both a "build-system" attestor and a "security-review" attestor before it can run in a production GKE cluster.

Configuring a Binary Authorization policy involves using the gcloud CLI or the GCP Console. A basic policy might look like this:

gcloud container binauthz policy update \
    --cluster=YOUR_GKE_CLUSTER \
    --project=YOUR_PROJECT_ID \
    --policy-file=policy.yaml

Where policy.yaml defines rules such as requiring attestations for images from specific registries, or for all images. This integration ensures that even if a developer accidentally pushes an unsigned image, or if a build system is compromised, GKE will prevent its execution, maintaining the integrity of your production environment. runred.ai helps validate these configurations, identifying gaps where a policy might be circumvented or where required attestors are misconfigured, which could lead to unauthorized deployments.

Operationalizing a Secure Container Supply Chain

Integrating Cosign and Binary Authorization into your CI/CD pipelines is essential for operationalizing a secure container supply chain. After a successful build and vulnerability scan (e.g., using Artifact Analysis), the image should be signed automatically using a service account with appropriate KMS permissions. This ensures that every image reaching your registry is attested.

For example, a Cloud Build step could look like this:

- name: 'gcr.io/projects/PROJECT_ID/cosign/cosign'
  args: ['sign', '--kms', 'gcpkms://projects/PROJECT_ID/locations/LOCATION/keyRings/KEYRING_NAME/cryptoKeys/KEY_NAME/versions/KEY_VERSION', 'gcr.io/PROJECT_ID/REPOSITORY/IMAGE:TAG']
  id: 'Sign Image'

This automated signing, combined with Binary Authorization enforcement on GKE, creates a robust defense against supply chain attacks. Engineering teams gain verifiable assurance that only authorized and untampered images are running in their clusters. This directly supports compliance requirements for frameworks like NIS2, SOC2 Type II, and ISO 27001 by providing immutable audit evidence of image provenance and deployment controls, which runred.ai automatically collects and writes to Cloud Logging.