Skip to content

Latest commit

 

History

History
75 lines (56 loc) · 3.99 KB

shoot_access.md

File metadata and controls

75 lines (56 loc) · 3.99 KB
Raw

Accessing Shoot Clusters

After creation of a shoot cluster, end-users require a kubeconfig to access it. There are several options available to get to such kubeconfig.

Static Token Kubeconfig

This kubeconfig contains a static token and provides cluster-admin privileges. It is created by default and persisted in the <shoot-name>.kubeconfig secret in the project namespace in the garden cluster.

apiVersion: core.gardener.cloud/v1beta1
kind: Shoot
...
spec:
  kubernetes:
    enableStaticTokenKubeconfig: true
...

It is not the recommended method to access the shoot cluster as the static token kubeconfig has some security flaws associated with it:

  • The static token in the kubeconfig doesn't have any expiration date. Read this document to learn how to rotate the static token.
  • The static token doesn't have any user identity associated with it. The user in that token will always be system:cluster-admin irrespective of the person accessing the cluster. Hence, it is impossible to audit the events in cluster.

shoots/adminkubeconfig subresource

The shoots/adminkubeconfig subresource allows users to dynamically generate temporary kubeconfigs that can be used to access shoot cluster with cluster-admin privileges. The credentials associated with this kubeconfig are client certificates which have a very short validity and must be renewed before they expire (by calling the subresource endpoint again).

The username associated with such kubeconfig will be the same which is used for authenticating to the Gardener API. Apart from this advantage, the created kubeconfig will not be persisted anywhere.

In order to request such a kubeconfig, you can run the following commands:

export NAMESPACE=my-namespace
export SHOOT_NAME=my-shoot
kubectl create \
    -f <path>/<to>/kubeconfig-request.json \
    --raw /apis/core.gardener.cloud/v1beta1/namespaces/${NAMESPACE}/shoots/${SHOOT_NAME}/adminkubeconfig | jq -r ".status.kubeconfig" | base64 -d

Here, the kubeconfig-request.json has the following content:

{
    "apiVersion": "authentication.gardener.cloud/v1alpha1",
    "kind": "AdminKubeconfigRequest",
    "spec": {
        "expirationSeconds": 1000
    }
}

The gardenctl-v2 tool makes it easy to target shoot clusters and automatically renews such kubeconfig when required.

OpenID Connect

The kube-apiserver of shoot clusters can be provided with OpenID Connect configuration via the ShootSpec:

apiVersion: core.gardener.cloud/v1beta1
kind: Shoot
...
spec:
  kubernetes:
    oidcConfig:
      ...

It is the end-user's responsibility to incorporate the OpenID Connect configurations in kubeconfig for accessing the cluster (i.e., Gardener will not automatically generate kubeconfig based on these OIDC settings). The recommended way is using the kubectl plugin called kubectl oidc-login for OIDC authentication.

If you want to use the same OIDC configuration for all your shoots by default then you can use the ClusterOpenIDConnectPreset and OpenIDConnectPreset API resources. They allow defaulting the .spec.kubernetes.kubeAPIServer.oidcConfig fields for newly created Shoots such that you don't have to repeat yourself every time (similar to PodPreset resources in Kubernetes). ClusterOpenIDConnectPreset specified OIDC configuration applies to Projects and Shoots cluster-wide (hence, only available to Gardener operators) while OpenIDConnectPreset is Project-scoped. Shoots have to "opt-in" for such defaulting by using the oidc=enable label.

For further information on (Cluster)OpenIDConnectPreset, refer to this document.