Kubernetes Policy Engine, Polaris: A General Preview of New Checks

by Ivan Fetch on September 20, 2022

Polaris is an open source policy engine for Kubernetes that validates and remediates Kubernetes resources. It includes 30+ built in configuration policies and the ability to write custom policies using an intuitive JSON syntax.

We’ve worked to add additional checks to the Kubernetes policy engine. I’ll briefly preview new built-in Polaris checks that identify five areas where humans or workloads may have more Kubernetes access than is necessary. In future blog posts, I’ll provide in-depth summaries of each of these five new checks.

1. ServiceAccount Tokens are Automatically Mounted

The same Kubernetes API that humans interact with can also be accessed by workloads running in the cluster. Workloads may be granted Kubernetes permissions that allow inspection of unrelated Kubernetes resources, especially if they share a Kubernetes ServiceAccount. This check detects workloads that automatically have credentials that may be used to access the cluster. This is important to help prevent unauthorized access to clusters.

2. Accompanying NetworkPolicy

Using Kubernetes NetworkPolicy resources along with a supporting Container Network Interface (CNI) can firewall traffic between workloads and exiting the Kubernetes cluster. This access control helps ensure containers can communicate with required network resources, and cannot reach other networks. This check ensures there is a namespaced Kubernetes NetworkPolicy for each workload. This is important because firewalling workload inter-communication increases security.

3. Hardening of Linux Workloads

By default, a workload likely has more ability than is needed to run its application. Tuning these privileges minimizes the radius, speed, and impact of a container compromise. This check ensures a workload uses either AppArmor, dropping Linux capabilities, SELinux, or a seccomp profile to grant workloads the minimal privileges needed to function. This is important because minimizing a workload’s privileges also minimizes an attacker’s ability to gain access to other workloads or to your cluster.

Sponsorships Available

4. Exec or Attach to a Pod

By running a command inside of an existing container, additional code can be executed that grants deeper access to workloads or the cluster. It’s a good practice to limit the use of commands like “kubectl exec” or “kubectl debug” in production clusters. This check detects Role Based Access Control (RBAC) that allows exec or attaching to a container. This is important because limiting the ability to run other commands protect your workloads from unauthorized access or exfiltration.

5. Cluster Admin Permission

Granting administrative access to a Kubernetes cluster helps your team move faster in the beginning, but this decision extends opportunity and scope for potential attackers. This check helps achieve the security principle of least privilege by detecting Role Based Access Control (RBAC) that allows cluster admin permissions. This is important because cluster admin permissions should be granted sparingly, and used in break-glass situations.

If any of these new Polaris checks have piqued your interest, perhaps as part of your NSA Kubernetes Hardening journey, be on the lookout for future blog posts that will delve more into each check.