Google Cloud CD Mitigation

Google Cloud CD Mitigation adds near-real-time protection for container images in Google Artifact Registry when used with Binary Authorization and Google Cloud Run, and with other deployment paths that honor your project Binary Authorization policy.

This topic is based on the App Analyzer onboarding assets, including Terraform and scripts, customer-deployed Cloud Functions in the downloadable bundle, and the prevasio-cd-mitigation backend handlers and lockers.

Overview

  • Problem it solves: Scheduled container scans run on a fixed cadence. A risky image pushed between scans could still be deployed. CD Mitigation reacts when Google publishes a registry event for a new image, triggers an on-demand scan, and, depending on your mitigation rules, can remove the cryptographic attestation that Binary Authorization expects so deploy-time policy can block workloads that depend on that image.

  • Difference from the daily container scan: The daily scan is batch and account-wide. CD Mitigation is event-driven and starts when Artifact Registry reports a relevant image action through the gcr Pub/Sub topic integration.

  • When it is triggered: On INSERT image-push flows that reach the events forwarder, and when messages are published for attestation processing. The backend also processes DELETE events for reporting cleanup.

  • What mitigation means: Mitigation uses Binary Authorization attestations stored in Container Analysis. If the scan outcome should block the image, the service deletes Prevasio-created attestations for that image so policy evaluation fails. If the outcome is passed, the flow can re-create an attestation. This is deploy-time enforcement through Binary Authorization, not a universal block on every docker pull in every context.

How Google Cloud CD Mitigation works

In your Google Cloud project

  • Artifact Registry publishes notifications to a Pub/Sub topic named gcr, which is created if missing. A push subscription delivers messages to the HTTPS endpoint on the Cloud Functions Gen2 function prevasio-<hash>-events-forwarder.

  • The events forwarder decodes the message. On INSERT, it publishes the image digest to prevasio-<hash>-images-to-sign and calls App Analyzer over HTTPS at .../prevasio/api/v1/events/images with a Bearer token from AlgoSec, using credentials stored in Secret Manager.

  • A push subscription on prevasio-<hash>-images-to-sign invokes prevasio-<hash>-image-attestation-creator, which signs a payload with Cloud KMS and creates a Container Analysis occurrence tied to your Binary Authorization attestor.

  • Cloud Scheduler runs every six hours and invokes prevasio-<hash>-cloud-run-scanner, which sets Cloud Run services and jobs to use the project default Binary Authorization policy where needed.

In AlgoSec / App Analyzer

  • The API Gateway listener receives the JSON body, resolves the tenant and mitigation configuration, and GcpProcessor enqueues an on-demand sandbox scan, including GCP credentials so the scanner can pull and analyze the image.

  • When the scan completes, sandbox_event_listener loads mitigation results from tenant S3 at gcp/<organization>/<project>/images/<hash>.json. If the status is blocked, it may enqueue a lock to GcpARLocker, which deletes matching Prevasio attestations. If passed, it may enqueue unlock to re-create attestations. Optional email notifications use Amazon SES.

Trust boundaries: Registry events and secrets stay in your project until the forwarder posts event metadata to App Analyzer. Image layers are not sent in the Pub/Sub JSON. The scanner uses credentials from onboarding to access the image from AlgoSec’s pipeline.

Where enforcement happens: Enforcement happens through Binary Authorization at deploy time, such as in Cloud Run or GKE when policy is enforced. App Analyzer changes the attestations your policy trusts.

What gets deployed in your Google Cloud project

Resource Purpose Category
Enabled APIs Enable Artifact Registry, Binary Authorization, Cloud Build, Cloud Functions, KMS, Scheduler, Compute, Container Analysis, Pub/Sub, Cloud Run, Secret Manager, and related APIs Prerequisite
Container Analysis note
prevasio-<hash>-note		 Acts as the anchor for attestations Policy
KMS key ring
prevasio-attestor-keyring and key prevasio-attestor-key		 Signs attestations Crypto
Binary Authorization
attestor prevasio-<hash>-attestor		 Acts as the trust anchor for policy enforcement Policy
Binary Authorization policy update Adds the attestor to the default admission rule with REQUIRE_ATTESTATION and ENFORCED_BLOCK_AND_AUDIT_LOG Policy
Secret Manager secrets Store organization ID, App Analyzer host, OAuth client JSON, and AlgoSec cloud host Credentials
Pub/Sub topic gcr Ingests Artifact Registry notifications Event
Pub/Sub topic
prevasio-<hash>-images-to-sign		 Queues digests for attestation Event
Subscriptions gcr to events forwarder, and images-to-sign to image attestation creator Event
GCS bucket <hash>-functions-source Stores deployment ZIP files and deletes objects after 30 days through a lifecycle rule Build
Cloud Functions Gen2 Deploys events-forwarder, image-attestation-creator, and cloud-run-scanner Execution
Cloud Scheduler Invokes cloud-run-scanner every six hours Scheduling

Scope: Regional settings use GCP_REGION from onboarding. The KMS key ring is global. The gcr topic is project-scoped, and the integration follows Google’s Artifact Registry notification model.

Required permissions and why they are needed

  • App Analyzer container roles, according to the desired-state reference, include roles/binaryauthorization.policyEditor, roles/containeranalysis.occurrences.editor, roles/containeranalysis.notes.attacher, and roles/cloudkms.signer, in addition to broader discovery roles. See your permissions documentation for the full list.

  • Resources created in the project grant the default compute service account Cloud Build builder, Secret Manager accessor on the CD Mitigation secrets, Pub/Sub publisher on images-to-sign, KMS signer on the attestor key, and note IAM permissions for the Binary Authorization service agent.

  • Runtime lock check: The backend verifies through testIamPermissions that containeranalysis.occurrences.list, containeranalysis.occurrences.delete, and containeranalysis.occurrences.create are granted. Without them, locking is skipped. Notifications may still be sent if configured.

End-to-end event flow

  1. An image push completes in Artifact Registry.

  2. Google delivers a notification to the gcr topic in the customer project.

  3. The push subscription invokes events-forwarder in the customer project.

  4. On INSERT, the forwarder publishes to images-to-sign and posts the event JSON to App Analyzer over HTTPS.

  5. image-attestation-creator creates an attestation occurrence using KMS in the customer project.

  6. App Analyzer queues a sandbox scan, and the results are written to S3 under your tenant.

  7. sandbox_event_listener reads the results. If the image is blocked and locking is allowed, GcpARLocker deletes Prevasio attestations. If the image passes, unlock may re-create attestations.

  8. Binary Authorization enforces policy when workloads are deployed by the Google control plane.

Needs validation: There may be an interval in which an image is attested before the scan completes, because the code initiates attestation and scanning in parallel for new pushes. Confirm whether this fits your risk tolerance.

Security and data handling considerations

  • Event-driven processing uses Pub/Sub, HTTP, and Scheduler. It does not rely on a continuous registry polling loop for this feature.

  • Data leaving the project in the hot path: The forwarder sends registry event metadata to App Analyzer over HTTPS with a short-lived Bearer token. It does not send image layers in that post.

  • Image contents: Scanning uses a separate pipeline with digest and credentials in internal queues. Retention and caching of scan artifacts still need validation.

  • Secrets: OAuth client material is stored in Secret Manager and read by the configured service account.

  • GCS bucket for function ZIP files: Objects may be deleted after 30 days according to the lifecycle rule.

Prerequisites and limitations

  • Prerequisites: Required APIs must be enabled, App Analyzer GCP onboarding must be completed successfully with the downloadable function bundle, and mitigation settings must be configured in App Analyzer if you want locking and email notifications.

  • Limitations: Cloud Run scanner runs every six hours, not on every push. Functions are deployed to GCP_REGION, the KMS key ring is global, and Binary Authorization policy is project-scoped.

  • Failure behavior: If the forwarder cannot authenticate or post events, near-real-time scanning for that push may not run. Scheduled scans may still apply, but alerting behavior still needs validation. If lock permissions are missing, locking is skipped, while email may still be sent if configured.

Troubleshooting and operational notes

  • Cloud Logging for Cloud Functions can help identify authentication failures, HTTP errors to App Analyzer, and stack traces.

  • Pub/Sub: Confirm that the gcr topic exists and that subscriptions show healthy delivery.

  • Binary Authorization and Container Analysis: Incorrect policy or attestations can broadly block deployments or unexpectedly allow them.

  • Offboarding: Use your organization’s GCP offboarding process. The exact checklist still needs validation.