Kubernetes Pod Security Policy
While the Pod Security Policy was deprecated in Kubernetes v1.21, user surveys show that many Kubernetes environments are still running on 1.18. Hence, it is important to understand Kubernetes Pod Security Policy as well as its replacement, the Kubernetes Pod Security Standard. In this blog we will walk through the basics for each. It is best to understand this Kubernetes security principle in conjunction with broader Kubernetes security best practices.
A Kubernetes Pod Security Policy is a Kubernetes resource that enforces security standards by controlling how Pods can run on a cluster. It is used to define a set of conditions and actions that allow the creation of Pods or reject them. The Pod Admission Controller is responsible for implementing the policy by intercepting requests to create Pods and checking them against the policy's rules. For instance, if a pod admission controller detects that a user is trying to run a container with escalated privileges, it can prevent the creation of that Pod. This is true for the managed cloud providers as well, for example the GKE Pod Security Policy. To retrieve information about a Pod Security Policy in a Kubernetes environment, you can use the `kubectl get pod security policy` command or its abbreviated version `kubectl get psp`.
Pod Security Policy Deprecated
Kubernetes Pod Security Policy was a feature that allowed policies to be set for pod security standards. However, in the Kubernetes 1.21 release, pod security policy was officially deprecated. This means that there will be no more support or updates for it. Users attempting to use this feature might see an error message indicating no matches for kind "podsecuritypolicy" in version "policy/v1beta1."
If you need to disable Pod Security Policy entirely, you can set the admission control flag to "AlwaysAdmit" to bypass any validations. Kubernetes Pod migration requires careful consideration of the pods' security as well. Therefore, it is essential to review your respective clusters' pods security before, during, and after any migration operations to ensure your systems remain secure.
As an alternative, Kubernetes now recommends that users use the pod security standards and pod security admission controllers. These admission controllers provide flexibility and allow for the configuration of a pod's security context. A pod security context can now be used to set various security parameters such as access control and network policies.Users are encouraged to use the more flexible and extensible Pod Security Admission API.
Kubernetes Pod Security Standards
Kubernetes pod security standards are the recommended replacement for Kubernetes Pod Security Policy, specifying a set of policies with privileged, baseline or restrictive levels of permissions.
The Pod Security Standards define three security policies:
- Privileged: This is a fully open and unrestricted policy that provides the widest possible level of permissions.
- Baseline: A minimally restrictive policy that prevents known privilege escalations. It can easily be used in most cases.
- Restricted: Highly restrictive policy that follows all the pod hardening best practices. You may experience compatibility issues when using this policy and thus, it is recommended for security-critical applications and low-trust users.
A complete list of the security policies is available.
As their name implies, Pod Security Standards are just standards. You need to enforce them in Kubernetes through the use of Pod Security Admission. Pod security restrictions are applied at the namespace level when pods are created.
These policies cover the following Kubernetes controls and more:
- Host Namespaces
- Privileged Containers
- HostPath volumes
- Seccomp
- Volume Types
- Running as Non-root
Kubernetes Pod Security Admission
Kubernetes pod security admission is the recommended route of enforcing the Pod Security Standards. It is enabled by default in Kubernetes v1.23 and later and you donʼt need to install anything to make it work. You can use it to block violating resources from being created or allow them but warn your users accordingly.
To strengthen basic defense at the pod level, you can use the Pod Security admission controller with the most restrictive policy set.
The levels of enforcement, at the namespace level, include enforce, audit and warn. For more flexibility and granular control over pod security, consider something like an Open Policy Agent (OPA), using the OPA Gatekeeper project.
Or you can check out KSOC’s admission control capabilities if you want to be able to see how your environment might look if certain admission controls were enabled in block mode.
How to Apply Kubernetes Pod Security Admission
First, you need to examine the workloads in each namespace, understand their criticality, and decide on an appropriate level of security for each. Then, you must set the Pod Security label accordingly, to define the corresponding Pod Security Standard level. Labels have three or four parts: a prefix, a mode, and a level.
The prefix should always be pod- security.kubernetes.io followed by a / . The mode indicates the action that the control plane should take if a violation is detected. The actions can be:
- Enforce: violations will be blocked
- Audit: violations will be allowed but will appear in the audit log
- Warn: violations will be allowed but a warning will appear to the user
The level indicates which Pod Security Standard level will be used: privileged, baseline, or restricted. For example, a label can look like this: pod-security.kubernetes.io/enforce: baseline
Kubernetes Pod Security Context
Kubernetes Pod Security Context is a feature that defines security settings at the pod level.
It includes parameters like `runAsNonRoot`, `fsGroup`, `capabilities`, `allowPrivilegeEscalation` and so on. It can be set for both the containers and the deployment which helps to restrict the containers to only what they're supposed to do.
One can also set `privileged: true` to give full access to a container if required. However, this should only be done for applications that require administrative privileges.
`runAsNonRoot` specifies that the container should not have root access while running. This is very useful as it ensures that the container cannot perform malicious activities such as privilege escalation.
The `fsGroup` setting defines the group ID that will be associated with the container's files. The `capabilities` list also allows one to add or remove Linux capabilities from the container which improves the security of the pod.
Using Labels and Namespaces for Kubernetes Security Policies
You can use multiple labels in a namespace. For example, you can enforce the baseline policy, blocking any pods that donʼt meet its requirements and at the same time generate a user warning and add an audit record for pods that do not meet the restricted policy requirements.
This can be achieved by using the following two labels:
- pod-security.kubernetes.io/enforce: baseline
- pod-security.kubernetes.io/audit: restricted
You can use the audit and warn modes to collect useful security information about your pods without enforcing any restrictions. Consider enabling those modes for all namespaces for the desired security policy. This way, you can warn your users when they perform changes not allowed by this level, or just monitor such changes by using the audit mode. Similarly, you can set a warn mode at the same level as your enforce mode, so that your users will receive warning when creating pods that are not allowed. This way they can be more effective in updating the resources in order to become compliant.
Once you label a namespace, the policy will go into effect instantly. Do not leave namespaces without a PodSecurity label. Do so only to indicate that the namespace has not been evaluated yet. If you are just starting with the Pod Security Standard, a good idea is to configure all namespaces with a security label for a stricter level, such as baseline.
How to Create Least Privilege Access with Pod Security Admission
The least privilege principle applies when using the Pod Security Admission. You should apply the stricter possible security level, ideally the restricted one. However, this is rarely possible, or practical, as some workloads require elevated privileges.
Of course you may have cases where you need to create some pods that are not allowed by the policy which is applied to a namespace. You can create exemptions in the Admission Controller configuration. Exemptions can be based on:
- Usernames: requests from specified users will be ignored.
- RuntimeClassNames: pods and workload resources that specify a specific runtime class name are ignored.
- Namespaces: pods and workload resources in a specific namespace are ignored.
Pod Security Admission works only at the pods level.
How RAD Security Can Help Enforce Pod Security Standards
RAD Security provides admission control that can enforce pod security standards with a dry-run, or 'would block' option to help teams that are not yet comfortable turning admission control into enforce mode. Policies are transparent within the cluster so engineering teams don't have to leave their current toolsets to see admission control policies.
Conclusion
In conclusion, understanding Kubernetes Pod Security Policy and its replacement, the Kubernetes Pod Security Standard, is crucial for maintaining secure Kubernetes environments. Although Pod Security Policy has been deprecated, it is still important to review and address the security of existing environments running on older versions of Kubernetes. Kubernetes now recommends using the pod security standards and pod security admission controllers as an alternative.
