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.
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.
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.
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.
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.