New OPA environment.

[Gray-Ghost347]

Hey guys,

First of all, I'm becoming a big fan of this tool, it's awesome! I'm from Cyber Security and I'm new to the OPA world.

We are currently deploying Gatekeeper in my organization, which is controlling my entire k8s environment, in conjunction with Terraform/Atlantis. Later this year, we want to migrate our entire environment to Kubernetes!
In the above environment, we have policies in production and everything works fine! But I would like to know how to build a new approach for another environment, outside of Kubernetes.
I have a cloud environment that is currently accessed by a limited number of people, but they can make significant changes within the dashboard. For example, letting a security group accept ingresses to 0.0.0.0./0.
My question, I already know that Gatekeeper only works within k8s, so would I have to have another OPA environment (other than Gatekeeper) installed to control these aspects via Terraform or something else I don't know yet (Lambda function?), via Rego policies?

For example: I want an OPA policy not to allow an SG to be created or changed (CREATE or UPDATE) when it violates the Rego rule that doesn't enable ingress to 0.0.0.0./0.

Is it possible to create a project to control a cloud environment like this?

[anderseknert]

Hi there! I'm happy to hear that you enjoy using OPA 🙂

For policy enforcement outside of Kubernetes, you could either use OPA core* for that, or possibly Conftest, which is popular in combination with Terraform.

Your requirement sounds like it's still Kube though?

For example: I want an OPA policy not to allow an SG to be created or changed (CREATE or UPDATE) when it violates the Rego rule that doesn't enable ingress to 0.0.0.0./0.

But perhaps I'm just not getting it yet.

(*FWIW, you can totally use OPA core in the context of Kubernetes too!)

[Gray-Ghost347]

Hi Anders Eknert.

It's a pleasure to chat with you. Thanks for your prompt reply!

Man, I'll try to explain myself as best I can, because I'm very new to this context, I'm learning!

At first glance it seemed to me that within the OPA solutions for kubernetes, only Gatekeeper would meet the needs of our organization. So I installed it via a helm chart, created the constrainttemplates and constraint, I upload them via a Git pipeline [which Terraform/Atlantis starts]. Everything is going well in this environment.
But I want to protect my cloud environment, because I've studied that the OPA is very agnostic! And that was the proposition I sold here in our organization when I brought in OPA.
I now need to know how to get this OPA core tool environment to link it to my cloud provider and any others that may be needed.
There is documentation on how I can do this [it can't be simple].

The example I gave of a policy that doesn't allow SGs to be created or changed with an ingress of 0.0.0.0./0 wouldn't be for the k8s context, it would be to prevent this change from happening INSIDE THE CLOUD DASHBOARD, i.e. with the user logged into the cloud URL, trying to create/change an SG and making it permissive, so OPA core wouldn't let them.
Did you understand my needs better now?

[Gray-Ghost347]

@anderseknert

[anderseknert]

Hi there! And sorry for the late response.

Yes, I think I get what you're saying. Whether it can be done depends on whether actions performed in the cloud dashboard trigger a something like a webhook that OPA can act on. The model of OPA is rather simple — get JSON in, make a decision, send JSON out. In the Kubernetes case, the Kube API makes sure to consult every configured admission controller (like OPA) for decisions before it makes modifications of storage. OPA (core) doesn't know that it's running in Kubernetes, just that it gets some JSON input that it will run against its policies. Similarly, OPA itself doesn't stop anything — it only sends back a JSON response (a decision) that the Kubernetes API server then enforces.

Cloud resources managed via Terraform, CloudFormation, etc.. are normally checked before they're deployed (in CI or whatever) but there are often options to also download existing (i.e. already deployed) resources and run checks on them too.

I don't know if there are cloud providers where clicking on things in the UI triggers something similar to Kubernetes "admission control". I think the most common option for orgs where cloud resources are managed programmatically is to make the UI read-only for most users, or otherwise limit access.