그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그
5 minute read
Access to the Garden Cluster for Extensions
Extensions that are installed on seed clusters via a
ControllerInstallation can simply read the kubeconfig file specified by the
GARDEN_KUBECONFIG environment variable to create a garden cluster client.
With this, they use a short-lived token (valid for
12h) associated with a dedicated
ServiceAccount in the
seed-<seed-name> namespace to securely access the garden cluster.
ServiceAccounts are granted permissions in the garden cluster similar to gardenlet clients.
gardenlet has been the only component running in the seed cluster that has access to both the seed cluster and the garden cluster.
Accordingly, extensions running on the seed cluster didn’t have access to the garden cluster.
Starting from Gardener
v1.74.0, there is a new mechanism for components running on seed clusters to get access to the garden cluster.
gardenlet runs an instance of the
TokenRequestor for requesting tokens that can be used to communicate with the garden cluster.
Using Gardenlet-Managed Garden Access
By default, extensions are equipped with secure access to the garden cluster using a dedicated
ServiceAccount without requiring any additional action.
They can simply read the file specified by the
GARDEN_KUBECONFIG and construct a garden client with it.
When installing a
ControllerInstallation, gardenlet creates two secrets in the installation’s namespace: a generic garden kubeconfig (
generic-garden-kubeconfig-<hash>) and a garden access secret (
Note that the
ServiceAccount created based on this access secret will be created in the respective
seed-* namespace in the garden cluster and labelled with
Additionally, gardenlet injects
volumeMounts, and two environment variables into all (init) containers in all objects in the
batch API groups:
GARDEN_KUBECONFIG: points to the path where the generic garden kubeconfig is mounted.
SEED_NAME: set to the name of the
Seedwhere the extension is installed. This is useful for restricting watches in the garden cluster to relevant objects.
If an object already contains the
GARDEN_KUBECONFIG environment variable, it is not overwritten and injection of
volumeMounts is skipped.
For example, a
Deployment deployed via a
ControllerInstallation will be mutated as follows:
- name: gardener-extension-provider-local
- name: GARDEN_KUBECONFIG
- name: SEED_NAME
- mountPath: /var/run/secrets/gardener.cloud/garden/generic-kubeconfig
- name: garden-kubeconfig
- key: kubeconfig
- key: token
The generic garden kubeconfig will look like this:
- name: extension
Manually Requesting a Token for the Garden Cluster
Seed components that need to communicate with the garden cluster can request a token in the garden cluster by creating a garden access secret.
This secret has to be labelled with
This will instruct gardenlet to create a new
example in its own
seed-<seed-name> namespace in the garden cluster, request a token for it, and populate the token in the secret’s data under the
Permissions in the Garden Cluster
SeedAuthorizer and the
SeedRestriction plugin handle extensions clients and generally grant the same permissions in the garden cluster to them as to gardenlet clients.
With this, extensions are restricted to work with objects in the garden cluster that are related to seed they are running one just like gardenlet.
Note that if the plugins are not enabled, extension clients are only granted read access to global resources like
CloudProfiles (this is granted to all authenticated users).
There are a few exceptions to the granted permissions as documented here.
If an extension needs access to additional resources in the garden cluster (e.g., extension-specific custom resources), permissions need to be granted via the usual RBAC means.
Let’s consider the following example: An extension requires the privileges to create
authorization.k8s.io/v1.SubjectAccessReviews (which is not covered by the “default” permissions mentioned above).
This requires a human Gardener operator to create a
ClusterRole in the garden cluster with the needed rules:
Note the label
authorization.gardener.cloud/extensions-serviceaccount-selector which contains a label selector for
There is a controller part of
gardener-controller-manager which takes care of maintaining the respective
It binds all
ServiceAccounts in the seed namespaces in the garden cluster (i.e., all extension clients) whose labels match.
You can read more about this controller here.
If an extension wants to create a dedicated
ServiceAccount for accessing the garden cluster without automatically inheriting all permissions of the gardenlet, it first needs to create a garden access secret in its extension namespace in the seed cluster:
❗️️Do not prefix the service account name with
extension- to prevent inheriting the gardenlet permissions! It is still recommended to add the extension name (e.g., as a suffix) for easier identification where this
ServiceAccount comes from.
Next, you can follow the same approach described above.
authorization.gardener.cloud/extensions-serviceaccount-selector annotation should not contain
controllerregistration.core.gardener.cloud/name=<extension-name> but rather custom labels, e.g.
This way, the created
ServiceAccount will only get the permissions of above
ClusterRole and nothing else.
Renewing All Garden Access Secrets
Operators can trigger an automatic renewal of all garden access secrets in a given
Seed and their requested
ServiceAccount tokens, e.g., when rotating the garden cluster’s
ServiceAccount signing key.
For this, the
Seed has to be annotated with