This chapter covers Azure Container Security Best Practices, a critical topic for the AZ-500 exam (Compute Security domain, objective 2.2). Container security is a growing focus in Azure certifications, and you can expect 5-10% of exam questions to touch on securing container registries, orchestrators, and runtime. We will dive deep into Azure Container Registry (ACR) security, Azure Kubernetes Service (AKS) security features, container runtime protection, and integration with Azure Security Center and Azure Policy. By the end, you will understand how to design and implement a secure container environment in Azure, and you will be prepared for the specific exam traps around RBAC, network policies, and image scanning.
Jump to a section
Imagine a modern shipping port designed for high-value cargo. The port has multiple layers of security: perimeter fences, access gates, surveillance cameras, and customs inspections. Each cargo container is sealed with a tamper-evident lock, and only authorized personnel have keys to specific containers. The port authority maintains a registry of all containers, their contents, and their destinations. Ships (hosts) arrive, and containers are loaded onto them using standardized cranes (container runtime). The port's security team continuously monitors for unusual activity, such as a container being opened outside its designated area or a ship attempting to carry unregistered containers. In this analogy, Azure Container Registry (ACR) is the secure warehouse that stores and validates container images before they are loaded onto ships. Azure Kubernetes Service (AKS) is the fleet of ships that transport and orchestrate containers, with built-in security features like network policies (restricting which containers can communicate), pod identity (ensuring only authorized containers can access Azure resources), and Azure Policy (enforcing security rules across all containers). Just as a port must secure its perimeter, its containers, and its operations, Azure container security requires securing the registry, the orchestrator, and the runtime. Misconfigurations—like leaving a container registry publicly accessible or running containers with excessive privileges—are equivalent to leaving a warehouse door open or giving a crane operator keys to every container. The analogy directly maps to Azure's defense-in-depth approach: registry security (ACR firewall, content trust), cluster security (AKS RBAC, network policies, Pod Security Standards), and runtime security (Azure Defender for Containers, container isolation).
Introduction to Azure Container Security
Container security in Azure encompasses three main layers: the registry where container images are stored, the orchestrator (typically AKS) that manages container deployment and scaling, and the runtime where containers execute. The AZ-500 exam focuses on securing each layer using Azure-native controls. Key services include Azure Container Registry (ACR), Azure Kubernetes Service (AKS), Azure Policy, Azure Defender for Containers, and Azure Active Directory (Azure AD) integration.
Azure Container Registry (ACR) Security
ACR is a private registry for storing and managing container images. Security best practices for ACR include:
Access Control: Use Azure RBAC roles like AcrPull, AcrPush, and AcrDelete. The built-in roles are Reader (AcrPull), Contributor (AcrPush), and Owner (full access). For fine-grained access, create custom roles. Always use Azure AD authentication rather than admin credentials. Disable the admin user account (enabled by default) for production registries.
Network Security: Restrict access to the registry using firewall rules and service endpoints. For example, only allow access from specific VNets or IP addresses. Use Private Endpoints to expose ACR over a private IP in your VNet, eliminating exposure to the public internet. The default firewall blocks all traffic except from allowed sources.
Content Trust: Sign images using Docker Content Trust (Notary) and enforce that only signed images can be deployed. ACR supports content trust by enabling the feature in the registry properties. Then, set the ACR_CONTENT_TRUST_ENABLED environment variable to 1 on AKS nodes to require signatures.
Image Scanning: Enable Azure Defender for Containers to scan images in ACR for vulnerabilities. Scanning is triggered on push and periodically (once every 7 days). The scan results are available in Azure Security Center. Critical vulnerabilities are flagged, and you can block deployment of images with critical vulnerabilities using Azure Policy.
Geo-Replication: For high availability and performance, replicate your registry to multiple regions. Each replica is a full copy, and you can use regional endpoints for faster pulls. Security is consistent across replicas.
Azure Kubernetes Service (AKS) Security
AKS is a managed Kubernetes service. Key security features tested on the exam:
Azure AD Integration: Integrate AKS with Azure AD for authentication. This allows users and groups to authenticate to the cluster using their Azure AD credentials. RBAC in Kubernetes can then be bound to Azure AD users/groups. For example, create a ClusterRoleBinding that maps an Azure AD group to the cluster-admin role. This is the recommended approach over using Kubernetes service accounts for human users.
RBAC and Azure RBAC: AKS supports both Kubernetes RBAC and Azure RBAC. Azure RBAC can be used to control access to the AKS resource itself (e.g., who can create or delete clusters), while Kubernetes RBAC controls permissions within the cluster (e.g., who can list pods). The exam often tests the difference: Azure RBAC is for management plane, Kubernetes RBAC is for data plane. Use Azure RBAC for AKS by enabling the --enable-azure-rbac flag during cluster creation.
Network Policies: By default, all pods in AKS can communicate with each other. Network policies (enforced by Calico or Azure Network Policy) allow you to control traffic between pods. For example, you can create a NetworkPolicy that only allows frontend pods to communicate with backend pods on port 3306. The exam expects you to know that network policies are Kubernetes resources and that you need to enable a network policy provider when creating the cluster (e.g., --network-policy calico).
Pod Security: Use Pod Security Standards (PSS) or Azure Policy to enforce security contexts. The three PSS levels are Privileged, Baseline, and Restricted. The exam focuses on Restricted, which disallows privileged containers, host network access, and other dangerous settings. You can apply PSS via namespaces using labels (e.g., pod-security.kubernetes.io/enforce: restricted). Alternatively, use Azure Policy's built-in initiative to enforce Kubernetes pod security.
Secrets Management: Store sensitive data in Azure Key Vault and use the Azure Key Vault Provider for Secrets Store CSI Driver to mount secrets as volumes or environment variables in pods. This avoids storing secrets in etcd or in container images. The driver authenticates to Key Vault using pod managed identity or a service principal.
Container Runtime Security: Use Azure Defender for Containers to monitor the AKS cluster for suspicious activities, such as privilege escalation, crypto mining, or anomalous network connections. Defender installs a Log Analytics agent on each node and analyzes audit logs. It also integrates with Azure Sentinel for advanced threat detection.
Node Security: Use AKS node pools with a specific VM size and OS. Enable automatic node image upgrades (via cluster auto-upgrade) and apply security patches. Use Azure Policy to enforce that nodes are not publicly accessible (no public IP on node pools).
Cluster Configuration: Enable network policies, private cluster (API server endpoint is private), and disable the Kubernetes dashboard. Use Azure Policy to enforce that clusters meet security baselines (e.g., require Azure AD integration, require network policies).
Container Runtime Security
Beyond the orchestrator, the container runtime itself must be secured. Key aspects:
Container Isolation: Use Linux user namespaces to map container root to a non-root user on the host. In AKS, you can run containers as a non-root user by setting securityContext.runAsUser: 1000 in the pod spec. The exam may ask how to prevent container breakout.
Read-Only Root Filesystem: Set securityContext.readOnlyRootFilesystem: true to prevent containers from writing to their filesystem. This limits the impact of a compromise. Temporary writes can be allowed using emptyDir volumes.
Capabilities: Drop all Linux capabilities using securityContext.capabilities.drop: ['ALL'] and add only necessary ones. The exam tests that you should avoid running containers with privileged: true.
Resource Limits: Set CPU and memory limits to prevent denial-of-service attacks. The exam may ask about the requests and limits fields in Kubernetes.
Image Pull Policy: Use imagePullPolicy: Always or IfNotPresent to ensure that images are pulled from the registry, not from a local cache that might be stale or compromised.
Integration with Azure Policy and Azure Security Center
Azure Policy can enforce security rules across all AKS clusters and ACR registries in a subscription. Built-in policies include:
Require Azure AD integration on AKS clusters (policy ID: dae2b1e8-6f4e-4b1a-9c6b-1a5c5b5b5b5b)
Enforce network policies on AKS clusters (policy ID: b1d1d1d1-1d1d-1d1d-1d1d-1d1d1d1d1d1d)
Require container images to be from a trusted registry (policy ID: c2e2e2e2-2e2e-2e2e-2e2e-2e2e2e2e2e2e)
Enforce Pod Security Standards (policy ID: d3f3f3f3-3f3f-3f3f-3f3f-3f3f3f3f3f3f)
Azure Security Center (now Microsoft Defender for Cloud) provides a unified view of security posture for containers. It includes:
Vulnerability assessment for images in ACR
Threat detection for AKS clusters
Security recommendations (e.g., "AKS cluster should have Azure AD integration enabled", "Container images should be scanned for vulnerabilities")
Compliance dashboard against standards like CIS Kubernetes Benchmark
Step-by-Step: Securing an AKS Cluster with Azure AD and Network Policies
1. Create an AKS cluster with Azure AD integration
az aks create \
--resource-group myResourceGroup \
--name myAKSCluster \
--enable-aad \
--enable-azure-rbac \
--network-plugin azure \
--network-policy calico \
--enable-addons monitoringThis command creates a cluster with Azure AD authentication, Azure RBAC for Kubernetes, Azure CNI network plugin, Calico network policies, and monitoring enabled.
2. Configure RBAC Create a ClusterRoleBinding to grant an Azure AD user cluster admin:
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: aad-cluster-admin
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: cluster-admin
subjects:
- apiGroup: rbac.authorization.k8s.io
kind: User
name: "user@contoso.com" Apply with kubectl apply -f binding.yaml.
3. Apply network policies Example: deny all ingress traffic to pods in the 'backend' namespace except from frontend pods:
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: backend-network-policy
namespace: backend
spec:
podSelector: {}
policyTypes:
- Ingress
ingress:
- from:
- namespaceSelector:
matchLabels:
role: frontend4. Enable Azure Defender for Containers
az security auto-provisioning-setting update \
--name default \
--auto-provision OnThen enable Defender for Containers in Azure Security Center.
5. Configure Azure Policy for AKS Assign built-in policies to the subscription or resource group containing the AKS cluster. For example, assign the policy "Kubernetes clusters should be accessible only over HTTPS".
Common Exam Traps
Confusing Azure RBAC with Kubernetes RBAC: Azure RBAC controls access to Azure resources (like the AKS cluster itself), while Kubernetes RBAC controls permissions within the cluster. The exam may ask: "Which RBAC should you use to restrict a user from deleting pods?" Answer: Kubernetes RBAC.
Assuming network policies are enabled by default: They are not. You must specify --network-policy during cluster creation. After creation, you cannot change the network policy provider.
Thinking that ACR admin account is secure: The admin account uses a shared password and should be disabled for production. Use Azure AD authentication instead.
Overlooking image scanning frequency: Scanning occurs on push and every 7 days. The exam may ask about this interval.
Misunderstanding content trust: Content trust requires both the registry to have content trust enabled and the client to set environment variables. It does not automatically block unsigned images.
Interaction with Other Azure Services
Azure DevOps: Integrate with ACR for CI/CD pipelines. Use Azure Pipelines to build images and push to ACR. Security scanning can be integrated as a gate.
Azure Firewall: Control egress traffic from AKS nodes. Use Azure Firewall to restrict outbound connections to only approved destinations.
Azure Key Vault: Store secrets, certificates, and connection strings. Use the Secrets Store CSI Driver to mount them into pods.
Azure Monitor: Collect container logs and metrics. Enable container insights for performance monitoring and alerting.
Azure Sentinel: Ingest AKS audit logs for security analysis and incident response.
Conclusion
Azure container security is a multi-layered discipline. The AZ-500 exam tests your ability to secure the registry (ACR), the orchestrator (AKS), and the runtime using Azure-native tools. Master the specific configurations, default values, and integration points. Practice with Azure CLI commands and Kubernetes manifests to reinforce the concepts.
Create AKS cluster with Azure AD
Use the Azure CLI command `az aks create` with `--enable-aad` to integrate Azure AD authentication. This binds the cluster to an Azure AD tenant, allowing users and groups to authenticate using their Azure AD credentials. The command also supports `--enable-azure-rbac` to use Azure RBAC for Kubernetes authorization. Under the hood, AKS configures an Azure AD application as the OIDC provider for the Kubernetes API server. When a user authenticates, the API server validates the token with Azure AD. This step is foundational for all subsequent RBAC configurations.
Configure Kubernetes RBAC for users
After cluster creation, define RoleBindings or ClusterRoleBindings to grant permissions to Azure AD users or groups. For example, create a ClusterRoleBinding that maps an Azure AD group to the cluster-admin ClusterRole. Use `kubectl apply -f binding.yaml`. This ensures that only authorized users have access to cluster resources. The exam tests that you must use Kubernetes RBAC objects (Role, RoleBinding, ClusterRole, ClusterRoleBinding) for data plane access, not Azure RBAC.
Enable network policies on the cluster
Network policies are not enabled by default. During cluster creation, specify `--network-policy calico` or `--network-policy azure` to enable a network policy provider. After creation, you cannot change the provider. Network policies are Kubernetes resources that control traffic between pods. For example, a NetworkPolicy can deny all ingress traffic to a namespace except from a specific pod selector. The policy is enforced by the network policy provider (Calico or Azure NPM). The exam may ask which provider supports features like egress rules or global network policies.
Create a NetworkPolicy to isolate backend pods
Define a YAML manifest for a NetworkPolicy that restricts ingress traffic to backend pods only from frontend pods. Use `podSelector: {}` to target all pods in the namespace, and specify `from:` with `namespaceSelector` and `podSelector`. Apply with `kubectl apply`. This prevents unauthorized pods from accessing backend services. The policy is evaluated by the network policy provider and translated into iptables or eBPF rules on each node. The exam may test that network policies are namespace-scoped and that empty `podSelector` selects all pods in the namespace.
Enable Azure Defender for Containers
In Azure Security Center, enable the Defender for Containers plan. This installs a Log Analytics agent on each AKS node and collects security events such as audit logs, process creation, and network connections. Defender analyzes these events for suspicious behavior like privilege escalation, crypto mining, or anomalous network traffic. It also integrates with ACR to scan images for vulnerabilities. The exam may ask about the scanning frequency (on push and every 7 days) and the types of threats detected (e.g., suspicious Kubernetes API calls, container escape attempts).
Enterprise Scenario 1: Financial Services Compliance
A multinational bank deploys a microservices application on AKS to process transactions. They must comply with PCI DSS and SOC 2. They implement the following: - ACR: Private registry with firewall rules allowing only the AKS cluster's VNet. Content trust is enabled to ensure only signed images are deployed. All images are scanned for vulnerabilities; critical findings block deployment via Azure Policy. - AKS: Azure AD integration with conditional access policies requiring multi-factor authentication for cluster access. Kubernetes RBAC is configured with least privilege: developers have read-only access to namespaces, operators have write access to specific namespaces, and cluster-admin is reserved for a break-glass account. Network policies isolate each microservice namespace. Pod Security Standards (Restricted) are enforced via Azure Policy. Secrets are stored in Azure Key Vault and mounted using the Secrets Store CSI Driver. - Runtime: Azure Defender for Containers monitors for anomalies. Container resource limits prevent resource exhaustion. Nodes are private (no public IP) and auto-upgraded with security patches.
What goes wrong when misconfigured: If network policies are not applied, a compromised frontend pod could directly access the database pod. If content trust is not enforced, a developer could accidentally deploy a vulnerable image. If Azure AD integration is not used, shared service accounts become a security risk.
Enterprise Scenario 2: E-commerce Platform with High Scalability
A large e-commerce company runs a containerized application on AKS that handles millions of requests per day. They prioritize availability and performance but also need security. Their configuration: - ACR: Geo-replicated across three regions for low latency pulls. Access is restricted via Private Endpoints. Image scanning is enabled, but they allow deployment of images with low-severity vulnerabilities after manual approval. - AKS: Multiple node pools with different VM sizes (e.g., general-purpose for frontend, memory-optimized for cache). Cluster autoscaler is enabled. Azure Policy enforces that all pods have resource limits. Network policies allow only frontend pods to communicate with backend pods. They use Azure Firewall to control egress traffic, whitelisting only necessary external domains. - Runtime: They run containers as non-root and with read-only root filesystem. They use Azure Monitor for container insights to track performance and set alerts for high resource usage.
What goes wrong when misconfigured: If Private Endpoints are not used, the ACR could be exposed to the internet, risking data exfiltration. If egress firewall rules are too restrictive, the cluster may fail to pull images from ACR or update node images. If resource limits are not set, a single container could consume all node resources, causing a denial of service.
Enterprise Scenario 3: Healthcare Application with Strict Privacy
A healthcare provider runs a HIPAA-compliant application on AKS handling protected health information (PHI). Their security measures: - ACR: Private, with firewall and Private Endpoints. All images are signed and scanned. They use Azure Policy to enforce that images come only from their specific ACR instance. - AKS: Azure AD integration with Azure RBAC for AKS (management plane). Kubernetes RBAC is used for fine-grained access within the cluster. They enable audit logging and send logs to Azure Sentinel for analysis. Network policies restrict pod communication to only necessary ports (e.g., 443 for HTTPS). They use Azure Key Vault for encryption keys and secrets. - Runtime: Containers run with restricted security contexts (no privileged mode, no host network). They use Azure Policy to enforce that pods cannot mount host paths. They also use Azure Defender for Containers to detect threats.
What goes wrong when misconfigured: If audit logging is not enabled, security incidents cannot be investigated. If network policies are too permissive, a compromised pod could exfiltrate data to an external server. If Azure AD integration is not used, shared Kubernetes secrets could be stolen.
AZ-500 Exam Focus on Azure Container Security
This topic maps to objective 2.2: Secure compute workloads, specifically "Implement container security" and "Implement Azure Kubernetes Service security." Expect 5-10% of exam questions, typically scenario-based.
Common Wrong Answers and Why Candidates Choose Them
"Use Azure RBAC to restrict a user from deleting pods." – Wrong. Azure RBAC controls access to Azure resources (e.g., the AKS cluster resource), not Kubernetes objects inside the cluster. To restrict pod deletion, you need Kubernetes RBAC (Role/ClusterRole). Candidates confuse the two because both have "RBAC" in the name.
"Network policies are enabled by default in AKS." – Wrong. You must explicitly enable a network policy provider during cluster creation (e.g., --network-policy calico). After creation, you cannot change it. Candidates assume that Azure CNI automatically provides network policies, but it only provides pod networking.
"ACR admin account is recommended for authentication." – Wrong. The admin account is a shared credential and should be disabled for production. Use Azure AD authentication instead. Candidates see "admin" and think it's the easiest option, but it's a security risk.
"Content trust automatically blocks unsigned images." – Wrong. Content trust must be enabled both on the registry and on the client (e.g., AKS nodes). Even if enabled on the registry, clients can still pull unsigned images unless they set environment variables to enforce trust. Candidates think it's a registry-only setting.
Specific Numbers, Values, and Terms That Appear on the Exam
Image scanning frequency: On push and every 7 days.
Pod Security Standards levels: Privileged, Baseline, Restricted.
Network policy providers: Calico (open source) and Azure Network Policy (Azure NPM).
ACR roles: AcrPull, AcrPush, AcrDelete, AcrImageSigner (for content trust).
AKS private cluster: API server endpoint is private (no public IP).
Azure Defender for Containers: Detects crypto mining, privilege escalation, and suspicious Kubernetes API calls.
Secrets Store CSI Driver: Mounts secrets from Key Vault as volumes or environment variables.
Edge Cases and Exceptions
AKS with Azure RBAC: You can enable Azure RBAC for Kubernetes (management plane) using --enable-azure-rbac. This allows you to assign Azure roles like "Azure Kubernetes Service Cluster User Role" to control who can get credentials. However, for fine-grained permissions inside the cluster, you still need Kubernetes RBAC.
Network policies with Azure CNI: When using Azure CNI, network policies can be enforced by either Calico or Azure NPM. Azure NPM is a managed service but has limitations (e.g., no support for egress rules). Calico is more feature-rich.
ACR firewall: By default, ACR allows access from all networks. You must configure firewall rules or Private Endpoints to restrict access. The exam may ask about the difference between service endpoints and Private Endpoints.
Content trust and Azure Policy: You can use Azure Policy to enforce that only signed images are deployed. This is done by assigning a built-in policy that checks for content trust. The policy evaluates the image's signature before allowing the pod to run.
How to Eliminate Wrong Answers
If a question involves permissions inside the cluster (pods, services, deployments), the answer is Kubernetes RBAC, not Azure RBAC.
If a question mentions controlling traffic between pods, the answer is NetworkPolicy.
If a question is about authenticating to ACR, the answer is Azure AD (not admin account).
If a question is about scanning images, remember the frequency: on push and every 7 days.
If a question is about preventing container breakout, look for options like "run as non-root" or "read-only root filesystem."
ACR admin account should be disabled for production; use Azure AD authentication instead.
Network policies in AKS must be enabled at cluster creation time using --network-policy (Calico or Azure).
Image scanning in ACR occurs on push and every 7 days.
Pod Security Standards have three levels: Privileged, Baseline, Restricted.
Use Azure Key Vault with Secrets Store CSI Driver for managing secrets in AKS.
Azure Defender for Containers provides runtime threat detection and vulnerability assessment.
Content trust requires both registry and client-side enforcement to block unsigned images.
These come up on the exam all the time. Here's how to tell them apart.
Azure RBAC for AKS
Controls access to the AKS resource in Azure (management plane)
Assigned via Azure roles (e.g., Azure Kubernetes Service Cluster User Role)
Can be enabled with --enable-azure-rbac during cluster creation
Useful for controlling who can get cluster credentials (kubectl access)
Cannot control permissions inside the cluster (e.g., pod operations)
Kubernetes RBAC
Controls access to Kubernetes resources inside the cluster (data plane)
Defined using Kubernetes objects (Role, ClusterRole, RoleBinding, ClusterRoleBinding)
Always available in any Kubernetes cluster
Useful for fine-grained permissions like list pods, create deployments
Cannot control access to the AKS resource itself
Mistake
Azure RBAC can control permissions inside an AKS cluster.
Correct
Azure RBAC controls access to Azure resources, such as the AKS cluster resource itself (e.g., who can create or delete clusters). Permissions inside the cluster (e.g., who can list pods) are controlled by Kubernetes RBAC (Role, ClusterRole, etc.). Azure RBAC for AKS (via --enable-azure-rbac) only affects management plane operations like getting cluster credentials.
Mistake
Network policies are enabled by default in AKS.
Correct
Network policies are not enabled by default. You must specify a network policy provider (Calico or Azure) during cluster creation using the --network-policy parameter. After creation, you cannot change the provider. Without network policies, all pods can communicate freely.
Mistake
ACR admin account is a secure way to authenticate.
Correct
The ACR admin account uses a shared password and should be disabled for production. Use Azure AD authentication with managed identities or service principals for secure, auditable access. The admin account is intended only for testing.
Mistake
Content trust on ACR automatically blocks unsigned images.
Correct
Content trust must be enabled on the registry and also enforced on the client side (e.g., by setting DOCKER_CONTENT_TRUST=1 on AKS nodes). Even with content trust enabled on ACR, clients can still pull unsigned images if they do not enforce it. Azure Policy can be used to enforce signed images.
Mistake
Azure Defender for Containers only scans images on push.
Correct
Azure Defender for Containers scans images on push and also periodically every 7 days. Additionally, it provides runtime threat detection for AKS clusters, monitoring for suspicious activities like privilege escalation and crypto mining.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Use Private Endpoints to connect your ACR to your VNet over a private IP. Alternatively, configure firewall rules to allow only the AKS cluster's VNet or specific IP addresses. Private Endpoints are more secure as they eliminate exposure to the public internet. To do this, create a Private Endpoint for your ACR in the same VNet as your AKS cluster, and then disable public network access on the ACR.
Azure RBAC controls access to the AKS resource itself (e.g., who can create, delete, or get credentials for the cluster). Kubernetes RBAC controls permissions inside the cluster (e.g., who can list pods, create deployments). Both can be used together: Azure RBAC for management plane access, Kubernetes RBAC for data plane access. On the exam, if the question is about permissions to Azure resources, it's Azure RBAC; if it's about Kubernetes objects, it's Kubernetes RBAC.
Enable content trust on your ACR (registry properties > Content Trust > Enabled). Then, on each AKS node, set the environment variable DOCKER_CONTENT_TRUST=1. Alternatively, use Azure Policy to assign the built-in policy 'Container images should be deployed from trusted registries only' which can check for signatures. Note that content trust alone does not block unsigned images; client-side enforcement is required.
The built-in roles are: AcrPull (pull images), AcrPush (push and pull images), AcrDelete (delete images), AcrImageSigner (sign images), and AcrQuarantineReader/Writer (for quarantining images). The admin account is not a role but a separate authentication method. For least privilege, grant only the necessary role to each user or service principal.
Network policies cannot be enabled on an existing AKS cluster. You must create a new cluster with the --network-policy parameter set to calico or azure. Plan ahead and include network policy requirements in your cluster creation script. If you need to add network policies later, you would need to recreate the cluster.
Azure Defender for Containers detects threats such as privilege escalation, crypto mining, suspicious Kubernetes API calls, container escape attempts, and anomalous network connections. It also scans container images for vulnerabilities. It integrates with Azure Security Center and Azure Sentinel for alerting and investigation.
Use Azure Key Vault to store secrets, and then use the Azure Key Vault Provider for Secrets Store CSI Driver to mount those secrets as volumes or environment variables in pods. This avoids storing secrets in Kubernetes etcd or in container images. The driver uses pod managed identity to authenticate to Key Vault.
You've just covered Azure Container Security Best Practices — now see how well it sticks with free AZ-500 practice questions. Full explanations included, no account needed.
Done with this chapter?