Enhanced Security for Helm Deployments: Gardener Adds Custom CA Support for OCI Registries

Gardener continues to enhance its security and flexibility, particularly for users operating in air-gapped environments or utilizing private infrastructure. A new feature now allows operators to specify a custom Certificate Authority (CA) bundle when pulling Helm charts from OCI registries. This is a significant improvement for environments where registries are secured with custom or self-signed TLS certificates.

The Challenge of Private Registries

Previously, while Gardener supported authentication to private OCI registries using pull secrets, it lacked a way to establish trust with registries secured by custom TLS certificate chains. This prevented Helm charts for extensions and other components from being downloaded due to certificate verification failures.

A New Level of Trust: caBundleSecretRef

To solve this, a new optional field, caBundleSecretRef, has been added to the ociRepository configuration in the following resources:

• operator.gardener.cloud/v1alpha1.Extension
• core.gardener.cloud/v1beta1.ControllerDeployment
• core.gardener.cloud/v1.ControllerDeployment

This field allows you to reference a Kubernetes Secret that contains the necessary CA bundle to verify the OCI registry's TLS certificate.

How It Works

The process is straightforward:

1. Create a CA Bundle Secret: First, you create a standard Kubernetes Secret in the garden namespace. For the Extension resource, create this secret in the runtime garden cluster; for ControllerDeployment, create it in the virtual garden cluster. This secret must contain the PEM-encoded CA certificate bundle under the data key bundle.crt.

2. Label the Secret: For the gardenlet to use this secret, it must be labeled with gardener.cloud/role: oci-ca-bundle. This label allows the secret to be propagated to the seed namespace in the virtual garden.

3. Reference the Secret: Finally, you reference this secret by name in the caBundleSecretRef field within the ociRepository block of your Extension or ControllerDeployment manifest.

Here is an example of how to configure an extension to use a private OCI registry with a custom CA:

First, create the secret containing your CA bundle:

apiVersion: v1
kind: Secret
metadata:
  name: my-registry-ca
  namespace: garden
  labels:
    gardener.cloud/role: oci-ca-bundle
type: Opaque
data:
  bundle.crt: <base64-encoded-ca-bundle>

Next, reference this secret in your Extension definition:

apiVersion: operator.gardener.cloud/v1alpha1
kind: Extension
metadata:
  name: provider-example
spec:
  deployment:
    admission:
      runtimeCluster:
        helm:
          ociRepository:
            repository: registry.example.com/charts/admission-runtime
            tag: v1.0.0
            caBundleSecretRef:
              name: my-registry-ca
            pullSecretRef:
              name: my-pull-secret
      virtualCluster:
        helm:
          ociRepository:
            repository: registry.example.com/charts/admission-application
            tag: v1.0.0
            caBundleSecretRef:
              name: my-registry-ca
            pullSecretRef:
              name: my-pull-secret
    extension:
      helm:
        ociRepository:
          repository: registry.example.com/charts/extension
          tag: v1.0.0
          caBundleSecretRef:
            name: my-registry-ca
          pullSecretRef:
            name: my-pull-secret

or ControllerDeployment definition:

apiVersion: core.gardener.cloud/v1beta1
kind: ControllerDeployment
metadata:
  name: provider-example
spec:
  helm:
    ociRepository:
      repository: registry.example.com/charts/controller
      tag: v1.0.0
      caBundleSecretRef:
        name: my-registry-ca
      pullSecretRef:
        name: my-pull-secret

With this configuration, Gardener will use the provided CA bundle to securely pull the Helm chart, enabling seamless deployment of extensions from your private registries.

This feature is the first step in a broader effort to improve support for custom CAs. Future updates will extend this capability, for example, to support the gardener-node-agent image to be pulled from a private registry during node bootstrapping.

---

Explore Further

• Recording of the presentation
• GitHub Pull Request #13868