Skip to content
Draft
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
130 changes: 130 additions & 0 deletions hips/hip-XXXX.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,130 @@
---
hip: 9999
title: "registries.conf support for OCI registry management"
authors: [ "George Jenkins <[email protected]>", "Andy Block <[email protected]>" ]
created: "2025-02-16"
type: "feature"
status: "draft"
---

## Abstract

[registries.conf][registries-conf] is a an alternative specification (to Docker's `docker/config.json`) for managing OCI registry configuration. That supports more advanced features, and has been standardized by other container ecosystem CLI tools (podman, buildah, skopeo, etc)

Support would extend Helm's flexilbity with respect to OCI configuration, including repository prefixes and aliases. This HIP focuces on the implementation of supporting `registries.conf`. Further HIPs to be created for exposing functionality based on utilzing `registries.conf`.

[registries-conf]: <https://github.com/containers/image/blob/main/docs/containers-registries.conf.5.md> "registries.conf specification"

## Motivation

`registries.conf` provides much more flexibible support for OCI registry management than the current Docker CLI based configuration format that Helm uses today.

Including support for repository prefixes (allowing different credentials for different prefixes), registry mirrors, and registry "aliasing". Features Helm would like to introduce. But is currenly blocked by a lack of mechanism to store detail

(in particular, the existing registry configuration Helm uses, Docker’s `$HOME/.docker/config.json`, etc do not support registry aliases nor prefixes)

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is do not support registry aliases nor prefixes the only limitation of Docker’s $HOME/.docker/config.json? I would expect that this proposal could clarify more on the problems and limitations here

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@FeynmanZhou are there other limitations you want to highlight?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure what limitations @FeynmanZhou is referring to, but one limitation this may or may not address is namespaced auth. Like with Harbor, you might have one credential for oci://localhost/production and another for oci://localhost/development and config.json as I recall only supports auth at the domain level.


## Rationale

Utilizing an existing specification / libraries enables Helm immediate build upon an existing standard.
Rather than Helm inventing its own convention.

`registries.conf` was picked as being a format intended for consumption beyond the Docker application container ecosystem.

## Specification

Helm will utilize the `registries.conf` specification when determinging OCI registry information (authentication credentials, etc):
<https://github.com/containers/image/blob/main/docs/containers-registries.conf.5.md>

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You may want to reference a versioned link instead of main branch in case the link is broken in the main branch



`registries.conf` will be preferred, either when a `registries.conf` file already exists on the users system.
Or when Helm supports and a user utilizes functionality that can not be supported by Docker's comnfigurtation file in the future.

<!-- The usage of `registries.conf` will be forced, when in the future -->

For example, a registry login command:
```bash
helm registry login "oci.example.com" --username foo --password bar
```

Will result in the configration exerpt (if, and only if, `registries.conf` exists on the users local system):
```toml
# registries.conf
[[registry]]
prefix = "oci.example.com"
```
Comment on lines +50 to +54
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In registries.conf, it’s not necessary to add a no-op entry for a registry. (In fact it’s currently somewhat annoying to do, although that would probably be best fixed in the parser package.)


```json
# auth.json
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For better or worse, auth.json is intentionally placed into tmpfs filesystems cleared on reboot. (The tools may read other locations in the home directory, but they, without specific instruction otherwise, don’t update them.)

That might be a fairly disruptive change to users of “login”, so it probably should be discussed as such.

"auths": {
...
"oci.example.com": {
"auth": "Zm9vOmJhcgo="
}
}
```

Helm will use the package TBD for updating (and reading) `registries.conf`.

If when reading a registries configation from `registries.conf` results in known configuration Helm doesn't support, Helm must error.
e.g. `location` or non-empty URI path in `prefix`.

An error reading `registries.conf` must result in an error for the user.
Otherwise, users who expect configration from `registries.conf` to be effected, will have a unspected fallback.

To account for existing configration in Docker’s registry configuration, Helm will prefer `registries.conf` when resolving OCI registries (including credentials).
And fall back to the existing store mechanism if `registries.conf` does not contain an entry for the required OCI registry (including if `registries.conf` does not exist).

Helm must expect (and even encourage) users to utilize other tooling to manage `registries.conf`.

## Backwards compatibility

Helm's fallback to Docker's registry configuration ensures the vast majority of existing user workflows remain the same.

However, there are three potential incompatibility scenarios:
2. A corrupt `registries.conf` will cause an error for existing workflows
1. An invalid or incompatible with Helm `registries.conf` entry for the given OCI registry will cause the users workflow to fail
3. Helm’s preference for `registries.conf` will break users who assume credentials are stored in Docker’s registry configuration

The first two can mitigated by users ensuring their systems `registries.conf` is valid, and only includes configuration options Helm supports for the registries they plan to use with Helm.

The last is mitigated by not using `registries.conf` initially unless it exists on the users system.

## Security implications

`registries.conf` introduces a new mechanism for storing OCI credentials, which may introduce credential management vulnerabilities specific to `registries.conf` / `auth.json`

Transitive dependencies of the TBD package for managing registries.conf may introduce security scanner noise (which tends to be a problem in the container library ecosystem)

## How to teach this

Helm's documentation will need to be updated with details of Helm's `registries.conf` support, and fallback to Docker config.

## Reference implementation

<!--
Link to any existing implementation and details about its state, e.g.
proof-of-concept.
-->

## Rejected ideas

### Falling back to Docker’s config upon error reading registries.conf

Falling back upon error means users who expect their configuration to be taken from `registries.conf` will unexpectedly have OCI configuration taken from Docker.
Potentially resulting in difficult to diagnose failures authenticating to the repository.

Rather than "failing fast" and requring users to ensure their configuration to be valid.

## Open issues

- Support for registies.conf in ORAS
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since we use ORAS for this, do we need to get agreement from them before this moves forward?

Copy link

@FeynmanZhou FeynmanZhou Mar 13, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @mattfarina ,

@sabre1041 brought up this proposal to the ORAS community meeting on Mar 5. There is also a GitHub issue tracked in oras-go oras-project/oras-go#918.

As this is a dependency for ORAS from Helm v4, what's the expected timeline to getregisties.conf supported in oras-go?

- Disucss Helm's/ORAS's usage of registries.conf with owners

## References

### ORAS credential store (registry configuration) docs

https://pkg.go.dev/oras.land/oras-go/v2/registry/remote/credentials#NewStoreFromDocker

### registries.conf specification
https://github.com/containers/image/blob/main/docs/containers-registries.conf.5.md