Add support for private image access

[dimitar-kostadinov]

How to categorize this PR?

/kind enhancement, api-change

What this PR does / why we need it:
This PR introduce support for private image access. RegistryCache is extended with optional field SecretReferenceName that contains reference to upstream registry credentials.
The credentials are provided by the user in the gardener project as a immutable kubernetes secret (e.g. ro-docker-secret). The secret is defined in the Shoot spec as resource reference under resources and secretReferenceName points to this reference:

apiVersion: core.gardener.cloud/v1beta1
kind: Shoot
...
spec:
  extensions:
  - type: registry-cache
    providerConfig:
      apiVersion: registry.extensions.gardener.cloud/v1alpha1
      kind: RegistryConfig
      caches:
      - upstream: docker.io
        size: 800Mi
        garbageCollection:
          enabled: true
        secretReferenceName: docker-secret
...
  resources:
  - name: docker-secret
    resourceRef:
      apiVersion: v1
      kind: Secret
      name: ro-docker-secret
...

During Shoot creation the secret is copied in the shoot namespace in the Seed with ref- prefix in the name.
When registry cache is deployed, a secret with the same credentials is added (e.g. registry-docker-io-7211f728) in the managed resource and cache registry access the credentials through env vars with data from this secret.

Which issue(s) this PR fixes:
Part of #3

Special notes for your reviewer:

Release note:

The registry-cache now supports providing credentials for private upstreams. For more details, see [How to provide credentials for upstream registry?](https://github.com/gardener/gardener-extension-registry-cache/blob/v0.3.0/docs/usage/upstream-credentials.md).

[gardener-prow]

@dimitar-kostadinov: The label(s) kind/enhancement, cannot be applied, because the repository doesn't have them.

In response to this:

How to categorize this PR?

/kind enhancement, api-change

What this PR does / why we need it:
This PR introduce support for private image access. RegistryCache is extended with optional field SecretReferenceName that contains reference to upstream registry credentials.
The credentials are provided by the user in the gardener project as a immutable kubernetes secret (e.g. ro-docker-secret). The secret is defined in the Shoot spec as resource reference under resources and secretReferenceName points to this reference:

apiVersion: core.gardener.cloud/v1beta1
kind: Shoot
...
spec:
 extensions:
 - type: registry-cache
   providerConfig:
     apiVersion: registry.extensions.gardener.cloud/v1alpha1
     kind: RegistryConfig
     caches:
     - upstream: docker.io
       size: 800Mi
       garbageCollection:
         enabled: true
       secretReferenceName: docker-secret
...
 resources:
 - name: docker-secret
   resourceRef:
     apiVersion: v1
     kind: Secret
     name: ro-docker-secret
...

During Shoot creation the secret is copied in the shoot namespace in the Seed with ref- prefix in the name.
When registry cache is deployed, a secret with the same credentials is added (e.g. registry-docker-io-7211f728) in the managed resource and cache registry access the credentials through env vars with data from this secret.

Which issue(s) this PR fixes:
Part of #3

Special notes for your reviewer:

Release note:

Introduce `caches[].secretReferenceName` optional field that contains resource reference to upstream registry credentials.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[dimitar-kostadinov]

/retest

[ialidzhikov]

Nice work! Minor suggestions inline.

[ialidzhikov]

/test pull-gardener-extension-registry-cache-e2e-kind

[gitguardian]

⚠️ GitGuardian has uncovered 2 secrets following the scan of your pull request.

Please consider investigating the findings and remediating the incidents. Failure to do so may lead to compromising the associated services or software components.

🔎 Detected hardcoded secrets in your pull request

GitGuardian id	Secret	Commit	Filename
-	Generic High Entropy Secret	f681c18	pkg/component/registrycaches/registry_caches_test.go	View secret
-	Generic High Entropy Secret	564cd95	pkg/component/registrycaches/registry_caches_test.go	View secret

🛠 Guidelines to remediate hardcoded secrets

1. Understand the implications of revoking this secret by investigating where it is used in your code.
2. Replace and store your secrets safely. Learn here the best practices.
3. Revoke and rotate these secrets.
4. If possible, rewrite git history. Rewriting git history is not a trivial act. You might completely break other contributing developers' workflow and you risk accidentally deleting legitimate data.

To avoid such incidents in the future consider

• following these best practices for managing and storing secrets including API keys and other credentials
• install secret detection on pre-commit to catch secret before it leaves your machine and ease remediation.

---

<sup>🦉 GitGuardian detects secrets in your source code to help developers and security teams secure the modern development process. You are seeing this because you or someone else with access to this repository has authorized GitGuardian to scan your pull request.

Our GitHub checks need improvements? Share your feedbacks!</sup>

[ialidzhikov]

/lgtm

[gardener-prow]

LGTM label has been added.

Git tree hash: d7ba09ef7d3a02f51ea002343911b6f3228d7c4d

[gardener-prow]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: ialidzhikov

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [ialidzhikov]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment