circleci-public/circle-policy-agent

policy-agent

The policy-agent is essentially a CircleCI-flavored wrapper library around the Open Policy Agent (OPA), which will allow the users to write the policy documents in CircleCI terminology.

policy-agent is responsible, at its core, for doing the following:

• Integrating with the Go API to evaluate policies.
• Expose custom built-in functions that make policies (i.e., rules) easier to write.

tools setup

We use golangci-lint and task in this repository:

$ brew install go-task/tap/go-task
$ brew install golangci-lint

or

sh -c "$(curl --location https://taskfile.dev/install.sh)" -- -d -b /usr/local/bin
curl -sSfL https://raw.githubusercontent.com/golangci/golangci-lint/master/install.sh | sh -s -- -b $(go env GOPATH)/bin v1.46.2

See common project tasks with task -l, including:

task lint
task fmt
task test

run lint

task lint

run tests

task test

API Documentation

With godoc, you can view generated html documentation on your machine for policy-agent. There are two task commands for convenience:

* doc: 		Run 'godoc', print docs url
* doc-open: Run 'godoc', open the docs url in your browser

Helpers

CircleCI has provided helper functions to make it easier to write Rego policies. To use this code, please include import data.circleci.config in your Rego file.

Currently supported helpers:

• orbs
  • ban_orbs
  • ban_orbs_version

circle-policy-agent's Issues

Generic helper functions for maps & arrays in CCI config

We are seeing some common basic functions that make assertions in config easier.

• in_array - for objects like context which can be a list or single value makes checking match either case.
• job_name - since jobs of a worklows can be a single string, or include things like custom name this uses the right name in either case.

.... Others?

Restrict Context Access by Project

Hey! that's my context!

Inside an org with many teams, some will want to restrict contexts to only be used on their projects.

This rule would check and ensure:

• IF they are using a context provided (function argument)
• AND NOT in our list of project IDs (user side) -- I think user would just { not list_of_projects[meta.project_id]} on the hard_fail stanza?
• THEN FAIL

Restrict Context Access by Branch Name

This is the "Branch Based Secrets" we all want and love.

Included in playground as example. This ticket is to make the branch name an argument, and move to config package.

@davidmdm - hope your ok if I track the things we're interested in collabing on here?