Azure Policies for Azure Kubernetes Service - Part 3

Azure Policies for Azure Kubernetes Service - Part 3

Introduction

In the previous post in this blog series we looked at the “Kubernetes cluster pod security baseline standards for Linux-based workloads” policy initiative. Today we will be looking at the sister policy “Kubernetes cluster pod security restricted standards for Linux-based workloads”.

Initiatives are a collection of policies for a common goal, this initiative contains 8 policies that Microsoft suggest should be applied to apply restricted security standard to Linux workloads. We will look at each policy individually, however, there is some overlap with the previous initiative due to the similarities between the goals of the two initiatives. The following policies have previously been discussed in the earlier post.

  • Kubernetes cluster should not allow privileged containers
  • Kubernetes cluster pods should only use approved host network and port range
  • Kubernetes cluster containers should not share host process ID or host IPC namespace
  • Kubernetes cluster containers should only use allowed capabilities

Overview of Azure Policies contained within the Initiative

Like before, 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

Kubernetes clusters should not allow container privilege escalation

Do not allow containers to run with privilege escalation to root in a Kubernetes cluster. This recommendation is part of CIS 5.2.5 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 aligns with security best practices and standards, such as the Center for Internet Security (CIS) Kubernetes Benchmark. It helps ensure that your Kubernetes clusters adhere to these guidelines. By preventing containers from running with elevated privileges, you reduce the risk of malicious activities and vulnerabilities being exploited within your cluster. The policy ensures a user can not escalate to root within the running container.

Kubernetes cluster pods should only use allowed volume types

Pods can only use allowed volume types in a Kubernetes cluster. This policy is generally available for Kubernetes Service (AKS), and preview for Azure Arc enabled Kubernetes. For more information, see https://aka.ms/kubepolicydoc.

In Kubernetes, volumes are used to store data that is accessible to containers within a pod. Different volume types offer various features and levels of persistence, such as emptyDir, hostPath, persistentVolumeClaim. Some volume types, like hostPath, can expose the host filesystem to the pod, which can be a significant security risk if not properly managed.

Kubernetes cluster pods and containers should only run with approved user and group IDs

Control the user, primary group, supplemental group and file system group IDs that pods and containers can use to run in a Kubernetes Cluster. 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 enforces that all pods and containers in your Kubernetes cluster run with user and group IDs that are explicitly approved. This helps prevent unauthorized access and potential security breaches by ensuring that only designated users and groups can execute processes within the cluster.

Kubernetes cluster containers should only use allowed seccomp profiles

Pod containers can only use allowed seccomp profiles in a Kubernetes cluster. This policy is generally available for Kubernetes Service (AKS), and preview for Azure Arc enabled Kubernetes. For more information, see https://aka.ms/kubepolicydoc.

The Policy is designed to enhance the security of your Kubernetes environments by restricting the system calls that containers can make. Seccomp (Secure Computing Mode) is a Linux kernel feature that restricts the system calls a process can make. By using seccomp profiles, you can limit the actions that containers can perform, reducing the attack surface and enhancing security. This is crucial for protecting the host system and other containers from malicious activities

Further Reading