H4HIP: Helm support registries.conf for OCI configuration/auth info
#391
Conversation
gjenkins8
force-pushed
the
gjenkins/registries.conf_support
branch
from
99c6d56 to
cea4a1d
Compare
| ```toml | ||
| # registries.conf | ||
| [[registry]] | ||
| prefix = "oci.example.com" | ||
| ``` |
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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.
|
|
||
| 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) |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
@FeynmanZhou are there other limitations you want to highlight?
There was a problem hiding this comment.
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.
| ## 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> |
There was a problem hiding this comment.
You may want to reference a versioned link instead of main branch in case the link is broken in the main branch
Co-authored-by: Andrew Block <andy.block@gmail.com> Signed-off-by: George Jenkins <gvjenkins@gmail.com>
|
|
||
| ## Open issues | ||
|
|
||
| - Support for registies.conf in ORAS |
There was a problem hiding this comment.
Since we use ORAS for this, do we need to get agreement from them before this moves forward?
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
I like the idea of supporting this in Helm.
We may want to note in this HIP that registry aliases would help with airgapped environments—an important use case for Helm users—where an in-cluster registry would replace external registries defined as the storage for chart dependencies.
There are existing means in Helm to overwrite a registry for container images in airgap—many charts make images/oci registries configurable, but even if they do not, this can be done with a post-renderer. However, there is currently no way to do this with the repository specified by chart dependencies without manually manipulating the Chart.yaml.
|
Note that the Podman tools that standardize registries.conf have been accepted as a CNCF Sandbox project: cncf/sandbox#309 |
|
Also note this related issue: helm/helm#13615 |
No description provided.