Azure Container Registry is where your container images live before they reach AKS, App Service, or Container Instances. It is a managed service that handles storage, replication, and access control. But "managed" does not mean "secure by default." The out-of-the-box configuration prioritizes accessibility over security, and most teams never tighten it.
I have seen ACR instances with public endpoints, admin accounts enabled, and no vulnerability scanning in organizations that otherwise take security seriously. The registry is often an afterthought -- set up during the initial project setup and never revisited.
This post covers how to fix that.
Choose the Right SKU
ACR comes in three SKUs: Basic, Standard, and Premium. The security features you need are only available in Premium.
Premium is required for production. Private endpoints, content trust, customer-managed encryption keys, geo-replication, and firewall rules are all Premium-only features. If you are running production workloads, you need Premium. The cost difference is trivial compared to the security capabilities.
Basic and Standard are fine for development and testing. But do not deploy to production from a Basic registry.
Disable the Admin Account
Every ACR instance has an admin account that can be enabled in the portal. It provides a username and password that grants full push and pull access to every repository in the registry.
Disable the admin account immediately. It is a shared credential with no audit trail for who used it. It cannot be scoped to specific repositories. It bypasses all RBAC. It is the opposite of everything you want in access control.
Use Azure AD authentication and RBAC instead. Every principal gets their own identity, their own permissions, and their own audit trail.
RBAC Configuration
ACR has several built-in roles. Use them at the appropriate scope.
AcrPull grants read-only access to pull images. Assign this to your AKS cluster's managed identity, your App Service's managed identity, and any other compute that needs to pull images.
AcrPush grants read and write access. Assign this to your CI/CD pipeline's service principal. It should be the only identity pushing to the registry.
AcrDelete grants permission to delete images and repositories. Very few principals should have this. Usually just your cleanup automation and registry administrators.
Scope roles to repositories when possible. ACR supports repository-scoped tokens that limit access to specific repositories within a registry. Use these for fine-grained access control -- your frontend pipeline should not have push access to the backend image repository.
Network Isolation
By default, ACR accepts connections from the public internet. For production registries, this is unacceptable.
Configure private endpoints. Create a private endpoint for your ACR in the same VNet as your AKS cluster and CI/CD agents. This keeps all registry traffic on the Azure backbone network.
Disable public access. Once your private endpoints are configured, disable public network access entirely. Your ACR should only be reachable from your private network.
Configure firewall rules as a fallback. If you cannot use private endpoints for all access patterns (e.g., developer workstations need access for debugging), configure firewall rules to allow only specific IP ranges. But private endpoints are the preferred approach.
Use dedicated data endpoints. ACR Premium supports dedicated data endpoints that provide a separate FQDN for data traffic (image pulls). This simplifies firewall rules and ensures data traffic does not share the management endpoint.
Content Trust and Image Signing
ACR supports Docker Content Trust (DCT) for image signing. This provides cryptographic assurance that an image was published by a trusted party and has not been tampered with.
Enable content trust on your registry. This allows publishers to sign images when pushing them. Consumers can then verify signatures when pulling.
Use Notation for sigstore-compatible signing. Docker Content Trust is the legacy approach. For newer deployments, consider using Notation with Azure Key Vault for OCI-native signing. Notation is more flexible and better integrated with the broader supply chain security ecosystem.
Enforce signature verification at deployment. Enable Azure Policy or use Ratify on AKS to verify that images are signed before they can be deployed. Without enforcement, signing is just a suggestion.
Vulnerability Scanning with Defender for Containers
Microsoft Defender for Containers provides vulnerability scanning for ACR images. It is the primary scanning mechanism in the Azure ecosystem.
Enable Defender for Containers. It scans images on push and continuously rescans as new vulnerabilities are discovered. It covers OS packages and application dependencies for major languages.
Review findings in Defender for Cloud. Scanning results appear as security recommendations in Defender for Cloud. Set up email notifications and workflow automation for critical findings.
Integrate with Azure Policy. Create policies that prevent deployment of images with critical vulnerabilities. Azure Policy can check Defender findings before allowing an image to run on AKS.
Understand scan coverage. Defender scans images pushed within the last 30 days by default. Older images may not be scanned. If you have long-lived images in your registry, ensure they are being rebuilt and rescanned regularly.
Geo-Replication Security
If you use ACR's geo-replication to place registries closer to your deployments, each replica needs the same security configuration.
Network rules apply to each replica endpoint. When you configure firewall rules or private endpoints, remember that each geo-replica has its own endpoint. Configure network controls for every replica.
Content trust works across replicas. Signed images maintain their signatures when replicated. Verify that your deployment targets check signatures regardless of which replica they pull from.
Retention and Lifecycle Management
Unmanaged registries grow indefinitely. Old images consume storage and accumulate vulnerabilities.
Configure retention policies. ACR Premium supports retention policies that automatically delete untagged manifests after a specified number of days. Enable this to prevent manifest bloat.
Use purge tasks for advanced cleanup. ACR purge tasks let you define more complex cleanup rules -- delete images older than 90 days, keep the most recent 10 tags, and similar policies. Schedule these to run regularly.
Quarantine suspicious images. ACR supports a quarantine pattern where newly pushed images are held in a quarantine state until they pass automated checks. Use this to prevent vulnerable or unsigned images from being pullable.
Audit Logging
ACR logs are essential for security monitoring and incident response.
Enable diagnostic logging. Configure ACR to send diagnostic logs to a Log Analytics workspace. This captures login events, repository events, and all API operations.
Monitor for suspicious activity. Set up alerts for admin account usage (if you cannot disable it for legacy reasons), image deletions, permission changes, and pulls from unexpected IP addresses.
Retain logs for compliance. Send logs to Azure Storage for long-term retention. Most compliance frameworks require at least one year of audit log retention.
CI/CD Integration Best Practices
Your CI/CD pipeline is the primary producer of images in your registry. Secure the integration.
Use managed identities for authentication. If your CI/CD runs on Azure (Azure DevOps, GitHub Actions with Azure runners), use managed identities to authenticate with ACR. No credentials to manage or rotate.
Use service principals with minimal permissions. For external CI/CD systems, create a dedicated service principal with only AcrPush on the specific repositories the pipeline builds. Rotate the credentials regularly.
Scan before pushing. Run vulnerability scanning in your CI/CD pipeline before pushing to ACR. This catches issues before they enter your registry, reducing noise in your Defender findings.
How Safeguard.sh Helps
Safeguard.sh provides continuous security monitoring for your Azure Container Registry that goes beyond what Defender for Containers offers. It generates comprehensive SBOMs for every image, tracks dependency changes between builds, and correlates vulnerabilities with actual deployment context in your AKS clusters.
The platform integrates with your Azure DevOps or GitHub Actions pipelines to enforce security gates, and provides a unified dashboard that shows your complete container security posture across all registries and clusters. When a new vulnerability drops, you know within minutes which production services are affected and what needs to happen.