Azure security baseline for Azure Kubernetes Service

This security baseline applies guidance from the Azure Security Benchmark version 1.0 to Azure Kubernetes. The Azure Security Benchmark provides recommendations on how you can secure your cloud solutions on Azure. The content is grouped by the security controls defined by the Azure Security Benchmark and the related guidance applicable to Azure Kubernetes.

Note

Controls not applicable to Azure Kubernetes Service, or for which the responsibility is Microsoft's, have been excluded. To see how Azure Kubernetes Service completely maps to the Azure Security Benchmark, see the full Azure Kubernetes Service security baseline mapping file.

Network Security

For more information, see the Azure Security Benchmark: Network Security.

1.1: Protect Azure resources within virtual networks

Guidance: By default, a network security group and route table are automatically created with the creation of a Microsoft Azure Kubernetes Service (AKS) cluster. AKS automatically modifies network security groups for appropriate traffic flow as services are created with load balancers, port mappings, or ingress routes. The network security group is automatically associated with the virtual NICs on customer nodes and the route table with the subnet on the virtual network.

Use AKS network policies to limit network traffic by defining rules for ingress and egress traffic between Linux pods in a cluster based on choice of namespaces and label selectors. Network policy usage requires the Azure CNI plug-in with defined virtual network and subnets and can only be enabled at cluster creation. They cannot be deployed on an existing AKS cluster.

You can implement a private AKS cluster to ensure network traffic between your AKS API server and node pools remains only on the private network. The control plane or API server, resides in an AKS-managed Azure subscription and uses internal (RFC1918) IP addresses, while the customer's cluster or node pool is in their own subscription. The server and the cluster or node pool communicate with each other using the Azure Private Link service in the API server virtual network and a private endpoint that's exposed in the subnet of the customer's AKS cluster. Alternatively, use a public endpoint for the AKS API server but restrict access with the AKS API Server's Authorized IP Ranges feature.

Responsibility: Customer

Azure Security Center monitoring: The Azure Security Benchmark is the default policy initiative for Security Center and is the foundation for Security Center's recommendations. The Azure Policy definitions related to this control are enabled automatically by Security Center. Alerts related to this control may require an Azure Defender plan for the related services.

Azure Policy built-in definitions - Microsoft.ContainerService:

Name
(Azure portal)
Description Effect(s) Version
(GitHub)
Authorized IP ranges should be defined on Kubernetes Services Restrict access to the Kubernetes Service Management API by granting API access only to IP addresses in specific ranges. It is recommended to limit access to authorized IP ranges to ensure that only applications from allowed networks can access the cluster. Audit, Disabled 2.0.1

1.2: Monitor and log the configuration and traffic of virtual networks, subnets, and NICs

Guidance: Use Security Center and follow its network protection recommendations to secure the network resources being used by your Azure Kubernetes Service (AKS) clusters.

Enable network security group flow logs and send the logs to an Azure Storage account for auditing. You can also send the flow logs to a Log Analytics workspace and then use Traffic Analytics to provide insights into traffic patterns in your Azure cloud to visualize network activity, identify hot spots and security threats, understand traffic flow patterns, and pinpoint network misconfigurations.

Responsibility: Customer

Azure Security Center monitoring: None

1.3: Protect critical web applications

Guidance: Use an Azure Application Gateway enabled Web Application Firewall (WAF) in front of an AKS cluster to provide an additional layer of security by filtering the incoming traffic to your web applications. Azure WAF uses a set of rules, provided by The Open Web Application Security Project (OWASP), for attacks, such as, cross site scripting or cookie poisoning against this traffic.

Use an API gateway for authentication, authorization, throttling, caching, transformation, and monitoring for APIs used in your AKS environment. An API gateway serves as a front door to the microservices, decouples clients from your microservices, and decreases the complexity of your microservices by removing the burden of handling cross cutting concerns.

Responsibility: Customer

Azure Security Center monitoring: None

1.4: Deny communications with known malicious IP addresses

Guidance: Enable Microsoft Distributed Denial-of-service (DDoS) Standard protection on the virtual networks where Azure Kubernetes Service (AKS) components are deployed for protections against DDoS attacks.

Install the network policy engine and create Kubernetes network policies to control the flow of traffic between pods in AKS as, by default, all traffic is allowed between these pods. Network policy should only be used for Linux-based nodes and pods in AKS. Define rules that limit pod communication for improved security.

Choose to allow or deny traffic based on settings such as assigned labels, namespace, or traffic port. The required network policies can be automatically applied as pods are dynamically created in an AKS cluster.

Responsibility: Customer

Azure Security Center monitoring: None

1.5: Record network packets

Guidance: Use Network Watcher packet capture as required for investigating anomalous activity.

Network Watcher is enabled automatically in your virtual network's region when you create or update a virtual network in your subscription. You can also create new instances of Network Watcher using PowerShell, the Azure CLI, the REST API, or the Azure Resource Manager Client method

Responsibility: Customer

Azure Security Center monitoring: None

1.6: Deploy network-based intrusion detection/intrusion prevention systems (IDS/IPS)

Guidance: Secure your Azure Kubernetes Service (AKS) cluster with an Azure Application Gateway enabled with a Web Application Firewall (WAF).

If intrusion detection and/or prevention based on payload inspection or behavior analytics is not a requirement, an Azure Application Gateway with WAF can be used and configured in "detection mode" to log alerts and threats, or "prevention mode" to actively block detected intrusions and attacks.

Responsibility: Customer

Azure Security Center monitoring: None

1.8: Minimize complexity and administrative overhead of network security rules

Guidance: Use virtual network service tags to define network access controls on network security groups associated with Azure Kubernetes Service (AKS) instances. Service tags can be used in place of specific IP addresses when creating security rules to allow or deny the traffic for the corresponding service by specifying the service tag name.

Microsoft manages the address prefixes encompassed by the service tag and automatically updates the service tag as addresses change.

Apply an Azure tag to node pools in your AKS cluster. They are different than the virtual network service tags, and are applied to each node within the node pool and persist through upgrades.

Responsibility: Customer

Azure Security Center monitoring: None

1.9: Maintain standard security configurations for network devices

Guidance: Define and implement standard security configurations with Azure Policy for network resources associated with your Azure Kubernetes Service (AKS) clusters.

Use Azure Policy aliases in the "Microsoft.ContainerService" and "Microsoft.Network" namespaces to create custom policies to audit or enforce the network configuration of your AKS clusters.

Also, use built-in policy definitions related to AKS, such as:

  • Authorized IP ranges should be defined on Kubernetes Services

  • Enforce HTTPS ingress in Kubernetes cluster

  • Ensure services listen only on allowed ports in Kubernetes cluster

Additional information is available at the referenced links.

Responsibility: Customer

Azure Security Center monitoring: None

1.10: Document traffic configuration rules

Guidance: Use tags for network security groups and other resources for traffic flow to and from Azure Kubernetes Service (AKS) clusters. Use the "Description" field for individual network security group rules to specify business need and/or duration, and so on, for any rules that allow traffic to/from a network.

Use any of the built-in Azure Policy tagging-related definitions, for example, "Require tag and its value" that ensure that all resources are created with tags and to receive notifications for existing untagged resources.

Choose to allow or deny specific network paths within the cluster based on namespaces and label selectors with network policies. Use these namespaces and labels as descriptors for traffic configuration rules. Use Azure PowerShell or Azure command-line interface (CLI) to look up or perform actions on resources based on their tags.

Responsibility: Customer

Azure Security Center monitoring: None

1.11: Use automated tools to monitor network resource configurations and detect changes

Guidance: Use Azure Activity Log to monitor network resource configurations and detect changes for network resources related to Azure Kubernetes Service (AKS) clusters.

Create alerts within Azure Monitor that will trigger when changes to critical network resources take place. Any entries from the AzureContainerService user in the activity logs are logged as platform actions.

Use Azure Monitor logs to enable and query the logs from AKS the master components, kube-apiserver and kube-controller-manager. Create and manage the nodes that run the kubelet with container runtime and deploy their applications through the managed Kubernetes API server.

Responsibility: Customer

Azure Security Center monitoring: None

Logging and Monitoring

For more information, see the Azure Security Benchmark: Logging and Monitoring.

2.1: Use approved time synchronization sources

Guidance: Azure Kubernetes Service (AKS) nodes use ntp.ubuntu.com for time synchronization, along with UDP port 123 and Network Time Protocol (NTP).

Ensure NTP servers are accessible by the cluster nodes if using custom DNS servers.

Responsibility: Shared

Azure Security Center monitoring: None

2.2: Configure central security log management

Guidance: Enable audit logs from Azure Kubernetes Services (AKS) master components, kube-apiserver and kube-controller-manager, which are provided as a managed service.

  • kube-auditaksService: The display name in audit log for the control plane operation (from the hcpService)

  • masterclient: The display name in audit log for MasterClientCertificate, the certificate you get from az aks get-credentials

  • nodeclient: The display name for ClientCertificate, which is used by agent nodes

Enable other audit logs such as kube-audit as well.

Export these logs to Log Analytics or another storage platform. In Azure Monitor, use Log Analytics workspaces to query and perform analytics, and use Azure Storage accounts for long term and archival storage.

Enable and on-board this data to Azure Sentinel or a third-party SIEM based on your organizational business requirements.

Responsibility: Customer

Azure Security Center monitoring: None

2.3: Enable audit logging for Azure resources

Guidance: Use Activity logs to monitor actions on Azure Kubernetes Service (AKS) resources to view all activity and their status. Determine what operations were taken on the resources in your subscription with activity logs:

  • who started the operation
  • when the operation occurred
  • the status of the operation
  • the values of other properties that might help you research the operation

Retrieve information from the activity log through Azure PowerShell, the Azure Command Line Interface (CLI), the Azure REST API, or the Azure portal.

Enable audit logs on AKS master components, such as:

  • kube-auditaksService: The display name in audit log for the control plane operation (from the hcpService)

  • masterclient: The display name in audit log for MasterClientCertificate, the certificate you get from az aks get-credentials

  • nodeclient: The display name for ClientCertificate, which is used by agent nodes

Turn on other audit logs such as kube-audit as well.

Responsibility: Customer

Azure Security Center monitoring: None

2.4: Collect security logs from operating systems

Guidance: Enable automatic installation of Log Analytics agents for collecting data from the AKS cluster nodes. Also, turn-on automatic provisioning of the Azure Log Analytics Monitoring Agent from Azure Security Center, as by default, automatic provisioning is off. The agent can also be installed manually. With automatic provisioning on, Security Center deploys the Log Analytics agent on all supported Azure VMs and any new ones that are created. Security center collects data from Azure Virtual Machines (VM), virtual machine scale sets, and IaaS containers, such as Kubernetes cluster nodes, to monitor for security vulnerabilities and threats. Data is collected using the Azure Log Analytics Agent, which reads various security-related configurations and event logs from the machine and copies the data to your workspace for analysis.

Data collection is required to provide visibility into missing updates, misconfigured OS security settings, endpoint protection status, and health and threat detections.

Responsibility: Shared

Azure Security Center monitoring: None

2.5: Configure security log storage retention

Guidance: Onboard your Azure Kubernetes Service (AKS) instances to Azure Monitor and set the corresponding Azure Log Analytics workspace retention period according to your organization's compliance requirements.

Responsibility: Customer

Azure Security Center monitoring: None

2.6: Monitor and review Logs

Guidance: Onboard your Azure Kubernetes Service (AKS) instances to Azure Monitor and configure diagnostic settings for your cluster.

Use Azure Monitor's Log Analytics workspace to review logs and perform queries on log data. Azure Monitor logs are enabled and managed in the Azure portal, or through CLI, and work with both Kubernetes role-based access control (Kubernetes RBAC), Azure RBAC, and non-RBAC enabled AKS clusters.

View the logs generated by AKS master components (kube-apiserver and kube-controllermanager) for troubleshooting your application and services. Enable and on-board data to Azure Sentinel or a third-party SIEM for centralized log management and monitoring.

Responsibility: Customer

Azure Security Center monitoring: None

2.7: Enable alerts for anomalous activities

Guidance: Use Azure Kubernetes Service (AKS) together with Security Center to gain deeper visibility into AKS nodes.

Review Security Center alerts on threats and malicious activity detected at the host and at the cluster level. Security Center implements continuous analysis of raw security events occurring in an AKS cluster, such as network data, process creation, and the Kubernetes audit log. Determine if this activity is expected behavior or whether the application is misbehaving. Use metrics and logs in Azure Monitor to substantiate your findings.

Responsibility: Customer

Azure Security Center monitoring: None

2.8: Centralize anti-malware logging

Guidance: Install and enable Microsoft Anti-malware for Azure to Azure Kubernetes Service (AKS) virtual machines and virtual machine scale set nodes. Review alerts in Security Center for remediation.

Responsibility: Customer

Azure Security Center monitoring: None

2.9: Enable DNS query logging

Guidance: Azure Kubernetes Service (AKS) uses the CoreDNS project for cluster DNS management and resolution.

Enable DNS query logging by applying documented configuration in your coredns-custom ConfigMap.

Responsibility: Customer

Azure Security Center monitoring: None

2.10: Enable command-line audit logging

Guidance: Use kubectl, a command-line client, in Azure Kubernetes Service (AKS) to manage a Kubernetes cluster and get its logs from AKS node for troubleshooting purposes. Kubectl is already installed if you use Azure Cloud Shell. To install kubectl locally, use the 'Install-AzAksKubectl' cmdlet.

Responsibility: Customer

Azure Security Center monitoring: None

Identity and Access Control

For more information, see the Azure Security Benchmark: Identity and Access Control.

3.1: Maintain an inventory of administrative accounts

Guidance: Azure Kubernetes Service (AKS) itself does not provide an identity management solution which stores regular user accounts and passwords. With Azure Active Directory (Azure AD) integration, you can grant users or groups access to Kubernetes resources within a namespace or across the cluster.

Perform ad hoc queries to discover accounts that are members of AKS administrative groups with the Azure AD PowerShell module

Use Azure CLI for operations like ‘Get access credentials for a managed Kubernetes cluster’ to assist in reconciling access on a regular basis. Implement this process to keep an updated inventory of the service accounts, which are another primary user type in AKS. Enforce Security Center's Identity and Access Management recommendations.

Responsibility: Customer

Azure Security Center monitoring: None

3.2: Change default passwords where applicable

Guidance: Azure Kubernetes Service (AKS) does not have the concept of common default passwords and does not provide an identity management solution where regular user accounts and passwords can be stored. With Azure Active Directory (Azure AD) integration, you can grant role-based access to AKS resources within a namespace or across the cluster.

Perform ad hoc queries to discover accounts that are members of AKS administrative groups with the Azure AD PowerShell module

Responsibility: Customer

Azure Security Center monitoring: None

3.3: Use dedicated administrative accounts

Guidance: Integrate user authentication for your Azure Kubernetes Service (AKS) clusters with Azure Active Directory (Azure AD). Sign in to an AKS cluster using an Azure AD authentication token. Configure Kubernetes role-based access control (Kubernetes RBAC) for administrative access to Kubernetes configuration (kubeconfig) information and permissions, namespaces and cluster resources.

Create policies and procedures around the use of dedicated administrative accounts. Implement Security Center Identity and Access Management recommendations.

Responsibility: Customer

Azure Security Center monitoring: None

3.4: Use single sign-on (SSO) with Azure Active Directory

Guidance: Use single sign-on for Azure Kubernetes Service (AKS) with Azure Active Directory (Azure AD) integrated authentication for an AKS cluster.

Responsibility: Customer

Azure Security Center monitoring: None

3.5: Use multi-factor authentication for all Azure Active Directory based access

Guidance: Integrate Authentication for Azure Kubernetes Service (AKS) with Azure Active Directory (Azure AD).

Enable Azure AD multifactor authentication and follow Security Center's Identity and Access Management recommendations.

Responsibility: Customer

Azure Security Center monitoring: None

3.6: Use dedicated machines (Privileged Access Workstations) for all administrative tasks

Guidance: Use a Privileged Access Workstation (PAW), with Multi-Factor Authentication (MFA), configured to log into your specified Azure Kubernetes Service (AKS) clusters and related resources.

Responsibility: Customer

Azure Security Center monitoring: None

3.7: Log and alert on suspicious activities from administrative accounts

Guidance: Use Azure Active Directory (Azure AD) security reports with Azure AD-integrated authentication for Azure Kubernetes Service (AKS). Alerts can be generated when suspicious or unsafe activity occurs in the environment. Use Security Center to monitor identity and access activity.

Responsibility: Customer

Azure Security Center monitoring: None

3.8: Manage Azure resources only from approved locations

Guidance: Use Conditional Access Named Locations to allow access to Azure Kubernetes Service (AKS) clusters from only specific logical groupings of IP address ranges or countries/regions. This requires integrated authentication for AKS with Azure Active Directory (Azure AD).

Limit the access to the AKS API server from a limited set of IP address ranges, as it receives requests to perform actions in the cluster to create resources or scale the number of nodes.

Responsibility: Customer

Azure Security Center monitoring: None

3.9: Use Azure Active Directory

Guidance: Use Azure Active Directory (Azure AD) as the central authentication and authorization system for Azure Kubernetes Service (AKS). Azure AD protects data by using strong encryption for data at rest and in transit and salts, hashes, and securely stores user credentials.

Use the AKS built-in roles with Azure role-based access control (Azure RBAC) - Resource Policy Contributor and Owner, for policy assignment operations to your Kubernetes cluster

Responsibility: Customer

Azure Security Center monitoring: None

3.10: Regularly review and reconcile user access

Guidance: Use Azure Active Directory (Azure AD) security reports with Azure AD-integrated authentication for Azure Kubernetes Service (AKS). Search Azure AD logs to help discover stale accounts.

Perform Azure Identity Access Reviews to efficiently manage group memberships, access to enterprise applications, and role assignments. Remediate Identity and Access recommendations from Security Center.

Be aware of roles used for support or troubleshooting purposes. For example, any cluster actions taken by Microsoft support (with user consent) are made under a built-in Kubernetes "edit" role of the name aks-support-rolebinding. AKS support is enabled with this role to edit cluster configuration and resources to troubleshoot and diagnose cluster issues. However, this role cannot modify permissions nor create roles or role bindings. This role access is only enabled under active support tickets with just-in-time (JIT) access.

Responsibility: Customer

Azure Security Center monitoring: None

3.11: Monitor attempts to access deactivated credentials

Guidance: Integrate user authentication for Azure Kubernetes Service (AKS) with Azure Active Directory (Azure AD). Create Diagnostic Settings for Azure AD, sending the audit and sign-in logs to an Azure Log Analytics workspace. Configure desired Alerts (such as when a deactivated account attempts to log in) within an Azure Log Analytics workspace.

Responsibility: Customer

Azure Security Center monitoring: None

3.12: Alert on account login behavior deviation

Guidance: Integrate user authentication for Azure Kubernetes Service (AKS) with Azure Active Directory (Azure AD). Use Azure AD's Risk Detections and Identity Protection feature to configure automated responses to detected suspicious actions related to user identities. Ingest data into Azure Sentinel for further investigations based on business needs.

Responsibility: Customer

Azure Security Center monitoring: None

Data Protection

For more information, see the Azure Security Benchmark: Data Protection.

4.1: Maintain an inventory of sensitive Information

Guidance: Use tags on resources related to Azure Kubernetes Service (AKS) deployments to assist in tracking Azure resources that store or process sensitive information.

Responsibility: Customer

Azure Security Center monitoring: None

4.2: Isolate systems storing or processing sensitive information

Guidance: Logically isolate teams and workloads in the same cluster with Azure Kubernetes Service (AKS) to provide the least number of privileges, scoped to the resources required by each team.

Use the namespace in Kubernetes to create a logical isolation boundary. Consider implementing additional Kubernetes features for isolation and multi-tenancy, such as, scheduling, networking, authentication/authorization, and containers.

Implement separate subscriptions and/or management groups for development, test, and production environments. Separate AKS clusters with networking by deploying them to distinct virtual networks, which are tagged appropriately.

Responsibility: Customer

Azure Security Center monitoring: None

4.3: Monitor and block unauthorized transfer of sensitive information

Guidance: Use a third-party solution from Azure Marketplace on network perimeters that monitors for unauthorized transfer of sensitive information and blocks such transfers while alerting information security professionals.

Microsoft manages the underlying platform and treats all customer content as sensitive and goes to great lengths to guard against customer data loss and exposure. To ensure customer data within Azure remains secure, Microsoft has implemented and maintains a suite of robust data protection controls and capabilities.

Responsibility: Shared

Azure Security Center monitoring: None

4.4: Encrypt all sensitive information in transit

Guidance: Create an HTTPS ingress controller and use your own TLS certificates (or optionally, Let's Encrypt) for your Azure Kubernetes Service (AKS) deployments.

Kubernetes egress traffic is encrypted over HTTPS/TLS by default. Review any potentially un-encrypted egress traffic from your AKS instances for additional monitoring. This may include NTP traffic, DNS traffic, HTTP traffic for retrieving updates in some cases.

Responsibility: Customer

Azure Security Center monitoring: None

4.5: Use an active discovery tool to identify sensitive data

Guidance: Data identification, classification, and loss prevention features are not yet available for Azure Storage or compute resources. Implement third-party solution if required for compliance purposes. Microsoft manages the underlying platform and treats all customer content as sensitive and goes to great lengths to guard against customer data loss and exposure.

To ensure customer data within Azure remains secure, Microsoft has implemented and maintains a suite of robust data protection controls and capabilities.

Responsibility: Customer

Azure Security Center monitoring: None

4.6: Use Azure RBAC to manage access to resources

Guidance: Use the Azure role-based access control (Azure RBAC) authorization system built on Azure Resource Manager to provide fine-grained access management of Azure resources.

Configure Azure Kubernetes Service (AKS) to use Azure Active Directory (Azure AD) for user authentication. Sign in to an AKS cluster using Azure AD authentication token using this configuration.

Use the AKS built-in roles with Azure RBAC- Resource Policy Contributor and Owner, for policy assignment operations to your AKS cluster

Responsibility: Customer

Azure Security Center monitoring: The Azure Security Benchmark is the default policy initiative for Security Center and is the foundation for Security Center's recommendations. The Azure Policy definitions related to this control are enabled automatically by Security Center. Alerts related to this control may require an Azure Defender plan for the related services.

Azure Policy built-in definitions - Microsoft.ContainerService:

Name
(Azure portal)
Description Effect(s) Version
(GitHub)
Role-Based Access Control (RBAC) should be used on Kubernetes Services To provide granular filtering on the actions that users can perform, use Role-Based Access Control (RBAC) to manage permissions in Kubernetes Service Clusters and configure relevant authorization policies. Audit, Disabled 1.0.2

4.7: Use host-based data loss prevention to enforce access control

Guidance: Data identification, classification, and loss prevention features are not yet available for Azure Storage or compute resources. Implement third-party solution if required for compliance purposes. Microsoft manages the underlying platform and treats all customer content as sensitive and goes to great lengths to guard against customer data loss and exposure. To ensure customer data within Azure remains secure, Microsoft has implemented and maintains a suite of robust data protection controls and capabilities.

Responsibility: Customer

Azure Security Center monitoring: None

4.8: Encrypt sensitive information at rest

Guidance: The two primary types of storage provided for volumes in Azure Kubernetes Service (AKS) are backed by Azure Disks or Azure Files. Both types of storage use Azure Storage Service Encryption (SSE), which encrypts data at rest to improve security. By default, data is encrypted with Microsoft-managed keys.

Encryption-at-rest using customer-managed keys is available for encrypting both the OS and data disks on AKS clusters for additional control over encryption keys. Customers own the responsibility for key management activities such as key backup and rotation. Disks cannot currently be encrypted using Azure Disk Encryption at the AKS node level.

Responsibility: Shared

Azure Security Center monitoring: None

4.9: Log and alert on changes to critical Azure resources

Guidance: Use Azure Monitor for containers to monitor the performance of container workloads deployed to managed Kubernetes clusters hosted on Azure Kubernetes Service (AKS).

Configure alerts for proactive notification or log creation when CPU and memory utilization on nodes or containers exceed defined thresholds, or when a health state change occurs in the cluster at the infrastructure or nodes health rollup.

Use Azure Activity Log to monitor your AKS clusters and related resources at a high level. Integrate with Prometheus to view application and workload metrics it collects from nodes and Kubernetes using queries to create custom alerts, dashboards, and detailed perform detailed analysis.

Responsibility: Customer

Azure Security Center monitoring: None

Vulnerability Management

For more information, see the Azure Security Benchmark: Vulnerability Management.

5.1: Run automated vulnerability scanning tools

Guidance: Use Security Center to monitor your Azure Container Registry including Azure Kubernetes Service (AKS) instances for vulnerabilities. Enable the Container Registries bundle in Security Center to ensure that Security Center is ready to scan images that get pushed to the registry.

Get notified in the Security Center dashboard when issues are found after Security Center scans the image using Qualys. The Container Registries bundle feature provides deeper visibility into vulnerabilities of the images used in Azure Resource Manager based registries.

Use Security Center for actionable recommendations for every vulnerability. These recommendations include a severity classification and guidance for remediation.

Responsibility: Customer

Azure Security Center monitoring: None

5.2: Deploy automated operating system patch management solution

Guidance: Security updates are automatically applied to Linux nodes to protect customer's Azure Kubernetes Service (AKS) clusters. These updates include OS security fixes or kernel updates.

Note that the process to keep Windows Server nodes up to date differs from nodes running Linux as windows server nodes don't receive daily updates. Instead, customers need to perform an upgrade on the Windows Server node pools in their AKS clusters which deploys new nodes with the latest base Window Server image and patches using Azure control panel or the Azure CLI. These updates contain security or functionality improvements to AKS.

Responsibility: Customer

Azure Security Center monitoring: None

5.3: Deploy an automated patch management solution for third-party software titles

Guidance: Implement a manual process to ensure Azure Kubernetes Service (AKS) cluster node's third-party applications remain patched for the duration of the cluster lifetime. This may require enabling automatic updates, monitoring the nodes, or performing periodic reboots.

Responsibility: Customer

Azure Security Center monitoring: The Azure Security Benchmark is the default policy initiative for Security Center and is the foundation for Security Center's recommendations. The Azure Policy definitions related to this control are enabled automatically by Security Center. Alerts related to this control may require an Azure Defender plan for the related services.

Azure Policy built-in definitions - Microsoft.ContainerService:

Name
(Azure portal)
Description Effect(s) Version
(GitHub)
Kubernetes Services should be upgraded to a non-vulnerable Kubernetes version Upgrade your Kubernetes service cluster to a later Kubernetes version to protect against known vulnerabilities in your current Kubernetes version. Vulnerability CVE-2019-9946 has been patched in Kubernetes versions 1.11.9+, 1.12.7+, 1.13.5+, and 1.14.0+ Audit, Disabled 1.0.2

5.4: Compare back-to-back vulnerability scans

Guidance: Export Security Center scan results at consistent intervals and compare the results to verify that vulnerabilities have been remediated.

Use the PowerShell cmdlet "Get-AzSecurityTask" to automate the retrieval of security tasks that Security Center recommends you to perform in order to strengthen your security posture and remediation vulnerability scan findings.

Responsibility: Customer

Azure Security Center monitoring: None

5.5: Use a risk-rating process to prioritize the remediation of discovered vulnerabilities

Guidance: Use the severity rating provided by Security Center to prioritize the remediation of vulnerabilities.

Use Common Vulnerability Scoring System (CVSS) (or another scoring systems as provided by your scanning tool) if using a built-in vulnerability assessment tool (such as Qualys or Rapid7, offered by Azure).

Responsibility: Customer

Azure Security Center monitoring: None

Inventory and Asset Management

For more information, see the Azure Security Benchmark: Inventory and Asset Management.

6.1: Use automated asset discovery solution

Guidance: Use Azure Resource Graph to query/discover all resources (such as compute, storage, network, and so on) within your subscriptions. Ensure that you have appropriate (read) permissions in your tenant and are able to enumerate all Azure subscriptions as well as resources within your subscriptions.

Although classic Azure resources may be discovered via Resource Graph, it is highly recommended to create and use Azure Resource Manager-based resources going forward.

Responsibility: Customer

Azure Security Center monitoring: None

6.2: Maintain asset metadata

Guidance: Apply tags to Azure resources with metadata to logically organize them into a taxonomy.

Responsibility: Customer

Azure Security Center monitoring: None

6.3: Delete unauthorized Azure resources

Guidance: Use tagging, management groups, and separate subscriptions, where appropriate, to organize and track assets.

Apply taints, labels, or tags when creating an Azure Kubernetes Service (AKS) node pool. All nodes within that node pool will also inherit that taint, label, or tag.

Taints, labels or tags can be used to reconcile inventory on a regular basis and ensure unauthorized resources are deleted from subscriptions in a timely manner.

Responsibility: Customer

Azure Security Center monitoring: None

6.4: Define and maintain an inventory of approved Azure resources

Guidance: Define a list of approved Azure resources and approved software for compute resources based on organizational business needs.

Responsibility: Customer

Azure Security Center monitoring: None

6.5: Monitor for unapproved Azure resources

Guidance: Use Azure Policy to put restrictions on the type of resources that can be created in customer subscriptions using the following built-in policy definitions:

  • Not allowed resource types

  • Allowed resource types

Use Azure Resource Graph to query/discover resources within your subscriptions. Ensure that all Azure resources present in the environment are approved based on organizational business requirements.

Responsibility: Customer

Azure Security Center monitoring: None

6.6: Monitor for unapproved software applications within compute resources

Guidance: Use Azure Automation Change Tracking and Inventory features to find out software that is installed in your environment.

Collect and view inventory for software, files, Linux daemons, Windows services, and Windows Registry keys on your computers and monitor for unapproved software applications.

Track the configurations of your machines to aid in pinpointing operational issues across your environment and better understand the state of your machines.

Responsibility: Customer

Azure Security Center monitoring: None

6.7: Remove unapproved Azure resources and software applications

Guidance: Use Azure Automation Change Tracking and Inventory features to find out software that is installed in your environment.

Collect and view inventory for software, files, Linux daemons, Windows services, and Windows Registry keys on your computers and monitor for unapproved software applications.

Track the configurations of your machines to aid in pinpointing operational issues across your environment and better understand the state of your machines.

Responsibility: Customer

Azure Security Center monitoring: None

6.8: Use only approved applications

Guidance: Use Azure Automation Change Tracking and Inventory features to find out software that is installed in your environment.

Collect and view inventory for software, files, Linux daemons, Windows services, and Windows Registry keys on your computers and monitor for unapproved software applications.

Track the configurations of your machines to aid in pinpointing operational issues across your environment and better understand the state of your machines.

Enable Adaptive Application analysis in Security Center for applications which exist in your environment.

Responsibility: Customer

Azure Security Center monitoring: None

6.9: Use only approved Azure services

Guidance: Use Azure Policy to put restrictions on the type of resources that can be created in customer subscriptions using the following built-in policy definitions:

  • Not allowed resource types

  • Allowed resource types

Use Azure Resource Graph to query/discover resources within your subscriptions. Ensure that all Azure resources present in the environment are approved.

Responsibility: Customer

Azure Security Center monitoring: None

6.10: Maintain an inventory of approved software titles

Guidance: Use Azure Policy to put restrictions on the type of resources that can be created in your subscriptions using built-in policy definitions.

Responsibility: Customer

Azure Security Center monitoring: None

6.11: Limit users' ability to interact with Azure Resource Manager

Guidance: Use Azure Conditional Access to limit users' ability to interact with Azure Resource Manager by configuring "Block access" for the "Microsoft Azure Management" App.

Responsibility: Customer

Azure Security Center monitoring: None

6.12: Limit users' ability to execute scripts in compute resources

Guidance: Azure Kubernetes Service (AKS) itself doesn't provide an identity management solution where regular user accounts and passwords are stored. Instead, use Azure Active Directory (Azure AD) as the integrated identity solution for your AKS clusters.

Grant users or groups access to Kubernetes resources within a namespace or across the cluster using Azure AD integration.

Use the Azure AD PowerShell module to perform ad hoc queries to discover accounts that are members of your AKS administrative groups and use it to reconcile access on a regular basis. Use Azure CLI for operations such as ‘Get access credentials for a managed Kubernetes cluster. Implement Security Center Identity and Access Management recommendations.

Responsibility: Customer

Azure Security Center monitoring: None

6.13: Physically or logically segregate high risk applications

Guidance: Use Azure Kubernetes Service (AKS) features to logically isolate teams and workloads in the same cluster for the least number of privileges, scoped to the resources required by each team.

Implement namespace in Kubernetes to create a logical isolation boundary. Use Azure Policy aliases in the "Microsoft.ContainerService" namespace to create custom policies to audit or enforce the configuration of your Azure Kubernetes Service (AKS) instances.

Review and implement additional Kubernetes features and considerations for isolation and multi-tenancy to include the following: scheduling, networking, authentication/authorization, and containers. Also use separate subscriptions and management groups for development, test, and production. Separate AKS clusters with virtual networks, subnets which are tagged appropriately, and secured with a Web Application Firewall (WAF).

Responsibility: Customer

Azure Security Center monitoring: None

Secure Configuration

For more information, see the Azure Security Benchmark: Secure Configuration.

7.1: Establish secure configurations for all Azure resources

Guidance: Use Azure Policy aliases in the "Microsoft.ContainerService" namespace to create custom policies to audit or enforce the configuration of your Azure Kubernetes Service (AKS) instances. Use built-in Azure Policy definitions.

Examples of built-in policy definitions for AKS include:

  • Enforce HTTPS ingress in Kubernetes cluster

  • Authorized IP ranges should be defined on Kubernetes Services

  • Role-based Access Control (RBAC) should be used on Kubernetes Services

  • Ensure only allowed container images in Kubernetes cluster

Export a template of your AKS configuration in JavaScript Object Notation (JSON) with Azure Resource Manager. Review it periodically to ensure that these configurations meet the security requirements for your organization. Use the recommendations from Azure Security Center as a secure configuration baseline for your Azure resources.

Responsibility: Customer

Azure Security Center monitoring: None

7.2: Establish secure operating system configurations

Guidance: Azure Kubernetes Clusters (AKS) clusters are deployed on host virtual machines with a security optimized OS. The host OS has additional security hardening steps incorporated into it to reduce the surface area of attack and allows the deployment of containers in a secure fashion.

Azure applies daily patches (including security patches) to AKS virtual machine hosts with some patches requiring a reboot. Customers are responsible for scheduling AKS Virtual Machine host reboots as per need.

Responsibility: Shared

Azure Security Center monitoring: None

7.3: Maintain secure Azure resource configurations

Guidance: Secure your Azure Kubernetes Service (AKS) cluster using pod security policies. Limit what pods can be scheduled to improve the security of your cluster.

Pods which request resources that are not allowed cannot run in the AKS cluster.

Also use Azure Policy [deny] and [deploy if not exist] effects to enforce secure settings for the Azure resources related to your AKS deployments (such as Virtual Networks, Subnets, Azure Firewalls, Storage Accounts, and so on).

Create custom Azure Policy definitions using aliases from the following namespaces:

  • Microsoft.ContainerService

  • Microsoft.Network

Additional information is available at the referenced links.

Responsibility: Customer

Azure Security Center monitoring: None

7.4: Maintain secure operating system configurations

Guidance: Azure Kubernetes Service (AKS) clusters are deployed on host virtual machines with a security optimized OS. The host OS has additional security hardening steps incorporated into it to reduce the surface area of attack and allows the deployment of containers in a secure fashion.

Refer to the list of Center for Internet Security (CIS) controls which are built into the host OS.

Responsibility: Customer

Azure Security Center monitoring: None

7.5: Securely store configuration of Azure resources

Guidance: Use Azure Repos to securely store and manage your configurations if using custom Azure Policy definitions. Export a template of your Azure Kubernetes Service (AKS) configuration in JavaScript Object Notation (JSON) with Azure Resource Manager. Periodically review it to ensure that the configurations meet the security requirements for your organization.

Implement third-party solutions such as Terraform to create a configuration file that declares the resources for the Kubernetes cluster. You can harden your AKS deployment by Implement security best practices and store your configuration as code in a secured location.

Responsibility: Customer

Azure Security Center monitoring: None

7.6: Securely store custom operating system images

Guidance: Not applicable to Azure Kubernetes Service (AKS). AKS provides a security optimized host Operating System (OS) by default. There is no current option to select an alternate or custom operating system.

Responsibility: Customer

Azure Security Center monitoring: None

7.7: Deploy configuration management tools for Azure resources

Guidance: Use Azure Policy to put restrictions on the type of resources that can be created in subscriptions using built-in policy definitions as well as Azure Policy aliases in the "Microsoft.ContainerService" namespace.

Create custom policies to audit, and enforce system configurations. Develop a process and pipeline for managing policy exceptions.

Responsibility: Customer

Azure Security Center monitoring: None

7.8: Deploy configuration management tools for operating systems

Guidance: Azure Kubernetes Service (AKS) clusters are deployed on host virtual machines with a security optimized OS. The host OS has additional security hardening steps incorporated into it to reduce the surface area of attack and allows the deployment of containers in a secure fashion.

Refer to the list of Center for Internet Security (CIS) controls which are built into AKS hosts.

Responsibility: Customer

Azure Security Center monitoring: None

7.9: Implement automated configuration monitoring for Azure resources

Guidance: Use Security Center to perform baseline scans for resources related to your Azure Kubernetes Service (AKS) deployments. Examples resources include but are not limited to the AKS cluster itself, the virtual network where the AKS cluster was deployed, the Azure Storage Account used to track Terraform state, or Azure Key Vault instances being used for the encryption keys for your AKS cluster's OS and data disks.

Responsibility: Customer

Azure Security Center monitoring: None

7.10: Implement automated configuration monitoring for operating systems

Guidance: Use Security Center container recommendations under the "Compute & apps" section to perform baseline scans for your Azure Kubernetes Service (AKS) clusters.

Get notified in the Security Center dashboard when configuration issues or vulnerabilities are found. This does require enabling the optional Container Registries bundle which allows Security Center to scan the image.

Responsibility: Customer

Azure Security Center monitoring: None

7.11: Manage Azure secrets securely

Guidance: Integrate Azure Key Vault with an Azure Kubernetes Service (AKS) cluster using a FlexVolume drive. Use Azure Key Vault to store and regularly rotate secrets such as credentials, storage account keys, or certificates. The FlexVolume driver lets the AKS cluster natively retrieve credentials from Key Vault and securely provide them only to the requesting pod. Use a pod managed identity to request access to Key Vault and retrieve the required credentials through the FlexVolume driver. Ensure Key Vault Soft Delete is enabled.

Limit credential exposure by not defining credentials in your application code.

Avoid the use of fixed or shared credentials.

Responsibility: Customer

Azure Security Center monitoring: None

7.12: Manage identities securely and automatically

Guidance: Do not define credentials in your application code as a security best practice. Use managed identities for Azure resources to let a pod authenticate itself against any service in Azure that supports it, including Azure Key Vault. The pod is assigned an Azure Identity to authenticate to Azure Active Directory (Azure AD) and receive a digital token which can be presented to other Azure services that check if the pod is authorized to access the service and perform the required actions.

Note that Pod managed identities are intended for use with Linux pods and container images only. Provision Azure Key Vault to store and retrieve digital keys and credentials. Keys such as the ones used to encrypt OS disks, AKS cluster data can be stored in Azure Key Vault.

Service principals can also be used in AKS clusters. However, clusters using service principals eventually may reach a state in which the service principal must be renewed to keep the cluster working. Managing service principals adds complexity, which is why it's easier to use managed identities instead. The same permission requirements apply for both service principals and managed identities.

Responsibility: Customer

Azure Security Center monitoring: None

7.13: Eliminate unintended credential exposure

Guidance: Implement Credential Scanner to identify credentials within code. Credential Scanner also encourages moving discovered credentials to more secure locations such as Azure Key Vault with recommendations.

Limit credential exposure by not defining credentials in your application code. and avoid the use of shared credentials. Azure Key Vault should be used to store and retrieve digital keys and credentials. Use managed identities for Azure resources to let your pod request access to other resources.

Responsibility: Customer

Azure Security Center monitoring: None

Malware Defense

For more information, see the Azure Security Benchmark: Malware Defense.

8.1: Use centrally managed antimalware software

Guidance: AKS manages the lifecycle and operations of agent nodes on your behalf - modifying the IaaS resources associated with the agent nodes is not supported. However, for Linux nodes you may use daemon sets to install custom software like an anti-malware solution.

Responsibility: Shared

Azure Security Center monitoring: None

8.2: Pre-scan files to be uploaded to non-compute Azure resources

Guidance: Pre-scan any files being uploaded to your AKS resources. Use Security Center's threat detection for data services to detect malware uploaded to storage accounts if using an Azure Storage Account as a data store or to track Terraform state for your AKS cluster.

Responsibility: Customer

Azure Security Center monitoring: None

8.3: Ensure antimalware software and signatures are updated

Guidance: AKS manages the lifecycle and operations of agent nodes on your behalf - modifying the IaaS resources associated with the agent nodes is not supported. However, for Linux nodes you may use daemon sets to install custom software like an anti-malware solution.

Responsibility: Shared

Azure Security Center monitoring: None

Data Recovery

For more information, see the Azure Security Benchmark: Data Recovery.

9.1: Ensure regular automated back ups

Guidance: Back up your data using an appropriate tool for your storage type such as Velero, which can back up persistent volumes along with additional cluster resources and configurations. Periodically, verify the integrity, and security, of those backups.

Remove state from your applications prior to backup. In cases where this cannot be done, back up the data from persistent volumes and regularly test the restore operations to verify data integrity and the processes required.

Responsibility: Customer

Azure Security Center monitoring: None

9.2: Perform complete system backups and backup any customer-managed keys

Guidance: Back up your data using an appropriate tool for your storage type such as Velero, which can back up persistent volumes along with additional cluster resources and configurations.

Perform regular automated backups of Key Vault Certificates, Keys, Managed Storage Accounts, and Secrets, with PowerShell commands.

Responsibility: Customer

Azure Security Center monitoring: None

9.3: Validate all backups including customer-managed keys

Guidance: Periodically perform data restoration of content within Velero Backup. If necessary, test restoring to an isolated virtual network.

Periodically perform data restoration of Key Vault Certificates, Keys, Managed Storage Accounts, and Secrets, with PowerShell commands.

Responsibility: Customer

Azure Security Center monitoring: None

9.4: Ensure protection of backups and customer-managed keys

Guidance: Back up your data using an appropriate tool for your storage type such as Velero, which can back up persistent volumes along with additional cluster resources and configurations.

Enable Soft-Delete in Key Vault to protect keys against accidental or malicious deletion if Azure Key Vault is being used with for Azure Kubernetes Service (AKS) deployments.

Responsibility: Customer

Azure Security Center monitoring: None

Incident Response

For more information, see the Azure Security Benchmark: Incident Response.

10.1: Create an incident response guide

Guidance: Build out an incident response guide for your organization. Ensure that there are written incident response plans that define all roles of personnel as well as phases of incident handling/management from detection to post-incident review.

Responsibility: Customer

Azure Security Center monitoring: None

10.2: Create an incident scoring and prioritization procedure

Guidance: Prioritize which alerts must be investigated first with Security Center assigned severity to alerts. The severity is based on how confident Security Center is in the finding or the analytics used to issue the alert as well as the confidence level that there was malicious intent behind the activity that led to the alert. Clearly mark subscriptions (for example, production, non-production) and create a naming system to clearly identify and categorize Azure resources.

Responsibility: Customer

Azure Security Center monitoring: None

10.3: Test security response procedures

Guidance: Conduct exercises to test your systems’ incident response capabilities at a regular cadence. Identify weak points and gaps and revise incident response plans as needed.

Responsibility: Customer

Azure Security Center monitoring: None

10.4: Provide security incident contact details and configure alert notifications for security incidents

Guidance: Security incident contact information will be used by Microsoft to contact you if the Microsoft Security Response Center (MSRC) discovers that the customer's data has been accessed by an unlawful or unauthorized party.

Review incidents, after the fact, to ensure that issues are resolved.

Responsibility: Customer

Azure Security Center monitoring: None

10.5: Incorporate security alerts into your incident response system

Guidance: Export Security Center alerts and recommendations using its Continuous Export feature. Continuous Export allows you to export alerts and recommendations either manually or in an ongoing, continuous fashion.

Choose the Security Center data connector to stream the alerts to Azure Sentinel, as per need and based on organizational business requirements.

Responsibility: Customer

Azure Security Center monitoring: None

10.6: Automate the response to security alerts

Guidance: Use the Workflow Automation feature in Security Center to automatically trigger responses via "Logic Apps" on security alerts and recommendations.

Responsibility: Customer

Azure Security Center monitoring: None

Penetration Tests and Red Team Exercises

For more information, see the Azure Security Benchmark: Penetration Tests and Red Team Exercises.

11.1: Conduct regular penetration testing of your Azure resources and ensure remediation of all critical security findings

Guidance: Follow the Microsoft Rules of Engagement to ensure your Penetration Tests are not in violation of Microsoft policies. Additional information on Microsoft’s strategy and execution of Red Teaming and live site penetration testing against Microsoft-managed cloud infrastructure, services, and applications, at the referenced links.

Responsibility: Shared

Azure Security Center monitoring: None

Next steps