Provide configuable Gardener Generic Extensions to Kyma users

[ruanxin]

Created on 2025-07-29 by Xin Ruan (@ruanxin ).

Decision log

Name	Description
Title	Provide Gardener Generic Extensions to Kyma users
Due date	2025-08-31
Status	Proposed on 2025-07-30
Decision type	Choice
Affected decisions

Context

Gardener offers a variety of generic extensions that can enhance a cluster's functionality, such as improving the security baseline with managed services like Falco. kyma-project/kyma-infrastructure-manager#990 The configuration for these extensions is specified in the Gardener Shoot resource.

Within the Kyma environment, the Kyma Infrastructure Manager (KIM) is the component responsible for managing the Shoot resource for a Kyma runtime. However, there is currently no unified solution that allows Kyma users to enable and configure these valuable Gardener extensions.

This decision record outlines and evaluates two potential architectural approaches to bridge this gap, enabling users to customize their Kyma runtimes with generic Gardener extensions.

Decision Drivers

• Security: The solution must follow the principle of least privilege, minimizing access scopes and potential attack vectors.
• User Experience (UX): The process for a user to enable and configure an extension should be straightforward and consistent with existing Kyma and Kubernetes practices.
• Architectural Cohesion: The design should align with the existing Kyma and Gardener architecture, maintaining a clear separation of concerns between components.

Have a unified user experience

1. Treat extension as kyma regular module

apiVersion: operator.kyma-project.io/v1beta2
kind: Kyma
spec:
  channel: fast
  modules:
    - name: api-gateway
    - name: falco
    - name: registry-cache

Open questions:
1. Version and channel subscriptions
- falco allows user to configure version https://github.com/gardener/gardener-extension-shoot-falco-service/blob/main/docs/falco-configuration.md#versions-and-update-strategy
- Registry cache seems no versioning concept.

2. Introduce as extension

kind: Kyma
spec:
  channel: fast
  modules:
    - name: api-gateway
  extensions:
    - name: falco
    - name: registry-cache

Decision

Consequences

References

https://gardener.cloud/docs/extensions/_index#generic-extensions
https://gardener.cloud/docs/gardener/managed_seed/#managedseeds-register-shoot-as-seed

[ruanxin]

Open questions

1. Support user preconfig extension during kyma provsion or not
2. How to monitor extension status
3. SLA for those extensions

[Disper]

@ruanxin thank you for creating this detailed concept! I'm afraid that the current architecture is unfortunately not unified and different depending on the extension we already configure in KIM (shoot-auditlog-service, shoot-oidc-service, shoot-dns-service, shoot-cert-service, shoot-networking-filter). Don't get me wrong, I appreciate that you're challenging the current approach. So, while I'm not sure that we could allow the configuration of all existing extensions generically (e.g., we can't afford losing audit logs by letting customers replace shoot-auditlog-service configuration), having that possibility for some could greatly reduce future maintenance effort.

For an extension to be considered generic IMO, we would need to:

1. Agree that customers will be able to learn whether their extension was configured properly or not, and if not, then what was the reason.
2. Agree that customers will be able to easily configure it. For example, if they are familiar with the configuration of shoot-networking-filter in BTP Cockpit, would we consider changing the experience to a generic one to be better? Would a customer be fine with knowing all the details required by Gardener in this particular extension config? Or can we as a managed solution, provide some value by hiding some complexity?
3. It should be explicitly whitelisted by Kyma organization (again, the auditlog example)

Before we decide to invest in a generic solution, it would be good to have a few (at least 2-3) extension examples that would look great to configure generically before we continue with the concept, so we don't fall into YAGNI trap.