Weaveworks 2022.03 release featuring Magalix PaC | Learn more
Balance innovation and agility with security and compliance
risks using a 3-step process across all cloud infrastructure.
Step up business agility without compromising
security or compliance
Everything you need to become a Kubernetes expert.
Always for free!
Everything you need to know about Magalix
culture and much more
We all know running anything as root is bad practice. We also know giving an authorized user more access than necessary is also bad practice. In a Kubernetes world, credentials and permission are handled by RBAC (role-based access control). But what about the pods themselves? Did you know that unless specified, the process inside your container is most likely running as root? To top that off, if someone deploys a privileged pod, the container now has root access to the node it’s scheduled on. Sounds like a security risk, doesn’t it?
At the heart of your Cloud-Native stack is Kubernetes. As development teams gain more access to self-serve, it becomes increasingly challenging to monitor every single pod, or deployment that happens across your organization. Even if you had spare cycles, you would have to:
Checking these just once won’t be sufficient. There would be a need to continuously check for these configurations, across all of your clusters, all the time. Not to mention all the new microservices that will be developed this year, this month, and this sprint! Inspecting even one of the items on the aforementioned list all the time would not only be impossible, but unnecessary.
Used in conjunction with Kubernetes Role-Based Access Control (RBAC), Kubernetes Pod Security Policies (PSP) automatically perform the proper gatekeeping for pod admittance based on the policy you define. In other words, if it doesn’t meet your requirements, it doesn’t get scheduled.
Example-psp.yml
apiVersion: policy/v1betal
kind: PodSecurityPolicy
metadata:
name: example
spec:
privileged: false
seLinux:
rule: RunAsAny
supplementalGroup:
rule: RunAsAny
runAsUser:
rule: MustRunAsNonRoot
fsGroup:
rule: RunAsAny
volumes:
- ‘ * ’
A basic Pod Security Policy not allowing containers to run as rootPSPs require an RBAC role and binding (cluster role and binding can work too) that allows a service account permission to use the policy. It then applies the policies in alphabetical order based on the policy name.Once configured and enabled, the PSP will work in real time so you don’t have to go out of your way to police your pods. Using the code snippet above as an example, with this policy applied your development teams would have to explicitly define a user other than root if they wanted their pods to run. In their container, they would need to use a user other than root, and then specify that non-root user in the deployment. Since PSPs are cluster wide, you can set it for each cluster and not spend time worrying about governing any violations of these policies.
👇👇
Managing PSPs and RBAC can be complex.
If you don’t have everything set just correctly, you can prevent properly configured pods from deploying at all. A policy that is too restrictive may present challenges as some containers that are pulled from public registries are using the root user. In these cases, modification and upkeep will need to be maintained by you. If the upstream image changes, you will need to merge those changes into yours. The same challenges exist for Helm based deployments.
Another potential pitfall with PSPs is that testing your policies requires deploying them somewhere and validating them. To do this correctly, you would need to apply the same configurations from your live cluster to your test one. If you are managing different clusters for different teams, it might require additional cluster building automation and configuration management.
One last pitfall is managing multiple policies in one cluster. One obvious reason you might have multiple policies is that one type of pod needs more privileges than the others. A way to achieve mixing-and-matching is by crafting your RBAC policies, service accounts, and PSPs with specific workloads. Since PSPs are cluster wide, you’ll have to come up with your own strategy that best suits your requirements.
For the same reasons you don’t give out root access, you also need your containers to run without unnecessary privileges. Prevent your teams from unknowingly running containers with elevated permissions and configurations to help safeguard your Kubernetes cluster from within. The last thing you need right now is a rogue container deleting all the files on an NFS mount so enable PSPs today, so you won’t be restoring services tomorrow.
Empower developers to delivery secure and compliant software with trusted application delivery and policy as code. Learn more.
Automate your deployments with continuous application delivery and GitOps. Read this blog to learn more.
This article explains the differences between hybrid and multi-cloud model and how GitOps is an effective way of managing these approaches. Learn more.
Implement the proper governance and operational excellence in your Kubernetes clusters.
Comments and Responses