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
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.
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.
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.
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 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 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.
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
After 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 metadata: name: magalix labels: app: nginx-privileged spec: containers: - name: nginx image: nginx
Then run the following command
$ Kubectl create -f ./check.yaml
Now let's get back to the dashboardHere 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.
Here’s why a Zero Trust security approach is one of the most reliable ways to prevent supply chain attacks.