Azure Container Security Best Practices and Recommendations

Azure Container Security is a top priority for any organization running containerized applications in the cloud. Implementing a robust security posture requires attention to several key areas.

Use Azure Policy to enforce security standards across your containerized applications. This helps ensure consistent configuration and reduces the risk of misconfigured containers.

Regularly update and patch your container images to prevent known vulnerabilities. Azure Container Registry (ACR) provides a secure way to store and manage your container images, including automated scanning and vulnerability assessment.

Azure Security Center provides real-time threat protection and vulnerability assessment for your containerized applications. This helps you stay ahead of potential security threats and ensures the integrity of your containerized workloads.

Securing your Azure Container Registry is a must, especially if it contains images with Intellectual Property.

To do this, you can use various tools to automate security code analysis and strengthen your security posture by following a Security Development Lifecycle (SDL).

Restricting access to your Kubernetes API server is also crucial, which can be done by defining authorized IP ranges or setting up your API servers as private clusters. This will ensure that only applications from allowed networks, machines, or subnets can access your cluster.

It's also important to regularly scan your registry images for known vulnerabilities and resolve any findings to maintain a secure and reliable software supply chain.

Secure your Azure Container Registry to protect your Intellectual Property and other sensitive assets. This can be done by ensuring your registries are tight, especially if they contain images with sensitive information.

Automating security code analysis using various tools can also help strengthen your security posture. This is in addition to having a great Security Development Lifecycle (SDL) routine in place.

Managed identities for Azure resources can be used to run code in Azure Container Instances without maintaining any secrets or credentials in code. This is a great way to manage application identities securely and automatically.

To use a secure key management process, create and control the lifecycle of your encryption keys used for customer-managed key-based encryption with Azure Key Vault. This provides an added layer of security for your container instance.

Regularly scanning your registry images for known vulnerabilities (CVEs) can help maintain a secure and reliable software supply chain. This can be done with Defender for Cloud, which provides detailed findings for each scanned image.

Defender for Cloud scans your registry images for known vulnerabilities and provides detailed findings for each scanned image. This helps maintain a secure and reliable software supply chain.

Container images in the Azure registry should have vulnerability findings resolved. This recommendation is powered by Microsoft Defender Vulnerability Management and is currently in preview.

Scanning and remediating vulnerabilities for container images in the registry reduces the risk of security incidents. It also ensures compliance with industry standards.

Starting October 6, 2024, the recommendation for containers running in Azure was updated to report only a single container for each root controller. This change removes duplicate reporting for identical containers.

The assessment key for this recommendation was updated to c5045ea3-afc6-4006-ab8f-86c8574dbf3d. If you are currently retrieving vulnerability reports via API, you should change the API call to use the new assessment key.

Defender for Cloud creates an inventory of all container workloads currently running in your Kubernetes clusters and provides vulnerability reports for those workloads. Scanning and remediating vulnerabilities of container workloads is critical to ensure a robust and secure software supply chain.

Azure Container Registry (ACR) provides robust access control and permission management features to ensure secure access to your container registry.

You can disable the ACR Admin User from the Azure Portal to improve security.

To grant granular access control, use Role-Based Access Control (RBAC) to assign specific roles to identities, users, or principals.

Repository-scoped permissions enable even more granular control by scoping permissions directly to a repository inside the ACR.

Here are some key RBAC roles to consider:

To stay on top of RBAC assignments, regularly review and update access rights to ensure there's no delegated or inherited access.

By using managed identities, service principals, or users, you can achieve granular access control and improve auditability.

Azure Key Vault integration provides a secure key management process for your container registry.

Don't forget to enforce least privileges in runtime to reduce your exposure to risk.

By following these best practices, you can ensure secure access control and permissions for your Azure Container Registry.

Monitoring and logging are crucial components of Azure container security. You should regularly review activity logs for your container registry, such as the Azure Container Registry, to stay on top of things and identify any suspicious or erroneous activity.

To monitor container activity and user access, you can use Azure Monitor for containers, which provides performance visibility by collecting metrics from Kubernetes environments. This includes memory and processor metrics from controllers, nodes, and containers.

Monitoring resource activity, like files, network, and other resources that your containers access, is essential for both performance monitoring and security. You can collect metrics, activity logs, and diagnostic logs using Azure Monitor.

To maintain an accurate audit trail of administrative access to your container ecosystem, you can log all container administrative user access. This includes integrating Azure Kubernetes Service with Microsoft Defender for Cloud to monitor the security configuration of the cluster environment.

Azure solutions for logging and threat detection include the Azure Container Monitoring solution and Resource logs for Azure Container Instances and Azure Container Registry. You can also configure resource logs to send them to your own data sink, such as a storage account or log analytics workspace.

Here are some Azure solutions for monitoring and logging:

Diagnostic logs in Kubernetes services should be enabled and retained up to a year to enable activity trails for investigation purposes when a security incident occurs.

Maintaining network segmentation between running containers is crucial to protect them from security risks in other subnets. This is especially important for industries that need to meet compliance mandates.

You can use partner tools like Aqua to automate nano-segmentation, which monitors container network activities in runtime and identifies all inbound and outbound network connections.

Restricting access to the Kubernetes API server is also vital. This can be done by defining authorized IP ranges or setting up private clusters.

To avoid compromised containers from sniffing network traffic, we recommend not putting your pods on the host network.

Here are some ways to restrict pod access to the host network and ports:

Using a virtual network or firewall rule can help control traffic flow and protect your Azure Container Registry. This setup is also helpful for controlling entire traffic flow.

Content trust is a vital aspect of securing your container images. It enables you to verify the source and integrity of the images, ensuring they are the images you expect.

With content trust, you can sign your images as you're pushing them to the registry, and configure clients to only pull signed images from a trusted source with verified data integrity. This is especially important if your registries contain images with Intellectual Property, etc.

To implement a full-cycle content trust scenario, you'll need to follow the steps outlined in the official Microsoft docs: Content trust in Azure Container Registry.

Signing your images and verifying their integrity reduces the risk of unknown vulnerabilities, security issues, and malicious images being introduced into your Kubernetes cluster.

Sensor-based capabilities are a key part of Microsoft's approach to network and data security.

Defender for Containers provides a sensor-based capability that alerts you about potential security threats by detecting unauthorized external processes within containers.

This capability is particularly useful for distinguishing between legitimate activities and potential threats, which can be achieved by defining drift policies that specify conditions for generating alerts.

An agent is deployed to your Azure Kubernetes Service cluster to collect security event data when you enable the SecurityProfile.AzureDefender profile.

By doing so, you can gain valuable insights into your cluster's security posture and take proactive measures to prevent potential threats.

Using a firewall is an essential step in protecting your Azure Container Registry. By setting up a virtual network or firewall rule, you can control the entire traffic flow and prevent unauthorized access to your registry.

For example, you can use a virtual network to restrict access to your Azure Container Registry, as mentioned in Tip 11. This involves creating a virtual network and assigning a subnet to your registry. You can then configure the virtual network to allow access only from specific public IP addresses or address ranges.

Here are some key benefits of using a firewall with your Azure Container Registry:

By implementing these security measures, you can significantly reduce the risk of unauthorized access to your Azure Container Registry.

To ensure a secure certificate management process, consider using Azure Key Vault integration for customer certificates. This service provides a secure way to store and manage certificates.

Azure Key Vault safeguards encryption keys and secrets, including certificates, connection strings, and passwords, for containerized applications. This is especially crucial for sensitive and business-critical data.

Using a secure certificate management process helps protect credentials required for logins or API access, such as passwords or tokens. This is essential when containers can spread across several clusters and Azure regions.

Inventory all credential secrets and require developers to use emerging secrets-management tools designed for container platforms. This helps prevent unauthorized access to sensitive data.

Azure Key Vault includes features like encrypted databases and TLS encryption for secrets data in transit. This ensures that sensitive data is protected at rest and in transit.

You can securely access Azure resources using managed identities, which are tied to a specific resource and can be assigned permissions to other resources that support managed identities. This eliminates the need to create additional principals.

Managed identities provide granular access control with Role-Based Access Control (RBAC), enabling a specific service or resource direct access to what it needs. For example, an Azure Container Instance can be granted Reader access only.

Here are the key benefits of using managed identities:

Service Principals can also be used for authentication, providing granular access rights and read-only scenarios. They are ideal for headless applications running automated tasks.

Having a centralized identity and authentication system in place is crucial for managing access to your Azure resources. This allows you to control who can access what, and ensure that only authorized users or services can interact with your containers.

Azure provides a feature called Managed Identities that enables this centralized identity and authentication system. You can create a managed identity for a specific resource, such as an Azure Container Instance, and use it to authenticate with other Azure services without maintaining any secrets or credentials in code.

This feature is supported by Azure Container Registry, Azure Functions, Azure Web Apps, and other services that have support for identities. By using managed identities, you can enforce granular access controls and avoid the need for "one key to rule them all" approach.

Here are some key benefits of using a centralized identity and authentication system:

By implementing a centralized identity and authentication system, you can ensure that your Azure resources are secure and only accessible to authorized users or services.

You may need to use a customer-managed key (CMK) for encryption, especially if you're dealing with sensitive data like Intellectual Property.

Customer-managed keys are commonly required to meet regulatory compliance standards.

To enable customer-managed key encryption, navigate to your Security Policy for the applicable scope, and update the Effect parameter for the corresponding policy to audit or enforce the use of customer-managed keys.

Customer-managed keys enable you to encrypt data with an Azure Key Vault key created and owned by you, giving you full control and responsibility for the key lifecycle, including rotation and management.

Here are some key facts about customer-managed key encryption:

Using customer-managed keys can be beneficial, but it's essential to understand the responsibilities that come with managing the key lifecycle.

Secure your Azure Container Registry by ensuring that it's tight, especially if it contains images with Intellectual Property. This involves using a Security Development Lifecycle (SDL) and automating security code analysis.

To control access to your registry, use Role-Based Access Control (RBAC) and assign the 'Reader' role to identities/users/principals who should only pull images, but never modify or make other changes.

Here are some best practices for managing access:

Plan your security strategy with Microsoft Defender for Containers. This solution is in general availability (GA), but certain features are still in preview, so be sure to check the Containers support matrix in Defender for Cloud for the latest information.

To deploy the required components, you'll need to review the permissions for each of the components. This includes roles such as security admin, who can dismiss alerts, and security reader, who can view vulnerability assessment findings.

Microsoft Defender for Containers is billed according to the pricing page, so be sure to review that before getting started. The solution is available in multiple clouds, but you'll need to check the Containers support matrix in Defender for Cloud to see which ones are supported.

Here's a quick rundown of the required roles and permissions:

By planning your security strategy with Microsoft Defender for Containers, you can improve the odds of identifying and resolving security concerns before they become a bigger problem.

Sharing sensitive host namespaces with containers should be avoided to protect against privilege escalation outside the container. This is a crucial aspect of Kubernetes security.

Containers shouldn't run with privilege escalation to root in your Kubernetes cluster, as this can lead to serious security risks. The AllowPrivilegeEscalation attribute controls whether a process can gain more privileges than its parent process.

Running containers as root users in your Kubernetes cluster should be avoided, as it can make it easier for attackers to exploit misconfigurations. This is because running a process as the root user inside a container runs it as root on the host.

Privileged containers should be avoided whenever possible, as they have all of the root capabilities of a host machine and can be used as entry points for attacks. This can lead to the spread of malicious code or malware to compromised applications, hosts, and networks.

Secure Key Management Process is a crucial aspect of maintaining the security and integrity of your data.

DP-6 recommends using a secure key management process, which can be achieved by integrating Azure Key Vault for customer keys, secrets, or certificates.

To implement this, you should use Azure Key Vault to create and control the lifecycle of your encryption keys used for customer-managed key-based encryption for your container instance.

This approach provides a secure way to manage your keys, ensuring that your data remains protected at all times.

DP-7 also emphasizes the importance of secure certificate management, which can be achieved by integrating Azure Key Vault for customer certificates.

DP-5 suggests using customer-managed key option in data at rest encryption when required, which is especially important for regulatory compliance.

If you need to use customer-managed keys for encryption, define the use case and service scope where encryption using customer-managed keys are needed, and enable data at rest encryption using customer-managed key for those services.

Container registries should be encrypted with a customer-managed key (CMK) if required, as this provides an additional layer of security and control over your data.

By default, data is encrypted at rest with service-managed keys, but customer-managed keys (CMK) are commonly required to meet regulatory compliance standards.

You can enable customer-managed keys to manage the encryption at rest of the contents of your registries, giving you full control and responsibility for the key lifecycle, including rotation and management.

For external recommendations, consider following the lead of major tech companies like Google and Microsoft, which have implemented two-factor authentication across all their platforms.

Using a password manager like LastPass can help you generate and store unique, complex passwords for each of your online accounts.

Google's 2-Step Verification requires users to enter a verification code sent to their phone or email in addition to their password.

Ensuring the integrity of container images throughout their lifecycle is crucial for maintaining security. This involves several key practices.

Images with vulnerabilities, even minor ones, shouldn't be allowed to run in a production environment. Ideally, all images deployed in production should be saved in a private registry accessible to a select few. This helps prevent the spread of vulnerabilities.

To ensure the origin of software is known, build images from the source. This way, if a vulnerability surfaces in a self-built container image, customers can find a quicker path to a resolution. With a public image, customers would need to find the root of a public image to fix it or get another secure image from the publisher.

Regularly audit images deployed in production to identify images that are out of date or haven't been updated in a while. You might use blue-green deployment methodologies and rolling upgrade mechanisms to update container images without downtime.

Here are some key steps to ensure image integrity:

By following these best practices, you can ensure the integrity of your container images throughout their lifecycle and maintain a secure environment.