This example shows how OPA can authorize changes to Puppet manifests.
You can try out the steps below using the policy file and JSON data contained in this repository.
This example works by defining a policy that:
- Accepts a compiled Puppet manifest as input (the Puppet catalog)
- Scans the resources in the Puppet catalog and identifies the author (using Git blame data)
- Checks if the author is a member of the team responsible for the resource
- Produces a
true
orfalse
result that indicates if the Puppet catalog is allowed (based on the checks above)
The policy relies on two pieces of external data:
- Git blame identifying the Puppet resource author
- Team membership
In real-world scenarios, this data could be replicated into OPA from sources like GitHub and LDAP.
First, start OPA using Docker.
docker run -it --rm -p 8181:8181 openpolicyagent/opa:0.4.8 run -s -l debug
Next, load the example policy:
curl -X PUT --data-binary @puppet_authz.rego localhost:8181/v1/policies/puppet_authz
Finally, load an example Git blame data set.
curl -X PUT -d @blame_allowed.json localhost:8181/v1/data/git
Now, run a policy query against OPA, providing the example Puppet catalog as input.
curl -X POST -d @puppet_catalog.json localhost:8181/v1/data/puppet/authz/allow
The result indicates that puppet_catalog.json
is allowed:
HTTP/1.1 200 OK
Content-Type: application/json
{
"result": true
}
Let's update the Git blame data in OPA.
curl -X PUT -d @blame_denied.json localhost:8181/v1/data/git
In this Git blame data set, bob
(who is a member of app_team
) modified an infra_team
resource.
curl -X POST -d @puppet_catalog.json localhost:8181/v1/data/puppet/authz/allow
This is the same query that we ran before. However, this time, the Git blame data stored inside OPA is different (and it represents a policy violation). As a result, the catalog is denied.
HTTP/1.1 200 OK
Content-Type: application/json
{
"result": false
}