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, is getting deprecated in the next Kubernetes release (Kubernetes 1.21), and will be entirely removed in Kubernetes 1.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).

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 the time comes 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 in 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 community.

OPA Deep Dive!

OPA, Open Policy Agent, is an open-source project, founded by Styra in 2016. It was donated to the CNCF in 2018, becomes an incubating project in 2019, and recently got graduated.

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.

CNCF Cloud Native Interactive Landscape — Open Policy Agent (OPA)

OPA is a full-featured and lightweight cloud-native policy engine configurable through RestFul APIs and runs as a sidecar alongside Applications/Pods in Kubernetes. OPA 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), security operators can concisely express policy-rules. OPA evaluates the Kubernetes resource updates against the defined policies.

OPA is well designed and integrated with Kubernetes APIs

Without an 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 stated 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

  • 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 are able to use nodes backed with GPUs,
  • Pods not labeled as agreed-on will be restricted from running in the environment.

Enjoy a free “Playground”!

A playground packaged with a bunch of policies examples that can be used to get started quickly is made publicly available; Very handy to anyone looking to discover, learn and play with OPA.

Feel free to check by following the link just below.

Seceral ready to use policy examples are well commented-out and are deeply explained as shown here:

OpenPolicyAgent — Playground

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 the usage of OPA in almost any stack.

Thank you for reading me!

Is a DevOps & Cloud enthusiast with 10 plus years of experience. He’s continuously immersing himself in the latest technologies trends & projects.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store