The Open Policy agent can be configured to consume policy bundles from remote HTTP servers, including support for AWS S3, Google Cloud Storage, and Azure Blog Storage.

As of version v0.40.0, OPA can now consume policy bundles packaged as OCI images. This allows building and tagging OPA policies just like docker containers, including using tools like cosign to sign those images and verify the signatures.

OCI images can be built using the policy CLI, part of the Open Policy Registry project.

Read on for more details!

Today, we are happy to announce that the Policy CLI can interact directly with Github Packages (GHCR)!

GitHub Packages is a platform that allows you to host and maintain packages and containers. The Policy CLI is a tool that can be used for building, versioning, and publishing your authorization policies. It uses OCI standards to manage artifacts, and the Open Policy Agent (OPA) to compile and run (For more instructions for downloading and using the Policy CLI head to our documentation).

You can now use the Policy CLI to manage your policy images with GHCR as well as the Open Container Registry. In this post, we’ll walk through using the Policy CLI with GHCR.

Login#

To log in to the Policy CLI using your Github Packages credentials, use the following command:

policy login -s ghcr.io -u <username>

This command will ask for the password, you can use your Github PAT to authenticate to GHCR if you have it enabled for your account. After authentication, the CLI will offer to set this server as your default registry. We recommend you set it as the default to make usage easier for the next couple of commands.

Push a policy image#

If you already have an image in your local registry that you want to push to GHCR you will need to first tag the image correctly before pushing. The structure of the image label is as follows:

<org>/<repo>:<tag>

Example:

Your local registry contains a built image that was tagged john/myapp:rbac. If you want to push this same image from your local registry to ghcr.io, so you should tag this image with the command:

policy tag john/myapp:rbac ghcr.io/<myusername_or_org>/myapp:rbac

After tagging your image, you can push it to ghcr.io using the command:

policy push ghcr.io/<myusername_or_org>/myapp:rbac

Removing an image from your local storage#

Following the example mentioned above, if you want to remove this image from your local storage you can use the command:

policy rm ghcr.io/<myusername_or_org>/myapp:rbac

Pulling a policy image#

Once you have a container package with your authorization policy, you can pull the image using the following command:

policy pull ghcr.io/<myusername_or_org>/myapp:rbac

Ensure your image is working#

To check whether your pulled image is working as intended you can use the following command to open an interactive OPA shell:

policy repl ghcr.io/<myusername_or_org>/myapp:rbac

Check the remote images available#

The following command will fetch the container packages stored in ghcr.io and will display a table with the available images:

policy remote images -o <myusername_or_org>

Removing an upstream repository#

GHCR has a couple of limitations regarding package removal that need to be taken into consideration:

• the newest tag pushed cannot be removed unless removing the entire package (you can use policy rm -r -a <image>).
• to be able to remove a package your login credentials (PAT) will need to have the delete:package permissions

Assuming you want to remove the image mentioned in the example above, you can run the following command to remove the container image:

policy rm -r -a ghcr.io/<myusername_or_org>/myapp:rbac

Changing visibility#

Although the CLI contains a command to change the visibility of an upstream image, at the moment GHCR does not allow this operation through an API. Currently, we recommend using the web UI to change a package’s visibility.

The Open Policy Agent (OPA) is a general-purpose decision engine used in a wide variety of contexts where policies govern authorization and access-control. One of the most important value propositions of OPA is that it decouples decision logic (defined in the policy) from decision enforcement (which happens in the application or service). This decoupling allows the policy to be developed and managed separately from the application or service. Decision-making execution is delegated to the OPA engine, guaranteeing that the policies are consistently interpreted and enforced.

OPA is used to enforce policies in many contexts, including microservices, Kubernetes, CI/CD pipelines, and API gateways. Having a single engine and language for handling authorization policies across the stack is a huge advantage for developers: it allows for policy reuse and makes testing, automation, and maintenance easier.

OPA policies are written in Rego and then bundled into a compressed tarball. The tarball is then loaded into the target environment, where the policy is enforced.

We believe that OPA’s distribution workflow could be enhanced and improved by integrating it with two Linux Foundation OSS projects: OCIv2 - the industry standard for container image formats, and Sigstore, an open and pluggable standard for code signing.

Three interconnected concerns need to be addressed as part of the policy-as-code workflow: versioning, signing, and sharing.

• Versioning a policy makes it easier to maintain, share and discover
• Signing a policy makes it possible to trust that the policy’s content is what the consumer of the policy expects it to be
• Sharing and discoverability of policies promote reuse and reduce duplication of code and effort.

The Open Policy Registry now has a proper console! Once you push policy images to the registry, you can view the policy repositories in your organization.

Clicking on a policy repository will show the tagged images you have for that repo.

Let us know if you have any feedback!#

We wrote a quick tutorial for getting started with the policy CLI.

It takes about 5 minutes to complete, and you'll learn how to:

• build and tag OPA containers
• push and pull OPA containers from the opcr.io registry
• sign and verify OPA containers with cosign
• Run a read-eval-print loop, issuing queries to your OPA container

The full tutorial is here.

Happy hacking!#

A brief history#

When we first started using OPA, we were impressed with how flexible it is as a general-purpose decision engine. We were familiar with using it for infrastructure scenarios (like k8s admission control), but thought we could extend its use to application and API authorization scenarios.