Open Policy Agent — A great alternative for Pod Security Policy
The Kubernetes PodSecurityPolicy (PSP) is the earliest reliable security control offered out-of-the-box with Kubernetes. It’s merely an Admission Controller which ensures deployed Pods meet the defined security level for a Kubernetes cluster.
Unfortunately, PSP is still in Beta, got deprecated in the Kubernetes release v1.21, and will be entirely removed in v1.25.
PSP enables admins to prevent running containers that violate defined security policies. (Example: Prevent running containers that require a specific set of system capabilities, or trying to use a system-critical PriorityClass, …).
Challenges with PSP?
PodSecurityPolicy has been stuck in Beta since its introduction in Kubernetes-v1.3. As all of us know, any Kubernetes API that stands in Beta for more than nine months will follow the rule of being deprecated and then gradually removed. PSP escaped from this rule for a while, but it is time to remove it definitively from the API.
Weaknesses are also the source of truth behind the idea of removing the PSP from Kubernetes. I share some here, but not going to dive into them:
- PSP doesn’t handle auto-injected sidecars well,
- Challenges when validating objects in CI/CD pipelines,
- Difficulties in assigning PSPs, with confusion in mutating/non-mutating PSPs,
- And many more.
To deep dive into PSP challenges, follow this link.
What path shall we follow then?
The alternative to the dying PSP is OPA, the Open Policy Agent, which is by far the best choice today. OPA is still under heavy development and has buy-in from the Kubernetes community.
OPA Deep Dive!
The community behind the lines?
OPA, Open Policy Agent, is an open-source project founded by Styra in 2016. It was donated to the CNCF in 2018, became an incubating project in 2019, and recently moved to ‘Graduated’ state.
A big community is backing up the project, such as Microsoft, Google, VMWare, and Styra. The CNCF Landscape provides more insights on the project and its evolution since 2016.
What is it?
OPA is a full-featured and lightweight cloud-native policy engine configurable through RestFul APIs and runs as a webhook in Kubernetes. OPA's purpose is mainly to decouple and offload policy decision-making from “policy enforcements” and provide full visibility on “who ”can do “what ”on a running Kubernetes cluster.
By relying on a declarative policy language (DSL ), called Rego, the security operators can concisely express/define policy rules; OPA evaluates the Kubernetes resource updates against the defined policies and applies the needed restrictions if any.
Policy-as-Code
Without appropriate policies in place, the boundless power of Kubernetes can result in dramatic consequences. Fortunately, Open Policy Agent provides the ability to set up policies that can limit those consequences.
OPA makes Security Officers’ life even more comfortable.
Below I state some common use-cases about “enforcing the usage of trusted registries”, “prohibiting privilege mode for containers”, “filtering on ingress & egress”, in addition to “enabling labeling’s best practices”:
a. Enforce Trusted Registries - Examples of related policies are below:
- Allow only container images to be pulled from trusted Container Registries,
- Allow only signed images to be used,
- Prohibit Images that match specific image tags or hash/SHA.
b. Prohibit privileges mode
- Ensure that containers will run with a specific UserID,
- Prohibit Pods from running in privileged mode or as root users,
- Prohibit insecure capabilities to be bound to containers.
c. Ingress filtering: It’s important to filter all ingress data not specifically required for services
- Prevent spinning up a service that exposes unwanted applications to the internet,
- Limit spinning up unnecessary external load balancers,
- Ensure that all protocols for internet-facing apps can only expose HTTPS.
d. Control over Egress
- Apply guardrails to pods from communicating with the outside world; Useful to prevent malware-infected zombies from participating in external DDoS attacks or Bitcoin mining. In the case of compromised pods, the risk is drastically reduced.
e. Labelling
- Only specific teams can use nodes backed with GPUs,
- Pods not labeled as agreed-on will be restricted from running in the environment.
Enjoy a free “Playground”!
Well after this quick “tour de table”, I invite you to check and enjoy the free online playground.
OPA made available to the community a free playground, packaged with a bunch of policy examples, which can be used for a quick start; Very handy to anyone looking to discover, learn and play with OPA, without getting into the burden of deploying it.
OPA Online-PlayGround — Fast feedback loop that helps to iterate on the policies and see the results instaneously.
Feel free to check the below link.
Several ready-to-use policy examples are well explained/commented on, as shown in this PrintScreen:
Try it out, start by building easy rules, browse the documentation for advanced policies. Once you got easy with the basics, customize the provided examples and move forward.
&! To Finish
Security is increasingly becoming a crucial part of all day-two operations. As a cloud security professional, it’s in your greatest interest to adopt it since day one. No one will be able to withstand high-security threats and impact.
Finally, OPA is well integrated with different solutions, not only with Kubernetes stacks. An index is available and provides insights on the integration points and plugins, allowing OPA usage in almost any stack.
Looking for alternatives, please have a look into KubeWarden, and Kyverno.
Thank you for reading me!
