Azure Policies for Azure Kubernetes Service - Part 2

Azure Policies for Azure Kubernetes Service - Part 2

Introduction

In this part of my blog series on AKS Azure Policies we will look at the policies included in the Policy Initiative “Kubernetes cluster pod security baseline standards for Linux-based workloads”

Initiatives are a collection of policies for a common goal, this initiative contains 5 policies that Microsoft suggest should be applied to apply baseline security standard to Linux workloads. We will look at each policy individually and the default configuration suggested as part of the initiative.

For the Initiative and the majority of cluster focused policies there are a set of parameters that can be used to exclude or highlight specific Namespaces for policy assignment. By Default the following namespaces are excluded from the policy initiative kube-system; gatekeeper-system; azure-arc; azure-extensions-usage-system

By default effect for the initiative is Audit, to allow clusters to still function but to highlight non-compliance within Policy dashboards. Alternative effects can be used which include audit; Audit; deny; Deny; disabled; Disabled

Overview of Azure Policies contained within the Initiative

Kubernetes cluster should not allow privileged containers

Do not allow privileged containers creation in a Kubernetes cluster. This recommendation is part of CIS 5.2.1 which is intended to improve the security of your Kubernetes environments. This policy is generally available for Kubernetes Service (AKS), and preview for Azure Arc enabled Kubernetes. For more information, see https://aka.ms/kubepolicydoc.

By default allowing privileged containers is not advised, as they would have elevated permissions for performing actions on the host. The default behaviour for a kubernetes manifest is to have securityContext privileged set to false so any container that needs to run with the elevated permissions needs to be explicitly set within the manifest. If this is set within the manifest then Azure Policy will then flag the container is non-compliant.

Kubernetes cluster pods should only use approved host network and port range

Restrict pod access to the host network and the allowable host port range in a Kubernetes cluster. This recommendation is part of CIS 5.2.4 which is intended to improve the security of your Kubernetes environments. This policy is generally available for Kubernetes Service (AKS), and preview for Azure Arc enabled Kubernetes. For more information, see https://aka.ms/kubepolicydoc.

This policy ensure only explicit host network access is allowed, it can restrict access to the host network namespace to a range of host ports. Within the Kubernetes manifest he default configuration is for host network access to be disabled but if required you could add exceptions to the policy and add the required configuration to the manifest.

Kubernetes cluster containers should not share host process ID or host IPC namespace

Block pod containers from sharing the host process ID namespace and host IPC namespace in a Kubernetes cluster. This recommendation is part of CIS 5.2.2 and CIS 5.2.3 which are intended to improve the security of your Kubernetes environments. This policy is generally available for Kubernetes Service (AKS), and preview for Azure Arc enabled Kubernetes. For more information, see https://aka.ms/kubepolicydoc.

This policy ensure containers do not share the Host Process ID and Host IPC namespaces. This restrictions any communication between host and container processes. Isolating the processes to a container namespace adds a layer of security, any containers that requires this access could have an exception created as needed.

Kubernetes cluster containers should only use allowed capabilities

Restrict the capabilities to reduce the attack surface of containers in a Kubernetes cluster. This recommendation is part of CIS 5.2.8 and CIS 5.2.9 which are intended to improve the security of your Kubernetes environments. This policy is generally available for Kubernetes Service (AKS), and preview for Azure Arc enabled Kubernetes. For more information, see https://aka.ms/kubepolicydoc.

This policy ensure containers running in your AKS clusters are only granted linux capabilities needed to function e.g. NET_ADMIN or SYS_ADMIN. If these are not needed for you the operation of your cluster than adding this restriction minimises the attach surface reducing the chance of them being compromised.

Kubernetes cluster pod hostPath volumes should only use allowed host paths

Limit pod HostPath volume mounts to the allowed host paths in a Kubernetes Cluster. This policy is generally available for Kubernetes Service (AKS), and Azure Arc enabled Kubernetes. For more information, see https://aka.ms/kubepolicydoc.

This policy restricts access to the host file system for potential volume mounts. Giving access to the host file system is risky and keeping the access to a minimum it advised. By default the predefined list does not allow any file path. Where possible I would keep this the same. I would also switch the effect for this policy to deny to ensure that access is actually restricted rather than just auditing the access.

Further Reading