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.
Kubernetes Pod Security Policy
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. These policies cover the following Kubernetes controls and more:
- Host Namespaces
- Privileged Containers
- HostPath volumes
- Volume Types
- Running as Non-root
Kubernetes Pod Security Admission
Kubernetes pod security admission is the recommended route of enforcing the Pod Security Standards. 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.
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.
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.