Rego policies related to the Enterprise Contract.
The Makefile
contains a lot of useful scripts and commands. Run
make
by itself to see the help.
Go is required for development. Tools like conftest
and opa
are executed with
the Go binary - they do not need to be installed in your system. See the top of the go.mod
file for the minimum version of Go required.
Most of the maintainers use asdf to seamlessly use the right version of Go.
Some, optional, make targets may require additional tooling. For example, make live-test
requires
entr to be installed.
The rego files should be formatted using the standard format. To apply the standard format run this before committing:
make fmt
The documentation is built using Antora.
Those docs are published here.
When making changes to policy rules, the docs will likely need to be re-generated. To do so run:
make generate-docs
Commit all of the modified files.
From the top level directory you can run all tests and formatting checks, as well as check that the docs are up to date, like this:
make ci
You can run a single test like this:
ec opa test ./policy -r <test_name_matcher>
or
go run github.com/enterprise-contract/ec-cli opa test ./policy -r <test_name_matcher>
The <test_name_matcher>
is a regex, so you can use it to run more than one
test.
See Makefile
for other ways to run the tests.
Policies must have unit tests validating them. All test files must adhere to the naming convention:
file.rego
file_test.rego
Refer to the policy testing docs for more information.
The CI also enforces that there is 100% test coverage. If you're not at 100% you can use this to show what lines of code are not covered:
make coverage
Fetch an image attestation from a registry:
make fetch-att
more input/input.json # to look at it
or:
make fetch-att IMAGE=<some-image-with-an-attestation-ref>
Create a dummy policy config file:
make dummy-config
cat data/config.json # to look at it
Then to verify the build using the defined policies:
make check-release
For example to fetch a pipeline definition from your local cluster:
make fetch-pipeline
make fetch-pipeline PIPELINE=<some-pipeline-name>
more input/input.json # to look at it
For a realistic Konflux pipeline definition that doesn't require cluster access, if you have the build-definitions repo checked out nearby you can do something like this:
( cd ../build-definitions && kustomize build pipelines/hacbs | yq 'select(document_index == 2)' -o json ) > input/input.json
Then to verify the pipeline definition using the defined policies:
make check-pipeline
Running policies against local ec-cli build
Build a local version of ec-cli
in your local ec-cli repo:
make build
Create a policy.yaml
file in your local ec-cli
repo with something like:
---
sources:
- policy:
- <path-to>/ec-policies/policy/lib
- <path-to>/ec-policies/policy/release
data:
- oci::quay.io/konflux-ci/tekton-catalog/data-acceptable-bundles:latest
- github.com/release-engineering/rhtap-ec-policy//data
Run the locally built ec-cli
command
dist/ec_<arch> validate image --verbose --images '{"components": [{"containerImage": "<container-image>", "name":"my-image", "source":{"git":{"url":"<repository-url>","revision":"<commit-id>"}}}]}' --policy 'policy.yaml' --public-key <public-key-to-verify-the-image> --strict false --ignore-rekor --verbose --output=text
The policies defined here are bundled and pushed as OCI artifacts using
conftest
. There are three bundles, one for each of the release and pipeline
policies, and one for the data which is used by both.
The push-bundles automates creating and pushing these bundles to quay.io, and generating a related PR in the infra-deployments repo so the latest bundles are used.
See also the policy bundle documentation.
See the Policy Authoring documentation for guidance on contributing to the definition of policy rules.