Kubernetes Pod Security Best Practices

Kubernetes is an immensely popular container orchestration solution for many enterprises because it fundamentally reduces cloud-native infrastructure complexity while also offering new flexibility and security advantages.

Because the default security for the Kubernetes API is rather limited in scope, it is critical to follow industry security standards and run checks on your Kubernetes Pods.

In this guide, we will explore the importance of security checks for your Pods and the industry-recommended best practices you should follow.

Why Pod Security Should Be a Priority

Kubernetes Pods vulnerabilities, like those of other IT components, put your security at risk. A 2022 research report released by Sysdig reveals that:

• 75% of containers and images have worrisome but patchable leaks.
• 76% of container images are running as root.
• Obscene amounts of funds are being burnt on poor resource capacity planning.
• Short container lifespans are making tracking and auditing nearly impossible.

These results show that enterprises have not paid sufficient attention to Kubernetes hardening. While Kubernetes is a mature technology, widely adopted, and past the “hype peak”, there are still gaps in usage maturity. One sign of maturity is consistently adhering to security best practices for the technology.

If this gap exists for your team, now is the perfect time to start outlining best practices and running checks that can considerably minimize operational risks, insider threats, and malicious actor threats.

Blink Automation: Run Security Check on Your Kubernetes Pods

Blink + Kubernetes

Get Started

Best Practices for Kubernetes Pod Security

Kubernetes Pods are the smallest usable units with one or more containers. These units are usually what malicious actors work with soon after compromising a container. Pod security must therefore be reinforced to significantly make such compromises difficult and minimize the impact of successful attempts.

By adhering to these best practices, you will effectively seal cracks in Kubernetes Pod security and avert loss of property.

Deploying Non-Root Containers

Many container services and applications run with elevated root user access despite not requiring such privileges. If non-root containers are used, container services and applications can be denied root privileges for execution, thus minimizing the impact of malicious manipulation. As both non-root containers affect the runtime environment significantly, applications must be rigorously tested to ensure compatibility.

Container engines can allow applications to run as non-root users with group membership. Generally, this is a custom setting configured at image build-time. If applications are configured for non-root execution at build time, applications will assuredly function correctly without root privileges.

Deploying Immutable File Systems

Generally, container applications are allowed to run uninhibited within their own contexts. If a malicious actor succeeds in getting execute access to a container, they can create files, get scripts, and modify container applications. Kubernetes can help block access to a container’s file system, but genuine applications may crash or behave strangely. To prevent this, admins can mount other file systems for applications that require read/write access.

Deploying Trusted and Secure Container Images

A container image may have been generated by building a container right from scratch or on top of an image in a repository. Setting controls for a repository — such as those for admission and network access — can help restrict developers to only using trustworthy repositories.

Container image scanning can be used to ensure deployed containers are trusted and secure. While building containers, scanning images can help find obsolete files, leaks, or misconfigurations like unsecured ports and access permissions. Container image scanning can also help identify and disregard alerts of false leaks that cybersecurity experts consider inaccurate.

Using a Kubernetes admission controller is one way of implementing container image scanning. A custom or enterprise controller can be implemented to scan any image before it is deployed in the cluster. This controller can block using images that fail to comply with policies defined in the controller configuration.

Leveraging Pod Security Policies

Pod security policies (PSPs) are cluster-wide, minimum-qualification security resources that all Kubernetes Pods must satisfy to be allowed to execute applications in the cluster. PSPs can provide default values when a Pod’s configuration misses it and if required, can deny generation of non-compliant Pods. Kubernetes Pod security policies are applied as enabled admission controllers optionally, but if PSPs are left unauthorized, Pods will not get created in the cluster.

The Kubernetes PSP API, “PodSecurityPolicy,” has been deprecated and replaced with the simplified “PodSecurity” API, which is now recommended for use. The standard role-based access control mode can also be leveraged to authorize the use of PSPs.

The following Kubernetes PSP components are available to admins for setting Pod policy controls:

Automate Pod Security Checks with Blink:

To ensure Pod security, you can follow best practices but it can be a very manual time-intensive process to validate and find gaps. Instead of starting from scratch, there’s an easier way to do it.

When you create a free Blink account, you can immediately run pre-built automations that are designed to check for these best practices across your Kubernetes clusters.

Get started with Blink today to see how easy automation can be.