<img src="https://ws.zoominfo.com/pixel/JHVDdRXH2uangmUMQBZd" width="1" height="1" style="display: none;">

New! Magalix brings you the SaC (Security-as-Code) podcast. Listen now!

Exit icon Listen Now
Why to Use OPA
DevOps Kubernetes Governance Policies


In this article, we will explain why to use OPA and what benefit comes with using OPA. Why we need a policy engine to verify whether resources are compliant with company policies and ensure best practices. We will also be looking into Magalix OPA SAAS which helps us provide its users a unified way of defining policies and you will be verifying the violations all in the dashboard.

Before starting, I would like you to take a look at some starter topics, we already covered the Basics of OPA and how you can integrate OPA with Kubernetes.

Let me tell you a story of mine. As I have started working on Kubernetes and had to do my certification, in the meantime, I was looking into every aspect of what and how things can be done in Kubernetes. While I understood what the Kubernetes resources could do, one thing I didn’t understand was security, like when I have to define the pod limit attribute to limit the computing resource, it can be done by using limit but what if I have to use these limits for all pods. That is where I was curious isn’t there any way to define it at a cluster level so I don’t have to define it at every pod? As in programming, we use middleware for authentication, so every request first authorizes then does the rest of the function. After going through many articles, I have come to understand the exact thing I needed from OPA which provides cluster-level policy defining at every create update or delete request and checks whether it is compliant with policies or if not it rejects the request.

Why to use OPA

You can also see the before and after of OPA with the picture above. If OPA is integrated it will check for policies and govern the resource if they are permitted or not.

Policies Enabled Resources

Using OPA, resources will be policies enabled, we mean that all resources in our cluster are checked if it is compliant with policies or not. It is also the service that is able to answer questions by comparing input policy statements written by administrators. For example, If the pod is taking computed resources above from the limit defined or images doesn’t include the image version. These policies enablement in Kubernetes is done by OPA.

Kubernetes Policies

Kubernetes Policies are used to define what the end-user can do with Kubernetes resources and by using these policies with OPA it secures the cluster with one policy for all resources.

Here are just a few of the Kubernetes policies used to restrict creation or updates for a specific resource:

  • We can define network policies to specify how a group of pods communicate with each other.
  • We use Volume Policy to specify the Kubernetes scheduler of the default limits for the number of volumes to be attached with nodes.
  • We can use the Limit Range option to enforce the constraint on resource usage:
    1. Compute resources for pod or container.
    2. Storage request per PVC.
    3. Request and Limit ratio.
  • We can use Access control fine-grained policy, Using RBAC, and defined to allow/deny fine-grained permission. For instance, an autoscaler has permission to scale up or down a replica of a pod in the specified namespace.
  • We can define Pod Security Policies that enable fine-grained permission and authorization for pod creation and updating. They allow for some of the options:
    1. Privileged.
    2. Volume type usage.
    3. Host filesystem usage.
    4. User IDs of container.
    5. Linux capabilities.
    6. Restrict escalation to root privileges.

Limitation of Kubernetes Policies

We have seen the Kubernetes policies above and can implement them on specific resources, but there isn’t any single security configuration where all the rules and engines can automatically validate the resource. Due to this problem, not having a single source of security and ensuring compliance manually is error-prone. We need a single independent policy engine that ensures best practice and makes sure that Kubernetes objects comply with company policies.

The Open Policy Agent (OPA) Gatekeeper was introduced to the Kubernetes world. Kubernetes allows the decoupling of policy decisions from the control plane’s API server by the admission controller webhook and governs and enforces how the cluster will be used. OPA also ensures this in an automated manner when creating, updating, and deleting Kubernetes Objects, eliminating the need for human intervention.

Magalix OPA SaaS

We already saw in a previous article on how to integrate OPA with Kubernetes. Now we will take a look how OPA helps in all over the security and Magalix provides the easy way to implement OPA. By using Magalix OPA, you don’t need to install OPA on your cluster and policies can be applied with a single click. Let's have a look at Magalix advisor.

Let’s create a policy in Magalix and see the difference
Why to use OPA With MagalixAfter successfully creating the issue in the advisor, you can see the violations in the dashboard. Before that lets create a pod with the name Magalix so we can verify if it is working or not.

// file name check.yaml

apiVersion: v1
kind: Pod
  name: magalix
    app: nginx-privileged
  - name: nginx
    image: nginx

Then run the following command

$ Kubectl create -f ./check.yaml

Now let's get back to the dashboardWhy to use OPA With MagalixHere we can see our two pods are violating this policy of having the name Magalix. One is which we create just now and the other is a Magalix agent. You can also see in detail what Magalix OPA provides here.

Try it Now


  • We are in need of a system to secure the cluster and ensure that system is compliant with organizational policies.
  • OPA is used for intercepting the request and ensure resources follow policies
  • Kubernetes Policies are good to use for single resources. However, when dealing with containerized applications, a team of developers working and hundreds of microservices involved, we need a single independent source of security configuration.
  • Open Policy Agent is a light-weight independent single source of security configuration that enforces best practices and compliance with company policies in an automated manner.
  • OPA intercepts API calls and validates these resources at creation, updating, and deletion.
  • OPA also has the Audit functionality, which enables us to check pre-existing resources for misconfiguration.
  • OPA can be monitored using Prometheus it scrapes metrics at port 8181
  • OPA use Rego, a declarative query language for writing policies and validating resources
  • Magalix OPA SAAS offered a unified and declarative way of defining policies and you can audit and see the violation in the UI format.

Comments and Responses

Related Articles

The Shared Security Model - Dividing Responsibilities

Understanding the Shared Cloud Security Model and causes behind common data breaches.

Read more
How to Prevent Non-Secure Container Images from Being Deployed with Policy-As-Code

Security is critical to business continuity. As such, DevOps teams must prevent non-secure container images from being deployed. But how do you do it?

Read more
Using Affinity with nodeSelector and Policy-As-Code, and Exclusions

In a Kubernetes cluster, you have to leverage policy-as-code to enforce Node Affinity using nodeSelector. But how do you do go about it? Learn more.

Read more