Deployment Auditing with Artifact Registry and Audit Logs

Artifact provenance and security scanning in Artifact Registry is the system that proves where a container image came from and whether it is safe to promote. Artifact Analysis extracts package inventory from each new image and records vulnerabilities as metadata, while Artifact guard (opens in a new tab) evaluates those images against centralized policies during build, registry storage, and runtime. Binary Authorization then enforces the registry decision by blocking non-compliant images from deploying to Google Kubernetes Engine (GKE).

1.1Enable scanning for repositories

Enabling scanning for Artifact Registry repositories requires both project-level APIs and repository-level settings. First, an identity needs the serviceusage.services.enable permission through the Owner role (roles/owner) or Service Usage Admin role (roles/serviceusage.serviceUsageAdmin) to enable the Artifact Registry and Container Scanning APIs. When the Artifact Analysis API is enabled, Artifact Analysis begins scanning new images as they are pushed to Artifact Registry repositories in the project, but scanning remains disabled by default for packages pushed to repositories until scanning is enabled for the individual repository.

Viewing scan results requires read access to both the registry and the scan metadata:

• Artifact Registry Reader (roles/artifactregistry.reader) for repository access
• Container Analysis Occurrences Viewer (roles/containeranalysis.occurrences.viewer) for vulnerability findings
• Container Analysis Notes Viewer (roles/containeranalysis.notes.viewer) for vulnerability definitions
• Container Scanner Service Agent (roles/containerscanning.ServiceAgent) for the scanning service

Runtime environments are preconfigured with access to repositories in the same project. Cross-project pulls, custom service accounts, or workflows that need both upload and download require explicit Identity and Access Management (IAM) grants and review of VM access scopes.

1.2Analyze vulnerability findings and scan lifecycle

Vulnerability analysis in Artifact Analysis turns image contents into trackable occurrences that show package-level risk per image digest. A scan extracts information about packages in the container when the image is uploaded, and totals for each digest appear in the Vulnerabilities column in the Google Cloud console. Findings can be viewed in the console, Google Cloud CLI, or Container Analysis API, and developers can follow a digest link to obtain CVE details for remediation and audit.

Scan metadata in Artifact Analysis follows an active-to-stale-to-archived lifecycle driven by image pulls. The service continues to refresh scans as long as the image has been pulled within the last 30 days. After 30 days without a pull, metadata stops updating and results become stale. Metadata that has been stale for more than 90 days becomes archived and can be evaluated only by using the API. Pulling an image with stale or archived metadata triggers a re-scan, refreshing metadata within up to 24 hours, while packages with stale or archived metadata cannot be rescanned on their own.

To inspect findings in the console, follow this ordered flow from repository to digest to vulnerability list:

1. Open repositories: Open the Repositories page and select the Artifact Registry repository as the source container.
2. Open image: Click the image name in the images list to expose per-digest totals in the Vulnerabilities column.
3. Open digest findings: Click the link in the Vulnerabilities column to flow from the digest to its detailed vulnerability occurrences.

1.3Enforce promotion and deployment policy with Artifact guard

Artifact guard is the Security Command Center service that evaluates container images against centralized vulnerability policies across the container lifecycle. A policy controls promotion with peer rules that work together:

• Block artifacts that exceed a severity threshold such as HIGH or CRITICAL
• Explicitly allow or deny specific software packages, package versions, or Common Vulnerabilities and Exposures (CVEs)
• Grant grace periods for specific CVEs while fixes are developed
• Centralize findings from pipelines, registries, and clusters into a single view in Security Command Center

A Software Bill of Materials (SBOM), a machine-readable inventory of components and dependencies, supplies the lineage data that Artifact guard and scanners use to identify CVEs. Ownership in Artifact guard is split by role so policy definition stays separate from pipeline wiring. Security Administrators define and manage centralized vulnerability policies, DevOps or Platform Engineering teams add CI/CD scanning connectors and configure GKE admission controllers, and Application Developers view build failure logs to identify and update vulnerable dependencies before redeploying.

The three enforcement stages differ by where evaluation happens and what happens on violation:

1.4Gate builds with On-Demand Scanning in Cloud Build

On-Demand Scanning in a Cloud Build pipeline gates promotion by scanning a locally built image and blocking the push to Artifact Registry when severity matches a predefined level. In this flow, Cloud Build builds the container image from source code, the pipeline invokes a scan of the built image, the pipeline assesses vulnerability severity levels against the acceptable threshold, and only images with no disqualifying severities flow from the build step to Artifact Registry storage. Because the check runs before the push, vulnerable artifacts never gain registry lineage that downstream promotion or Binary Authorization would later need to block.

The high-level workflow for Artifact guard extends the same gate-first order to all scopes. First, create a connector to the CI/CD environment for pipeline scope, while registry and GKE cluster scopes are defined natively during policy configuration. Then configure Artifact guard policies for the target pipeline, registry, or runtime scope. Only after policies are attached do evaluations run, where pipeline builds fail on violation, registry admission control blocks deployment to GKE, and runtime monitoring flags newly disclosed issues in running containers.

Monitoring and auditing pipeline execution means tracking every build and every promotion between environments so failures, delays, and unauthorized changes can be proven and fixed. Cloud Build creates the verifiable record of how an artifact was built, Cloud Deploy creates the ordered record of where that artifact was released, and Cloud Audit Logs records who invoked those actions. Together they provide operational visibility, security enforcement, and compliance evidence across the delivery lifecycle and support software supply chain security (opens in a new tab).

2.1Analyze build logs and execution history in Cloud Build

Cloud Build is the service that runs builds on Google Cloud infrastructure in isolated and ephemeral build environments controlled by granular IAM permissions and VPC Service Controls. Each build emits step logs, duration, status, and toolchain details, and for container images it can generate authenticated and non-falsifiable build provenance at Supply-chain Levels for Software Artifacts (SLSA) Level 3. Because the environment is ephemeral and the provenance binds the output digest to its inputs, the history shows exactly what source, steps, and tools produced each artifact.

Security insights for built applications consolidate three peer signals for each build: the SLSA build level that identifies the maturity of the build process, vulnerabilities found in the build artifacts, and build provenance that includes digests of built images, input source locations, build toolchain, build steps, and build duration. Review step logs in Logs Explorer to identify failed commands, retried steps, and duration outliers that indicate performance bottlenecks, then correlate those failures with provenance to determine whether the cause was source change, dependency change, or toolchain change. For container images, Artifact Analysis continues to update image metadata after the initial scan when new vulnerability data arrives, so a previously passing build can later show new findings without a rebuild.

A complete audit lifecycle around build logs depends on Cloud Logging and Cloud Monitoring working together. Enable audit logging including for Cloud Storage, create logs-based metrics to capture relevant build and deployment events, configure alerting policies on those metrics, and deliver alerts through notification channels to the responsible personnel. Regularly analyze logs for anomalies, export logs through Pub/Sub for integration with a security information and event management (SIEM) system, maintain an incident response plan for anomalies, and regularly review both the alerting policy and IAM roles.

2.2Interpret delivery pipeline metrics and deployment history in Cloud Deploy

Cloud Deploy is the continuous delivery service that automates delivery of applications to a series of target environments in a defined sequence for GKE, GKE Enterprise, and Cloud Run. A release flows from the pipeline into the first target, then advances target by target only after each deployment succeeds and any required approval is granted, which creates a deployment history ordered by environment. The service provides built-in delivery metrics, one-click approvals and rollbacks, and enterprise security and audit, plus security insights for deployed applications.

Delivery metrics and dashboards answer whether promotions are healthy, stalled, or regressing across development, test, and production environments. Use them to track release frequency, promotion success and failure by target, rollout duration, and rollback rate, then drill from a failed or slow rollout into the target-specific deployment history and underlying build logs. Because Cloud Deploy enforces the same sequence for every release, a skipped environment, an out-of-order deployment, or a rollback to a prior known-safe version is visible as a break in the expected promotion path rather than as an untracked manual change.

2.3Implement approval gates and audit trails for promotion between environments

Approval gates are policy checkpoints that block promotion between environments until an authorized decision is recorded. Cloud Deploy supports one-click approvals before a release advances to the next target, so the audit trail shows who approved which release for which environment and when. Define different policies for development, test, and production so only verified artifacts deploy to higher environments, narrow the scope of security reviews to gated transitions, and preserve the ability to roll back to a known and safe version when a gate or deployment check fails.

Binary Authorization extends approval enforcement to deployment time on GKE and Cloud Run by checking attestations, which are configurable signatures attached to container images. An attestation can prove three separate conditions:

• A specific build system or continuous integration (CI) pipeline created the container image.
• The container image is compliant with a vulnerability signing policy.
• The container image passes the criteria for promotion to the next deployment environment, such as from development to quality assurance.

When the required attestations are missing, the platform denies deployment, so only trusted code runs on the target even if the pipeline was compromised. This control depends on the Cloud Build provenance and vulnerability signals upstream, because the attestation decision consumes the identity of the builder and the result of the security checks. Audit trails remain trustworthy only when logs are protected and retained. Control access to logs and log configurations with IAM allow policies, enforce uniform bucket-level access on the bucket that stores audit logs, and restrict audit functionality in application code. Back up audit logs to a separate repository such as Cloud Storage, configure retention, verify integrity, and monitor the exported logs with Cloud Monitoring and Pub/Sub alerting.

Cloud Audit Logs (opens in a new tab) is the Google Cloud auditing system that records who did what, where, and when across Google Cloud resources. Google Cloud services write immutable audit log entries for administrative activities and resource access, which gives deployment auditing the same transparency as on-premises environments for security, compliance, and operational visibility.

3.1Services that generate audit logs

Services that generate audit logs include the deployment and platform services that support the software delivery lifecycle, and the full list is maintained as Google Cloud services with audit logs. All Google Cloud services will eventually provide audit logs, so deployment actions in services such as build, deploy, and artifact systems can be traced through the same auditing framework. Google Cloud MCP servers also write Data Access audit logs in the format SERVICE_NAME.googleapis.com/mcp, enabled through audit logging for mcp.googleapis.com in the IAM AuditConfig object. Google Workspace and Cloud Identity produce Admin Activity audit logs separately in the Google Admin console, including user login events, and sharing those logs into Google Cloud enables central management of identity and deployment activity together.

3.2Types of audit logs

Cloud Audit Logs provides four audit log types for each Google Cloud project, folder, and organization. Admin Activity audit logs record user-driven API calls and other actions that modify configuration or metadata, such as creating VM instances or changing Identity and Access Management permissions. The other types extend coverage to data access, Google-driven system actions, and denied access attempts, and each type has a fixed identifier in Cloud Logging for querying.

Log entries written by Cloud Audit Logs are immutable, so deployment history cannot be altered after it is recorded. Admin Activity coverage is therefore the reliable baseline for tracking configuration changes, while Data Access logging is managed more selectively because of volume and cost.

3.3Access control for audit logs

Access control for Cloud Audit Logs data is managed with Identity and Access Management roles applied at the project level. The Logs Viewer role roles/logging.viewer grants read-only access to Admin Activity, Policy Denied, and System Event audit logs. The Private Logs Viewer role roles/logging.privateLogViewer includes the permissions in Logs Viewer plus the permissions needed to read Data Access audit logs in the _Default bucket. This boundary separates routine deployment-change review from broader access to potentially sensitive data-access history.

3.4Querying and monitoring deployment activity

Logs Explorer in the Google Cloud console is the primary path for retrieving audit log entries for troubleshooting and deployment review. Log entries can also be queried through the Cloud Audit Logs API, and Distributed Cloud user clusters must forward entries through the cloudAuditLogging section of the user cluster configuration before they appear in Cloud Audit Logs. Monitoring uses log-based alerting policies that send data from Logging to Cloud Monitoring and notify operators when a described condition appears.

Retrieving deployment audit entries follows an ordered workflow:

1. Open Logs Explorer: Go to Logs Explorer in the Google Cloud console and select the organization or the project configured for log forwarding.
2. Select resource type: Choose the Google Cloud resource whose audit logs are needed, such as k8s_cluster for Binary Authorization enforcement on pods.
3. Select log name: Choose activity for Admin Activity, data_access for Data Access, system_event for System Event, or policy for Policy Denied.
4. Run query: Refine the query in the query editor, confirm the time period covers the deployment event, and click Run query.

For Binary Authorization for Google Distributed Cloud (opens in a new tab), filtered queries distinguish rejected, dry-run, and break-glass pod activity. Rejected pod creation or update is found by filtering protoPayload.methodName for io.k8s.core.v1.pods.create or io.k8s.core.v1.pods.update with protoPayload.response.status of Failure. Dry-run activity adds the label binaryauthorization.googleapis.com/dry-run set to true, while break-glass activity uses binaryauthorization.googleapis.com/break-glass or the request label image-policy.k8s.io/break-glass. Log-based alerts should flag suspicious API requests such as unauthorized VM creations or IAM privilege escalations, with separate handling for events that need immediate investigation versus low-priority events.

3.5Routing audit logs with sinks for retention and analysis

Log sinks in Cloud Logging route some or all audit logs to supported destinations for long-term storage, retention, and analysis. Sinks move audit data from log buckets to external systems when compliance requires preservation beyond normal bucket retention.

• Cloud Logging log buckets hold logs for query and retention, with custom retention configurable from 1 day to 3650 days.
• Cloud Storage receives exported logs for low-cost, long-term archival storage.
• BigQuery receives exported logs for large-scale retention and SQL-based deployment and security analysis.

Custom retention rules apply to all logs in a bucket regardless of log type or whether the log was copied from another location. By default, Cloud Logging encrypts stored content at rest, and organizations with advanced requirements can protect audit logs with customer-managed encryption keys (CMEK) instead of Google-managed key encryption keys. Costs are managed by estimating usage, configuring alerting policies, recognizing that Data Access audit logs can be large, and excluding audit logs that are not useful, such as Data Access logs in development projects.

Key Facts

• Artifact Analysis scan metadata becomes stale after 30 days without an image pull and archived after 90 days stale, with archived metadata available only through the API and refresh after a pull taking up to 24 hours.
• Artifact guard enforces centralized policy at build-time scanning, registry admission control with Binary Authorization blocking deployment to GKE, and runtime monitoring of running containers.
• Cloud Build can generate SLSA Level 3 build provenance that binds the output image digest to source locations, build steps, toolchain, and duration.
• Binary Authorization denies deployment to GKE and Cloud Run when required attestations for builder identity, vulnerability compliance, or promotion criteria are missing.
• Admin Activity audit logs use log name activity and cannot be disabled, while Data Access audit logs use data_access and require the Private Logs Viewer role for viewing in the _Default bucket.