Intro
Kubernetes Security Policy is a combination of Kubernetes admission control, Pod Security Policies and Pod Security Standards. While Pod Security Policies have been deprecated as of Kubernetes v1.21, it is possible many teams are still running it, as not every Kubernetes environment is completely up to date, so it is still useful to include. These capabilities are all a critical part of limiting access to third parties and creating a least privilege environment for your Kubernetes clusters.
Kubernetes Pod Security Standards
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.
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
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.
What is Pod Security Admission
Pod Security Admission is a very easy way to enforce a specific security level in your pods. 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.
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.
Conclusion
As we have discussed in this post, there are numerous security issues you need to consider when it comes to Kubernetes security policies. In addition to pod security admission, the Pod Security Standards describe three, very specific security profiles. You must enforce one of those three, which can be rather restrictive in terms of the available options that you have. You cannot add custom controls, or remove other controls that you donʼt wish to enforce. Even exemptions work in a very limited way.
