As with every new Kubernetes release there are a great number of new features, however there are a couple of key changes which could have impacts to security and are worth looking at in more details. In addition to the deprecation of PodSecurityPolicies, we’ll also look at some newly promoted features being put in place to block Kubernetes vulnerabilities and things like the new IPv6 support which will be one to take account of when designing cluster network security controls.
PodSecurityPolicy deprecation
PodSecurityPolicy (PSP) is a key control for Kubernetes clusters as it provides the mechanism to allow cluster operators to restrict rights available to workloads being deployed to the cluster. Without PSPs or a similar feature, it is trivial for any user who can deploy pods to a cluster, to get access to the underlying node and potentially to gain full control of the cluster.
As a feature, PSP has been in beta for a long time, and as part of an initiative to ensure that Kubernetes features are either graduated or deprecated it was decided that PSP would be deprecated.
The first thing that’s important to note about this deprecation is that it doesn’t mean that PSPs will stop working today. The current intention is not to remove the feature until at least Kubernetes 1.25 which won’t be scheduled until 2022 under current release timescales.
However, it’s a good time to start planning on replacement and how those will affect your workloads, and there are a number of options to replace PSP.
The first of these is the planned in-tree replacement for PSP. In short, the goal is to have a simple replacement admission controller which can provide validation against Kubernetes’ generic Pod Security Standards. We’ve covered some details on those in a previous blog “Kubernetes Pod Security Policy Deprecation: All You Need to Know”, and one of the things that should be noted from that, is that it’s likely that some workloads won’t be able to neatly fit into one of the policies that have been defined.
Where that’s the case you’ll need to look at more powerful options for policy enforcement, and there are a number of promising alternatives.
- Open Policy Agent – this is a powerful generic admission controller which allows for policies defined in Rego to be applied to Kubernetes clusters and other targets. The OPA project maintains a set of pre-baked rego templates which implement controls similar to those provided by PSP. Also, if you’re looking for good rego templates for OPA, Aqua’s AppShield is well worth a look.
- Kyverno – this is another choice which is attracting quite a lot of attention. The scope of the project is on Kubernetes policy specific, as contrasted to OPAs wider purview, and policies are written in YAML, which may provide an easier learning curve than OPAs rego based approach. Similarly to OPA, Kyverno provides a set of sample policies mapped to PSP restrictions.
- K-Rail is another workload policy enforcement tool, which has the intention to help secure multi-tenant clusters. It provides an in-built policy library and, as with the other two options available, provides an option for users to write their own policies.
If you’d like to get some more information about the PSP deprecation, there’s an excellent write-up on the Kubernetes Blog.
Admission controller to block external ServiceIPs
This is a useful additional admission controller which is being added to help mitigate a recent security issue in Kubernetes. CVE-2020-8554 allowed for a MITM attack for services external to the cluster, where an attacker could create a service in a Kubernetes cluster (so primarily a risk in multi-tenant clusters). The new admission controller will allow for the underlying feature to be disabled at a cluster level, removing the risk where the feature is not needed.
IPv4/IPv6 dual-stack support
An exciting change for this release is the graduation of IPv6 dual-stack support to beta. Beta graduation is an important milestone for Kubernetes features as it means that they are enabled by default, so all Kubernetes 1.21 clusters will have IPv6 enabled on them.
This will be an important one to make sure any network security features in your clusters (for example block or allow lists for connections) take account of IPv6 addresses. Whilst Kubernetes network policies shouldn’t usually be using hard coded IP addresses, there may be places where this kind of filter is in place and will need updated to account for additional addresses.
External client-go credential providers
Another interesting feature in the list of enhancements for 1.21 is the external client-go credential provider, which is graduating to stable. This feature allows for external helper programs to be used for user authentication, which helps when integrating Kubernetes with various Identity and Access Management systems.
There is one interesting security problem to be aware of with this feature though, which is that it’s important to read any Kubeconfig files you might want to use as, using this feature, the author of the Kubeconfig file can execute code on any user’s machine!
- name: external
user:
exec:
apiVersion: "client.authentication.k8s.io/v1beta1"
args:
- "/tmp/lorem"
command: "touch"
env: null
provideClusterInfo: false
Above is an example user block which uses this feature and you can see the “command” and “args” parameters. In the example above anyone using a Kubeconfig file with this user specified would create a file in /tmp called lorem. Whilst that example isn’t malicious, it would be fairly simple for an attacker to utilize it to compromise a client machine.
Conclusion
With the wide array of new features in this Kubernetes release, there’s quite a lot to consider for your clusters and it’s definitely time to be planning how you’ll be replacing PSPs. Trialling OPA and Kyverno, or waiting till the new in-built admission controller lands and seeing if that’ll meet your needs, and as ever we’ll be back here in three months when 1.22 lands and there’s another slew of exciting changes to look at.