SnykSecKubernetes “crossed the adoption chasm” in 2021 after 5.6 million developers used it to orchestrate their containers, according to the Cloud Native Computing Federation (CNCF). The annual CNCF survey recorded that an impressive 96% of organizations were either contemplating or outright using Kubernetes.
However, Kubernetes becomes more appealing to hackers and malefactors as it becomes more popular. As developers flock to Kubernetes as the go-to container orchestration platform, they must also make sure to use it securely.
Kubernetes Pod Security Standards are a key way to maintain Kubernetes security, containing three cumulative policies spanning from completely strict to fairly open security measures. Let’s delve into what the Kubernetes Pod Security Standards are, examine how the Pod Security admission controller enforces the standards, and explore use cases for each policy.
What are Kubernetes Pod Security Standards?
Kubernetes Pod Security Standards are policies and guidelines to maintain container security and integrity in Kubernetes clusters. The standards define three different profiles with varying restrictions to ensure containerized workloads are secure against known privilege escalations and adhere to current best practices for Pod hardening:
- Privileged: Provides an entirely unrestricted policy.
- Baseline: Offers minimally-restrictive guardrails while preventing known privilege escalations.
- Restricted: Follows current Pod hardening best practices but may limit compatibility.
Adhering to these standards helps ensure that containerized applications meet industry-standard security requirements within Kubernetes environments. To accomplish this, Kubernetes offers a built-in Pod Security admission controller to check Pods’ isolation levels against these Pod Security Standards.
In previous Kubernetes versions, this was PodSecurityPolicy’s job. However, Kubernetes deprecated this feature in v1.21 and removed it entirely in v1.25. In a blog post, Kubernetes SIG Security explained that the original admission controller suffered “serious usability issues.” PodSecurityPolicy was confusing, prone to inadvertently granting permissions broader than intended, and made it challenging to inspect which permissions applied in a specific situation. Retrofitting PodSecurityPolicy to address these issues would have been a complex project that could break other features, which is why it was deprecated and replaced.
Pod Security Standards build on the standard levels from the deprecated PodSecurityPolicy, simplifying the switch for legacy systems using PodSecurityPolicy. The built-in Pod Security admission controller enforces those standards in clusters or namespaces.
Working with Pod Security admission controller
Once we enable the Pod Security admission controller and install the webhook, we can configure the admission control mode in our namespaces:
- Enforce: Rejects Pods with policy violations.
- Audit: Allows Pods with policy violations but includes an audit annotation in the audit log event record.
- Warn: Allows Pods with policy violations but warns users.
Configuring the Pod Security admission controller involves identifying two labels:
- Level: Privileged, baseline, or restricted.
- Mode: Enforce, audit, or warn.
Similarly, we can set multiple security checks on any namespace. We can also specify the version and check against the policy shipped with that specific Kubernetes minor version.
For example, if we want to know if the namespace “my-namespace” doesn’t meet the latest baseline version of the Pod Security Standards, we can set up this warning:
kubectl label --overwrite ns my-namespace \
pod-security.kubernetes.io/warn=baseline \
pod-security.kubernetes.io/warn-version=latest
And if we want to enforce “baseline” level security but be notified in the logs to audit the security level to see if we can meet the Restricted level standard, we can set it up like this:
kubectl label --overwrite ns my-namespace \
pod-security.kubernetes.io/enforce=baseline \
pod-security.kubernetes.io/enforce-version=latest
pod-security.kubernetes.io/audit=restricted \
pod-security.kubernetes.io/audit-version=latest
Using the Privileged security profile
Since the Privileged security profile allows for known privilege escalation, we should only use it in limited use cases where only trusted users perform critical infrastructure workloads.
The Privileged policy profile in Kubernetes Pod Security Standards offers unrestricted permissions necessary for managing sensitive workloads with the flexibility to perform complex tasks in critical systems. For instance, let’s imagine an organization that manages sensitive financial information. In this situation, privileged and trusted users must manage the organization’s system- and infrastructure-level workloads to ensure they’re secure.
While this kind of access is sometimes necessary, the organization should only grant open access to users who strictly need it within their roles. Using a more lenient approach like the Privileged profile makes it crucial to limit the permission scope.
It’s also important to include the Pod Security admission controller’s Restricted-level warning and audit modes when using a Privileged security profile. This approach actively warns users of each action’s status, and all event logs have audit annotations for relevant entries.
Finally, it’s critical to implement other best practices outside of Pod-specific measures. For instance, you might require multi-factor authentication (MFA) to mitigate the potential risks of granting broad permissions.
Using the Baseline security profile
The Baseline policy is perfect for application operators and developers of non-critical applications who want to secure their environment without making it too complex. Baseline policy lets users manage typical containerized workloads while still defending against known privilege escalations.
For example, let’s imagine that our example organization runs several non-critical microservices on its infrastructure to support its business operations. The Baseline policy profile helps ensure these workloads are secure without requiring significant additional effort from application operators or developers. The organization limits potential risks by implementing this minimally-restrictive security measure, preventing malicious attackers from gaining elevated privileges through vulnerabilities in container images or other attack vectors.
Say the example organization uses a third-party vendor service requiring read-only access to data stored in Kubernetes clusters. The Baseline Pod security policy restricts privileged access beyond what the vendor needs, and it denies unauthorized attempts by vendors (or anyone else) to escalate their permissions level beyond baseline requirements.
The Baseline security profile also offers flexibility for organizations with standard workloads, including APIs and web applications. These organizations won’t need additional configuration measures unless they find it necessary after further testing and analysis.
Importantly, the Baseline security profile is intentionally generic to cover a broad set of workloads. As a result, the Baseline profile often includes unhelpful restrictions for any particular use case. Instead of defaulting to the Privileged profile, since offering blanket root access would be insecure, you’ll likely need to configure some application-specific controls based on your particular use case.
Using the Restricted security profile
The Restricted policy profile is the most secure of the three, as it enforces current Pod hardening best practices.
Let’s say our example organization deploys several containerized workloads to process sensitive financial transactions. However, they also have legacy systems running non-containerized applications that don’t follow modern security standards. The Restricted Pod security policy ensures all containers adhere to best practices, including sandboxing, restricting user accounts, and controlling network privileges.
Through the Restricted security profile, application operators and developers of security-critical applications ensure, among other security measures, that:
- All containers running within a Pod are read-only.
- Linux capabilities are limited to those necessary for the container’s operation.
- Each container’s hostname is set explicitly using an environment variable.
- Resources like CPU and memory use per process in a container must be specified when creating Pods.
The secure Restricted policy profile offers greater transparency over potential attack surfaces, especially for organizations dealing with vulnerable workloads. The policy enforces current Pod hardening best practices to help protect against privilege escalations or other malicious activities.
You can achieve added security through layered protection mechanisms from various points, including reducing unnecessary application features outside core functions and employing advanced threat mitigation capabilities.
Working with Pod Security Standards
Kubernetes Pod Security Standards help developers keep their containerized applications secure within the Kubernetes environment. The three security profiles — Privileged, Baseline, and Restricted — vary in restrictions depending on user needs. The Pod Security admission controller enables these standards in clusters or namespaces by enforcing, auditing, or warning, depending on the level selected, and also lets you specify a version if desired.
Organizations can use Pod Security Standards to ensure compliance with industry-standard security requirements while protecting against potential privilege escalations and other malicious activities. Ultimately, employing Pod Security Standards via the Pod Security admission controller simplifies the development process while protecting any workloads running within Kubernetes clusters.
Once you’ve set up your Pod Security Standards in Kubernetes, explore how Snyk Container helps find and fix container vulnerabilities throughout the development process, providing insights and recommendations to keep your containers secure.
