Have you been struggling to adopt Kubernetes Pod Security Standards? Monokle is here to help!
Recently, the Kubernetes project took a much-needed stab at addressing potential security risks through Kubernetes configuration policies with the introduction of Pod Security Standards in Kubernetes 1.25. These standards are a set of rules that can be applied to the configurations (or “desired state”) for resources in any namespace in your Kubernetes clusters – providing an immediate safety net when it comes to common misconfigurations that comprise security and resource utilization.
The Pod Security Standards introduce 3 “profiles”:
- Privileged: Unrestricted policy, providing the widest possible level of permissions.
- Baseline: Minimally restrictive policy which prevents known privilege escalations.
- Restricted: Heavily restricted policy, following current Pod hardening best practices.
Once you’ve decided which to apply, you need to enable them by adding corresponding labels to the Namespace resources in your cluster:
This example blocks any pods that don’t satisfy the restricted policy requirements and also generates a corresponding user-facing warning.
Read more about Pod Security Standards and how to enforce them in the Kubernetes Documentation.
One challenge when adopting Pod Security Standards is their “all or nothing” approach. For example, if you already have a large set of resources deployed in your clusters and you’d like to apply Pod Security Standards, you have two options: the recommended Restricted profile or the more permissive Baseline option. Opting for the recommended restricted profile may leave you at risk of encountering hundreds/thousands of errors that need to be fixed before your applications can be up and running again. On the contrary, this might incite you to go for the Baseline profile instead, which is a good start but ultimately lets a lot of important misconfigurations slip through.
Wouldn’t it be helpful if there was a tool that allowed you to:
- Apply Pod Security Standard rules in a more granular fashion helping to identify weak spots in configurations
- Define a viable remediation strategy for you and your team
- Autofix underlying misconfigurations to speed up the process since many of the remediations are pretty straightforward modifications to your deployment/pod YAMLs
If you’ve come this far, you’ll be excited to learn that Monokle does all of this for you – providing a much smoother path to Pod Security Standards adoption than what is currently available with the bare-bones Kubernetes approach.
In case you didn’t already know, Monokle is set of tools for Kubernetes Policy Management and enforcement:
- Monokle Cloud is your central policy control plane for managing policies.
- Monokle VS-Code Extension / CLI / Desktop / GitHub App are all open-source tools used to enforce policies at different points in the application lifecycle. You can leverage the power of these policy and validation tools as standalone options or you can take full advantage of their complete integration with Monokle Cloud.
The Monokle validation engine used across the complete set of tools provides flexible Pod Security Standards support via a dedicated validation plugin that allows you to:
- Enable / Disable each rule in any of the PSS profiles individually for gradual evaluation and adoption of PSS rules and profiles.
- Interactively apply autofixes to resources violating any PSS rules – saving massive amounts of time when many resources would otherwise need to be manually updated.
Let’s have a look at these two features in turn.
In Monokle Cloud and Monokle Desktop, our visual tools, the Pod Security Standards plugin can be enabled in the policy configuration panels:
If you’ve created a Monokle Cloud project for centralized policy enforcement you’ll find this configuration in the Policy Builder instead:
In either case, enabling the plugin will allow you to configure and toggle all rules in the Pod Security Standard profiles individually, making it easy to assess their impact on your resources, for example in Monokle Cloud:
Let’s have a quick look how you can use this validation plugin in a short video:
If you want to try this yourself in Monokle Cloud - just go to https://app.monokle.com/explore/github/GoogleCloudPlatform/microservices-demo - and follow the steps from the video above. When you go to the mentioned site, you will be asked to sign-up/in if you haven’t already - no YAML strings attached!
Not only does Monokle allow you to work with Pod Security Standard rules and profiles interactively as shown above, Monokle Cloud can also automatically fix many of the associated misconfigurations for you, helping to save time and make the overall adoption of better pod security practices easier to implement.
Whenever an autofix for a specific misconfiguration is available, the validation audit panel will show a corresponding “magic wand” icon – which will automatically fix the error for you:
And while that might sound cool, seeing is believing! Check out this short video that picks up where the above video left off:
Remember that to be able to actually commit/contribute any hotfixes you might do on a public repo you’ll have to fork that repo first and apply the autofix there, before you can create an upstream Pull Request.
Although automatically auto fixing configuration errors might sound like a given path to saving time and improving deployment quality, there are a couple of things to consider before allowing this to become a common practice among your team:
- Engineers that “blindly” fix misconfiguration by clicking a button will not understand or learn what the actual cause of the problem is – and what the remediation does to fix it. When faced with similar (mis)configurations later without access to similar tooling, the risk is that they will be unaware of what the issue is and consequently, not be able to fix it manually.
- Some misconfiguration remediations are straightforward and unambiguous – others could have side effects or not fix all aspects of the underlying problem, for example changing permissions that are incompatible with how the underlying Docker image needs to access the system, or dropping all capabilities without adding NET_BIND_SERVICE. Once again, learning about and understanding the misconfiguration and its possible remediation(s) is key to sustainable configuration management.
That being said – if your team understands what remediations do, and you’ve discussed and agreed upon their usage – nothing should stop you from saving the time of manually updating YAML by leveraging the magic of Monokle with a click of a button.
If you’d prefer to start with the Monokle VS-Code extension let’s have a look at that approach instead:
1. Install the Monokle VS-Code extension in VS-Code
2. Open a project containing resources to which you would like to apply Pod Security Standard rules
3. Create a monokle.validation.yaml file in your project folder with the below contents:
plugins:
```
pod-security-standards: true
```
rules:
```
pod-security-standards/host-process: err
pod-security-standards/host-namespaces: err
pod-security-standards/privileged-containers: err
pod-security-standards/capabilities: err
pod-security-standards/host-path-volumes: err
pod-security-standards/host-ports: err
pod-security-standards/app-armor: err
pod-security-standards/selinux: err
pod-security-standards/proc-mount: err
pod-security-standards/seccomp: err
pod-security-standards/sysctls: err
pod-security-standards/volume-types: warn
pod-security-standards/privilege-escalation: warn
pod-security-standards/running-as-non-root: warn
pod-security-standards/running-as-non-root-user: warn
pod-security-standards/seccomp-strict: warn
pod-security-standards/capabilities-strict: warn
```
As you can see, this enables the pod-security-standards plugin and assigns warn/err severities to the individual rules. You can learn more about these configuration options in our documentation.
4. You’re all set! The Monokle validation engine will automatically kick in and validate your resources in line with the above configuration.
The Monokle CLI is a great way to add resource validation to your CI/CD pipelines, or just for ad-hoc validation of local resources. Install it as described on GitHub and then simply run monokle validate . in a folder containing a monokle.validation.yaml file, which will validate found resources accordingly and print a nice result to the console.
Running it with the above configuration results in the following output:
The Monokle team is busy implementing our own admission controller - allowing you to enforce policies in your clusters just as you already can in your pre-commit development workflows as shown above. Paired with Monokle's native Pod Security Standards support, this will allow you to enforce corresponding PSS rules in older versions of Kubernetes (i.e. pre 1.25) which lack the built-in PSS support - making it possible to adopt PSS and corresponding practices before you make the jump to a supported Kubernetes version. Keep an eye out for our announcement - or visit us at Kubecon in Chicago to see this in action.
Through the addition of Pod Security Standards to Kubernetes 1.25, it is evident that the Kubernetes team is looking to highlight the overall importance of Kubernetes policy functionality as they look to help teams find ways to deploy secure and compliant applications. At Monokle, we believe that policies and validation should never be overlooked and are the cornerstones of attaining high-quality Kubernetes deployments. It is because of this foundational belief, we are excited to share how our set of tools can help users adopt Kubernetes Pod Security Standards with ease. The ValidatingAdmissionPolicy and related resources introduced in Kubernetes 1.28 further show the importance of this aspect of Kubernetes applications, and we've written a dedicated blog-post to show you how that is already supported in Monokle - Real-time Kubernetes Policy development with Monokle.
For help getting started with Monokle and Kubernetes Pod Security Standards or to give us feedback about additional needs to help you further your policy initiatives and best practices, don’t hesitate to reach out. You can find us on Twitter (now X), Discord, LinkedIn, or connect with us directly from our website. We are eager to hear from you – thanks!
Join the Monokle Community in one of these channels:
Subscribe to our monthly newsletter to stay up to date with all-things Monokle.
