3.1.1.3. Container Registries: ACR, Image Signing, and Lifecycle
3.1.1.3. Container Registries: ACR, Image Signing, and Lifecycle
Container images follow the same package management principles but add their own security and lifecycle concerns.
Container registries store, manage, and distribute container images — the deployable artifacts for containerized applications. Azure Container Registry (ACR) integrates with AKS through managed identity, eliminating image pull secrets entirely: az aks update --attach-acr grants the AKS kubelet's managed identity the AcrPull role. No secrets to rotate, no imagePullSecrets to distribute across namespaces. Image signing with Notation creates cryptographic verification — only images signed by the release pipeline can be deployed, enforced at the Kubernetes admission controller level. ACR retention policies and tag purging address the 80% storage waste from orphaned feature branch images: retention policies clean untagged manifests automatically, while pipeline-based purging removes old tags. For workloads targeting both AMD64 and ARM64 nodes, multi-architecture builds via docker buildx produce a single manifest list that Kubernetes resolves per node architecture.
Content for Artifact Traceability - see flashcards and questions for this subsection.
Container image lifecycle management prevents registry bloat and security exposure. Untagged images (dangling manifests) accumulate when new builds push the same tag — the old image loses its tag but the layers remain. ACR retention policies automatically purge untagged manifests after a configurable period. For tagged images, pipeline-based purging with acr purge removes tags older than N days on non-production repositories. Always exclude production tags and release-tagged images from automated purging.
Image vulnerability scanning with Microsoft Defender for Containers scans images at push time and continuously rescans stored images as new CVEs are published. Scan results integrate with Azure Policy to block deployment of images with Critical vulnerabilities. Quarantine policies hold newly pushed images in a quarantine state until scanning completes — preventing deployment of unscanned images.
For build optimization, multi-stage Dockerfiles separate build dependencies from runtime, producing smaller production images. Layer caching in ACR tasks (--cache-from) reuses unchanged layers across builds, reducing build time from minutes to seconds for incremental changes.
Geo-replication in Azure Container Registry places image copies in multiple Azure regions, reducing pull latency for globally distributed AKS clusters. Each replica is read-only; pushes go to the primary region and replicate automatically. For disaster recovery, the primary region can fail over to a replica.
Image quarantine policies provide an additional security layer: newly pushed images enter quarantine status and are unavailable for deployment until they pass vulnerability scanning. This prevents a race condition where a pipeline pushes and immediately deploys an image before scanning completes.
ACR Tasks provide server-side container builds — no local Docker daemon required. Define a multi-step task file that builds, tests, and pushes images entirely within ACR. This eliminates the Docker-in-Docker security concern on build agents and standardizes the build environment across all team members.
Geo-replication in ACR distributes images across Azure regions, enabling local pulls for globally distributed AKS clusters. Replication happens automatically — push to one region, pull from any. This reduces image pull latency and provides availability resilience if a region goes down.
ACR tasks enable automated container image building triggered by source code commits, base image updates, or scheduled timers — eliminating the need for a separate CI pipeline for image builds.
