Container Registry and AKS Security

Azure Container Registry is a managed, private Docker registry service that stores container images and artifacts. ACR is built on top of Azure Blob Storage and provides a secure, scalable repository for your container workloads. The exam focuses on securing ACR at multiple layers: access control, network security, content trust, and vulnerability scanning.

ACR uses Azure RBAC for authentication and authorization. The built-in roles are: - AcrPull: Allows pulling (downloading) images. - AcrPush: Allows pushing (uploading) images and Helm charts. - AcrDelete: Allows deleting images and tags. - AcrImageSigner: Allows signing images for content trust. - Contributor and Owner: Provide full management of the registry, including role assignments.

Authentication methods include: - Azure AD authentication: Use az acr login to authenticate with your Azure AD identity. This is the recommended method for human users. - Admin account: A legacy account with username and password (two passwords). Disabled by default; enable only for legacy scenarios. The exam warns against using admin accounts in production. - Service principal: Use a service principal with a client ID and secret or certificate for automated deployments (e.g., CI/CD pipelines). - Managed identity: Assign a managed identity to an Azure resource (e.g., AKS cluster) and grant it AcrPull role for seamless authentication.

By default, ACR accepts connections from all networks. To restrict access: - Firewall rules: Configure IP-based access rules. Only allow traffic from specific IP ranges (e.g., your corporate VPN). - Service endpoints: Use Azure Service Endpoints to restrict traffic to your virtual network. This is a legacy approach; private endpoints are preferred. - Private endpoints: Assign a private IP address to ACR from your virtual network. Traffic never traverses the public internet. This is the most secure option and recommended for production. Requires a Private DNS Zone for resolution. - Public network access: You can disable public access entirely, forcing all traffic through private endpoints or trusted Azure services (like AKS).

ACR implements Docker Content Trust (Notary v2) to ensure image integrity. When enabled, only signed images can be pushed. The workflow: 1. A signer (user with AcrImageSigner role) signs the image using a delegation key. 2. The registry verifies the signature before accepting the image. 3. Clients configure DOCKER_CONTENT_TRUST=1 to pull only signed images.

On the exam, remember that content trust prevents tampering and ensures that images come from a trusted source. It does NOT scan for vulnerabilities.

Microsoft Defender for Cloud provides vulnerability scanning for images in ACR. When enabled, it scans images on push and periodically. It detects vulnerabilities in OS packages and libraries, and provides remediation steps. The exam tests that scanning is enabled via Defender for Cloud (formerly Security Center) and that it is a prerequisite for AKS security assessments.

AKS is a managed Kubernetes service. Security responsibilities are shared between Microsoft and you. Microsoft manages the control plane (API server, etcd, scheduler) and you secure worker nodes, pods, and network policies.

AKS integrates with Azure AD for authentication. You can enable Azure AD integration (managed or legacy) to allow users to authenticate with their Azure AD credentials. Key points: - Managed Azure AD integration: Default option. Creates a managed Azure AD application. Users get cluster-admin or namespace-level roles via Kubernetes RBAC. - Azure RBAC for Kubernetes: Allows granting Azure AD users/groups roles like Azure Kubernetes Service RBAC Cluster Admin at the subscription or resource group level. - Kubernetes RBAC: Uses Role and ClusterRole objects. The exam tests that you can use both Azure RBAC and Kubernetes RBAC together.

AKS supports two network plugins: kubenet and Azure CNI. For security, Azure CNI is recommended because it assigns a VNet IP to each pod, enabling Network Policies. - Network Policies: Kubernetes resources that control pod-to-pod traffic. Use Calico or Azure network policy engine. Policies define ingress/egress rules based on pod labels, namespaces, IP blocks, and ports. - Azure Policy for AKS: Apply Azure Policy to enforce security rules (e.g., disallow hostNetwork, require readOnlyRootFilesystem).

Pod Security Standards define three levels: Privileged, Baseline, and Restricted. AKS uses Pod Security Admission (PSA) to enforce these standards at the namespace level. The exam tests: - Privileged: Unrestricted (least secure). - Baseline: Minimally restrictive (prevents known privilege escalations). - Restricted: Heavily restrictive (follows pod hardening best practices).

You can set PSA via labels on namespaces: pod-security.kubernetes.io/enforce.

Microsoft Defender for Containers provides threat detection for AKS clusters, including: - Runtime threat detection: Alerts on suspicious activities like crypto mining, port scanning, or privileged container execution. - Vulnerability assessment: Scans container images in ACR and running pods. - Kubernetes audit logs: Analyzes API server logs for malicious commands.

Enable Defender for Cloud with the 'Containers' plan to get these features.

AKS can mount secrets from Azure Key Vault using the Secret Store CSI Driver. This avoids storing secrets in etcd. The driver uses a managed identity to authenticate to Key Vault. Key points: - CSI Driver: A Kubernetes CSI driver that mounts secrets as volumes or environment variables. - Rotation: Key Vault supports automatic rotation; the driver can sync secrets without pod restart. - Access: Grant the AKS cluster's managed identity Get and List permissions on Key Vault secrets.

Azure Policy can enforce security rules on AKS clusters. For example, a policy can require that all pods have resource limits. Microsoft Defender for Cloud provides a security score for AKS clusters and recommends fixes. The exam tests that you can use these tools together to achieve compliance.

This core explanation covers the essential mechanisms and configurations you need to know for the AZ-500 exam. Focus on understanding the 'why' behind each security control and the specific Azure services involved.

A large e-commerce company runs hundreds of microservices on AKS across multiple regions. They use ACR Premium with geo-replication to ensure low-latency pulls in each region. Security is paramount: they enable private endpoints for ACR and AKS, disable public access, and use Azure Firewall to control egress. They integrate Azure AD for AKS authentication and use Azure RBAC to grant developers namespace-level access. For image security, they enable Microsoft Defender for Containers to scan images on push and run time. They also enforce Pod Security Standards: the 'restricted' level for production namespaces and 'baseline' for development. They use Azure Policy to enforce that all pods have resource limits and that images come only from approved registries. A common misconfiguration they've encountered is forgetting to assign AcrPull role to the AKS managed identity, causing deployments to fail with ImagePullBackOff. They also learned to use network policies to isolate microservices, preventing lateral movement if a container is compromised. At scale, they monitor cluster performance with Container Insights and set alerts for any security events from Defender for Cloud. This setup meets PCI-DSS compliance requirements for cardholder data environments.

A bank deploys a containerized trading application on AKS. They have strict regulatory requirements: all container images must be signed (content trust) and scanned for vulnerabilities. They use ACR with content trust enabled, and only users with AcrImageSigner role can push signed images. The build pipeline (Azure DevOps) uses a service principal with AcrPush and AcrImageSigner roles to push signed images. The AKS cluster is private (no public API endpoint) and integrated with Azure AD. Developers access the cluster via a jump box in a management VNet. They use Azure Key Vault CSI driver to mount secrets (like database passwords) without storing them in etcd. They also use network policies to restrict pod-to-pod communication: only the frontend pods can talk to backend pods on specific ports. A major challenge was rotating the signing keys; they now store root keys in Azure Key Vault with hardware security module (HSM) backing. They also enable Defender for Containers runtime threat detection, which alerted them to a cryptominer in a compromised container. The incident response involved isolating the pod using network policies and revoking the compromised service principal. This scenario is typical for regulated industries and tests your knowledge of layered security.

A SaaS company automates deployments using GitHub Actions. Their CI/CD pipeline builds container images, pushes them to ACR, and deploys to AKS. Security is integrated at every step: the pipeline uses OpenID Connect (OIDC) to authenticate to Azure without storing secrets. The GitHub Actions runner is assigned a managed identity that has AcrPush role on ACR. After push, a separate job triggers Defender for Cloud scanning; if vulnerabilities are found, the pipeline fails. For deployment, the pipeline uses az aks get-credentials with Azure AD authentication. They use Azure Policy to enforce that all deployments must have at least two replicas and that containers run as non-root. They also use GitOps with Flux to ensure cluster state matches git repository. A common mistake they've seen is disabling public network access on ACR but forgetting to configure the private endpoint, causing the pipeline to fail. They also learned to use az acr check-health to diagnose connectivity issues. This scenario highlights the importance of integrating security into CI/CD and understanding the authentication flow between services.