Credential support for registry mirror

[c-pius]

How to categorize this issue?

/area security
/kind enhancement

What would you like to be added:

Registry cache supports configuring upstream credentials. For registry mirror, there doesn't seem to be such option. Is this understanding correct?

If so, would it be possible to add credential support for registry mirror? More specifically, we would probably also need AWS IAM authentication for it: #240

Why is this needed:

We are currently working on bringing Kyma to SovCloud. For this, we are transferring images of workloads we deploy to shoots from our public registry to a private cloud registry. Then, when deploying the workloads, we have some custom logic exchanging the host from public to private registry.

We were wondering if this custom logic could be replaced by using the registry mirror extension. We already PoCed and ran into problems regarding the authentication.

[networkhell]

I did a little research what needs to be done to get this implemented:

Currently the gardener operatingsystemconfig extension lacks the support for header based authentication which I guess is the best available approach to mirror authentication - See: https://github.com/containerd/containerd/blob/main/docs/hosts.md#header-fields-in-the-toml-table-format

Get authentication for mirrors working:

1. Add support for the server field and the override_path option, and allow URL paths to be part of the serverand host fields of the mirrorConfig to a.) support non-conformant registries (like the widely used harbor registry) and b.) be able to control if a fallback to upstream is allowed
2. Extend the gardener operatingsystemconfig to support custom headers in the containerd RegistryHost config
3. Add support for a Secret Reference containing the actual credentials for a specific registry mirror

I am willing to help with 1. and 3.

[gardener-ci-robot]

The Gardener project currently lacks enough active contributors to adequately respond to all issues.
This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 60d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 60d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as active with /lifecycle active
• Mark this issue as frozen with /lifecycle frozen
• Mark this issue as fresh with /remove-lifecycle stale
• Mark this issue as rotten with /lifecycle rotten
• Close this issue with /close

/lifecycle stale

[hoffimar]

/remove-lifecycle stale