Integrate with .docker/config or OIDC provider setups

[zmarouf]

The current flow requires an explicit username password pair.

I believe security could be enhanced with JIT credentials with short-expiry times. The easiest would be to leverage existing local .docker configuration or environment variables for OIDC setups like IRSSA and WorkloadIdentity.

Thoughts? :)

[migmartri]

Hi!

Thanks for opening this discussion!

I'd like to add some context to set the stage and make sure we are on the same page of the problem we want to solve :)

There are 3 touch points where an OCI registry is involved.

1 - When a container image material type is added to an attestation (see in this video)

# add an material of type container_image 
chainloop attestation add ... 

This command will use your local docker keychain (.docker/config) to authenticate against the provided image reference OCI registry and retrieve the manifest => digest

https://github.com/chainloop-dev/chainloop/blob/29d39b98144b137774f7c0bbd383ebb62f94cd18/internal/attestation/crafter/materials/oci_image.go#L53

2 - When you upload an artifact or add a material to the attestation that requires upload (example)

# manual upload
chainloop artifact upload ...
# or add a material that requires upload, i.e artifact, SBOM, ...
chainloop attestation add ... 
# or pushes the 

3 - When an attestation gets received, it gets routed to an OCI registry by the control plane

In this case, it is the control plane the one that routes the attestation to the OCI registry.

AuthN

The first touch point uses local docker environment (whatever the CI where the attestation is happening is logged in as).

The other 2 cases, are in fact routed through the artifact CAS and indeed requires stable, OCI credentials.

In other words, the clients (CLI or control-plane) do not talk to OCI directly (or will not soon #2), so the Artifact CAS is the one that will push the artifacts on their behalf.

The reasoning behind this decision are

• Artifacts backends should be plugable, today we have OCI but tomorrow some people might want to store artifacts to blob storage, artifactory, send it to a kafka stream, anything.
• Operators can mix and match with different backends, the integration in the client side (CI) should not change in that case.
• Leveraging local/CI credentials means that the owners of the CI/CD pipeline have access to the OCI registry where the attestation/artifacts will rest, and we try to keep both separated.
• Simplicity on the CI side. A chainloop robot account is everything you'll ever need for a successful integration.

Short-lived/OIDC AuthZ for Artifact CAS

With that out of the way, could you confirm @zmarouf:

• a) if that separation of concerns on who owns the authentication described above makes sense in your case?
• b) This issue refers to the OCI repository that needs to be added to your Chainloop organization that powers the touchpoints 2 and 3?

If so, as you pointed out, setting up the target OCI registry requires a keypair which then gets stored in a secret backend (AWS secret manager or Hashicorp Vault)

$ chainloop config set-oci-repo \
    # i.e ghcr.io/chainloop-dev/chainloop-cas
    --repo ghcr.io/[username or org]/[my-repository] \
    --username [username] \
    --password [personal access token]

Ideally we'd prefer not to store any credentials at all indeed, so leveraging identity based authentication would be much, much better.

If the goal is to allow the artifact CAS to push to OCI but instead of leveraging static/long-lasting credentials short-lived based on OIDC/Identity how would you do it? Could you elaborate a little bit more on your proposed IRSSA approach?

Thank you!!