OPA - For Terraform
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
All Credits to this video creator : https://www.youtube.com/watch?v=deu-BpE1L98
https://github.com/open-policy-agent/opa -- Github library for OPA
List of Adobters : https://github.com/open-policy-agent/opa/blob/main/ADOPTERS.md
Github repo for Regula : https://github.com/fugue/regula
You may have the question if there already have OPA why did you make regula. Well Regula adds to OPA loads of capabilities , convenience features for doing infrastructure as code security assessment
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
OPA
Sample of Rego Code :
If you are doing Policy as a Code what you are really doing is testing configurations and this really comes down to looking what a configuration is and deciding if this all fair game or possible errors with it. And in order to express these policy rules you need a language
Other alternatives to Rego is sequel , may be Graph database for JSON support or just using a regular Java Script or Python. But I think OPA Rego has so many things that makes it ideal for this use case.
Another query language is JQueue
OPA has this build in testing frame-work
OPA uses packages so that you can group code together
package simple --You can call this defining a package or opening a package
If I open up an interpreter
> opa run simple
> data.simple.allow
false
You declare a package and put in a bunch of declarations.
If we go to an example of a IaC , we have a terraform file here
We cannot use this HCL file directly as an input document to rego . So what usually happens is we use terraform to first convert this to a Plan file.
> terraform plan -out tmp.plan
Then convert this to JSON.
> terraform show -json tmp.plan
This is how a terraform plan looks like
Lets say we want all the departments to have a department tag.
If I want to run something with plan rego . we can always use opa eval .
There are two ways that we can write the rule. instead of planned_values we can also use "resource_changes"
Do you really look at planned changes or resource change -- It is really a mix of the both . You really want to take the union of the both .
There are complexities to work with the JSON file for we need to get into the JSON plan.
If we use regula we can remove loads of complexity
Below is the same rule written in Regula.
rule.department_tag -- rule is the namespace. And that's the way it picks up all that rules it wants to run.
Here we care about a single resource type . We have a default allow = false











Comments
Post a Comment