Google Cloud Artifact Registry replaced Container Registry as the recommended place to store your container images, language packages, and OS packages on GCP. It is a significant upgrade in terms of features, but the security configuration is not automatic. A default Artifact Registry setup leaves gaps that a determined attacker can exploit.
This guide covers how to lock down Artifact Registry properly, with a focus on real-world attack scenarios rather than checkbox compliance.
Why Artifact Registry Security Matters
Your artifact registry is the distribution point for everything you deploy. Container images, npm packages, Python wheels, Maven artifacts -- they all flow through this system on their way to production. If an attacker can tamper with an artifact in your registry, they own your deployment.
The risk is not hypothetical. Dependency confusion attacks, compromised base images, and registry credential theft are all actively exploited techniques. Artifact Registry gives you the tools to defend against these attacks, but you have to configure them correctly.
IAM Configuration: The Foundation
Artifact Registry uses GCP IAM for access control. The default permissions are often too broad, especially when projects are set up quickly.
Use repository-level IAM, not project-level. Artifact Registry supports IAM policies at the individual repository level. This means you can give your CI/CD pipeline write access to the build repository without giving it access to the production repository. Project-level roles like roles/artifactregistry.writer grant access to every repository in the project. Avoid them.
Separate read and write permissions. Your Kubernetes nodes need to pull images. They do not need to push them. Give GKE node service accounts roles/artifactregistry.reader on the specific repositories they need. Give your Cloud Build service account roles/artifactregistry.writer only on the repositories it builds into.
Use dedicated service accounts. Do not use the default compute service account for Artifact Registry access. Create purpose-built service accounts with minimal permissions. Name them clearly -- sa-cloudbuild-artifacts@project.iam is better than wondering why the default compute account has registry write access.
Audit IAM bindings regularly. Use gcloud asset search-all-iam-policies to find every principal with access to your Artifact Registry repositories. Review this list quarterly and remove access that is no longer needed.
Vulnerability Scanning with Container Analysis
GCP offers two scanning modes for container images: on-demand scanning and automatic scanning through Container Analysis. Use both.
Enable automatic scanning. Container Analysis continuously scans images stored in Artifact Registry for known vulnerabilities. This is not just a one-time scan on push -- it re-evaluates images as new CVEs are published. An image that was clean last week might have critical vulnerabilities today.
Act on scan results. Scanning is useless if nobody looks at the results. Integrate Container Analysis findings into your workflow. Set up Pub/Sub notifications for new vulnerabilities and route them to your security team's alerting system.
Define severity thresholds. Not every vulnerability requires immediate action. Define clear thresholds: critical and high severity vulnerabilities in production images get immediate attention, medium vulnerabilities get tracked in your backlog, and low severity findings get reviewed quarterly.
Scan before promotion. Before promoting an image from a staging repository to a production repository, verify that it passes your vulnerability threshold. This is a natural gate in your deployment pipeline.
Binary Authorization: Enforcing Image Trust
Binary Authorization is GCP's mechanism for ensuring that only trusted container images run on your GKE clusters. It is the enforcement layer that turns your security policies into hard gates.
Create attestors for each verification step. Define attestors for your build system, your security scanner, and your manual review process. An image must collect attestations from all required attestors before it can be deployed.
Use PKIX key pairs for attestation. Each attestor should use a unique PKIX key pair stored in Cloud KMS. This provides cryptographic proof that a specific verification step was completed by an authorized system.
Start with dry-run mode. Binary Authorization supports a dry-run mode that logs policy violations without blocking deployments. Use this to validate your policies before enforcing them. There is nothing worse than a misconfigured security control that blocks legitimate deployments during an incident.
Handle break-glass scenarios. Define a break-glass procedure that allows emergency deployments to bypass Binary Authorization. Log these events aggressively and review them after the incident. The break-glass mechanism should be painful enough that people do not use it casually.
Repository Configuration Best Practices
How you structure your Artifact Registry repositories affects your security posture.
Use separate repositories for each environment. Create distinct repositories for development, staging, and production images. Apply progressively stricter IAM policies and scanning requirements as images move toward production.
Enable immutable tags where possible. Artifact Registry supports tag immutability for Docker repositories. When enabled, a tag cannot be overwritten once it is pushed. This prevents tag mutation attacks and ensures that a specific tag always refers to the same image.
Set cleanup policies. Old, unpatched images sitting in your registry are a liability. Configure cleanup policies to automatically delete images older than a defined threshold, keeping only the most recent versions. This reduces your attack surface and your storage costs.
Use remote repositories as proxies. Artifact Registry remote repositories act as caching proxies for upstream sources like Docker Hub, Maven Central, and npm. Route all external package pulls through remote repositories so you have a single point of visibility and control.
Network Security
Artifact Registry supports VPC Service Controls, which are essential for organizations with strict network security requirements.
Configure VPC Service Controls. Place Artifact Registry inside a VPC Service Controls perimeter. This prevents data exfiltration by restricting which networks and identities can access the registry.
Use Private Google Access. Configure your VPC subnets to use Private Google Access so that GKE nodes and Cloud Build workers can reach Artifact Registry without traversing the public internet.
Restrict access by IP range. For repositories that need to be accessible from outside GCP, use organization policies to restrict access to known IP ranges.
Audit Logging and Monitoring
You cannot secure what you cannot see. GCP's audit logging gives you visibility into Artifact Registry operations.
Enable data access logs. By default, GCP logs admin activity (creating/deleting repositories) but not data access (pushing/pulling images). Enable data access audit logs for Artifact Registry so you can see who is pulling what and when.
Monitor for anomalies. Set up log-based metrics and alerts for unusual patterns: images being pulled from unexpected IP ranges, pushes happening outside business hours, or a sudden spike in pull requests for a specific image.
Export logs for retention. GCP retains audit logs for a limited time. Export them to Cloud Storage or BigQuery for long-term retention and analysis. You will want these logs during an incident investigation.
Integrating with Cloud Build
Cloud Build is the natural CI/CD partner for Artifact Registry. The integration is straightforward, but there are security considerations.
Use Cloud Build's built-in provenance. Cloud Build can automatically generate SLSA provenance metadata for artifacts it produces. Enable this to create a verifiable record of how each artifact was built.
Pin builder images. In your cloudbuild.yaml, reference builder images by digest, not by tag. This ensures your builds use exactly the image you expect, not a potentially compromised version hiding behind a mutable tag.
Minimize build step permissions. Each Cloud Build step runs with the permissions of the Cloud Build service account. Keep these permissions minimal and use step-level secret references to avoid exposing credentials to steps that do not need them.
How Safeguard.sh Helps
Safeguard.sh extends your GCP Artifact Registry security with automated SBOM generation, continuous vulnerability monitoring, and policy enforcement that works across your entire artifact lifecycle. It integrates with Container Analysis findings and adds deeper dependency analysis, license compliance checking, and risk scoring that goes beyond what GCP's native tools provide.
The platform gives you a unified view of your artifact security posture across all your GCP projects, so you can see which repositories have the highest risk and where to focus your remediation efforts. Whether you are running ten repositories or ten thousand, Safeguard.sh scales with you.