Skip to content
Open
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
137 changes: 137 additions & 0 deletions hips/hip-XXXX.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,137 @@
---
hip: 9999
title: "registries.conf support for OCI registry management"
authors: [ "George Jenkins <gvjenkins@gmail.com>", "Andy Block <andy@redhat.com>" ]
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
authors: [ "George Jenkins <gvjenkins@gmail.com>", "Andy Block <andy@redhat.com>" ]
authors: [ "George Jenkins <gvjenkins@gmail.com>", "Andrew Block <andy.block@gmail.com>" ]

created: "2025-02-16"
type: "feature"
status: "draft"
---

## Abstract

[registries.conf][registries-conf] is an alternative specification for managing client OCI registry configuration that supports more advanced features, compared to Docker's `docker/config.json` that Helm currently uses today.

This HIP focuses on the initial implementation of supporting `registries.conf` within Helm.
Further HIPs will be created to expose additional functionality based on utilizing `registries.conf`.

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

## Motivation

Helm uses Docker's `docker/config.json` to store client OCI registry configuration today.

`registries.conf` provides much more advanced functionality for client OCI registry management than `docker/config.json`.
Notably:

- support for repository prefixes (allowing different credentials for different prefixes)
- registry mirrors
- registry "aliasing"—features
Copy link
Contributor

Choose a reason for hiding this comment

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

Add:

  • allowing/denying registries


Helm would like to introduce features depending on these functionalities. Supporting `registries.conf` would enable them without Helm having to create or implement its own mechanisms.
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
Helm would like to introduce features depending on these functionalities. Supporting `registries.conf` would enable them without Helm having to create or implement its own mechanisms.
Helm would like to introduce features leaning upon these functionalities. Supporting `registries.conf` would enable them without Helm having to create or implement its own mechanisms.

With `registries.conf` having been standardized by other container ecosystem CLI tools (podman, buildah, skopeo, etc.).
Copy link
Contributor

Choose a reason for hiding this comment

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

Should we also mention that these are also CNCF hosted tools/projects


## Rationale

Utilizing an existing specification and libraries enables Helm to immediately build upon an existing standard, rather than inventing its own convention.

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

ORAS (the library Helm uses for supporting OCI functionality) has planned support for `registries.conf` client-side OCI registry management.
Copy link
Contributor

Choose a reason for hiding this comment

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

Should we include reference(s) to the ORAS specific features?


## Specification

Helm will utilize the `registries.conf` specification when determining 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 user's system, or when Helm supports and a user utilizes functionality that cannot be supported by Docker's configuration file in the future.
Copy link
Contributor

Choose a reason for hiding this comment

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

Should we indicate where we will search for entries?


<!-- 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 configuration excerpt (if, and only if, `registries.conf` exists on the user's local system):

```toml
# registries.conf
[[registry]]
prefix = "oci.example.com"
```
Comment on lines +58 to +62
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="
}
}
```

Choose a reason for hiding this comment

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

Do you want to mention policy.json around here since that is used for allow/deny?

Choose a reason for hiding this comment

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

I guess along these lines, hopefully certs.d would be supported. That could be out of the scope for this document though.


Helm will use ORAS v3 for updating (and reading) `registries.conf` (TODO: link to ORAS v3 `registries.conf` implementation).
Copy link
Contributor

Choose a reason for hiding this comment

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

Should we call out the fact that ORAS v3 development has yet to begin as of this date

Choose a reason for hiding this comment

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

I wouldn't characterize it as hasn't begun. An oras-go v2 branch was cut and there are several PRs out for v3. Nothing has merged though.


If reading a registry configuration from `registries.conf` results in a known configuration that Helm doesn't support, Helm must report a warning (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 configuration from `registries.conf` to be effective will have an unexpected fallback.

To account for existing configuration in Docker’s registry configuration, Helm will prefer `registries.conf` when resolving OCI registries (including credentials), and fall back to the existing storage 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`.
Copy link
Contributor

Choose a reason for hiding this comment

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

Or at least provide some form of guidance


## 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:

Choose a reason for hiding this comment

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

I think there is another possibility here where the user doesn't have a registries.conf but has a auth.json My understanding is the registries.conf is not required.

1. A corrupt `registries.conf` will cause an error for existing workflows
2. An invalid or incompatible with Helm `registries.conf` entry for the given OCI registry will cause the user's workflow to fail
3. Helm’s preference for `registries.conf` will break users who assume credentials are stored in Docker’s registry configuration
Copy link
Contributor

Choose a reason for hiding this comment

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

Do we want to include an explicit option to opt out of the feature and fall back. That way, we are covered for all scenarios


The first two can be mitigated by users ensuring their system's `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 user's 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 requiring users to ensure their configuration is valid.

## Open issues

- ORAS `registries.conf` support: <https://github.com/oras-project/oras-go/issues/918>
- Is the release and backwards compatibility plan good enough?
- <strike>Discuss Helm's/ORAS's potential usage of `registries.conf` with `registries.conf` owners</strike>

## References

### ORAS credential store (Docker 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>