Download bundles from OCI-compatible registries

[omerlh]

Expected Behavior

OCI-compatible registries can be used to store anything, including OPA bundles (see here a live example). I want to configure OPA with registry details and let it pull all the policy bundles from it (or specific bundles)

Actual Behavior

Bundle API supported, we can write a facade that translates Bundle API to OCI.

See also #1413 (thanks to @garethr!)

[garethr]

Some context to the use of OCI registries for storing artefacts other than Docker images here: https://stevelasker.blog/2019/01/25/cloud-native-artifact-stores-evolve-from-container-registries/

Conftest supports pushing and pulling OPA bundles, but I'd be happy to pull that out of Conftest and into OPA (or a standalone library) if folks thing this is useful elsewhere too.

The discussion in #1413 is intended to match up the mimetype/layers in the OCI image with the current bundle format described in the docs.

The OPA config for using OCI bundles could be something like the following:

services:
  - name: acr
    url: https://instrumenta.azurecr.io
    type: oci

bundle:
  name: kubernetes
  tag: latest
  service: acr

The assumption at the moment appears to be that aggregation of policies happens before creating the bundle, so only one bundle is downloaded. That likely makes directly reusable bundles harder to accomplish. The docs The docs cover how to configure bundle .manifest files to deal with importing multiple bundles but don't discuss how to then configure OPA to use multiple bundles.

[tsandall]

👍 support for downloading from OCI registries would be nice to have.

I could imagine removing the need for a service definition in this scenario. For example just configure OPA with the bundle tag:

bundle:
  tag: instrumenta.azurecr.io/kubernetes:latest

We have #721 to track support for multiple bundles. Now that .manifest lets users control which roots a bundle owns, it should be fine to extend OPA to download multiple bundles. See #721 for more detail on what needs to be changed to make this happen.

[RichiCoder1]

With recently added ECR support, would be great to see this + AWS IAM support for it: https://aws.amazon.com/blogs/containers/oci-artifact-support-in-amazon-ecr/

[garethr]

Hi @RichiCoder1. We use this in https://github.com/open-policy-agent/conftest. Under the hood we use Oras which is where IAM support would want to land I think. Would be great to get ECR added to https://github.com/deislabs/oras/blob/master/implementors.md.

[RichiCoder1]

@garethr I'll see if I can dig in! Looks like there's a ticket for that (which I've updated) oras-project/oras#105.

[RichiCoder1]

Actually, is Oras the appropriate place to but IAM/AWS specific logic? At least right now it's all just standard Docker/OCI, and I'm not sure they'd take a contribution to add AWS-specific auth. Maybe that's something that'd be better implemented in conftest/opa or some different adapter lib?

[garethr]

In my view this should be applicable to any user of Oras, rather than just Conftest. Implementing there has the advantage of it being useful and consistent for any consumer I feel.

[RichiCoder1]

There seems to be receptiveness on the Oras side to building out an extensibility point for that sort of thing: https://cloud-native.slack.com/archives/CJ1KHJM5Z/p1599738293031300

So, it'd be figuring out what's the best way to accomplish that.

[RichiCoder1]

Created oras-project/oras#177 to at least start brain storming. Would love feedback, ideas!

[gwkunze]

Should the alternate auth support be split off in a separate issue perhaps?

[srenatus]

👋 cc @viovanov @gertd @ogazitt @gimmyxd: Would this be something you'd be interested in contributing? Sounds like a good fit 💯

[viovanov]

@srenatus sorry for the late reply :)
Yes, we're definitely interested, we just have to schedule that work.

[srenatus]

Cleaning this up. There's experimental support for this in 0.40.0. Follow-ups are tracked via #4518 and some newer issues I'm writing right now.