Skip to content

Identity and Access Management

Architecture

The access and User management on Open Sovereign Cloud is based on OpenID Connect (OIDC).

A Keycloak instance is located on the Garden cluster. This instance is responsible for Identity and Access management for the customer.

Several instances of the Dex OIDC provider handle the authentication requests. Dex is located on the Garden cluster and on each Seed cluster, and it forwards authentication requests to the Keycloak.

The simplified architecture is shown in the diagram below.

Keycloak-ops-users

Provisioning of Customer User Self-Management

During the onboarding process OSC creates one or more user specified by the customer — the Realm owners. These users will be granted with rights to create and manage additional customer users and groups.

OSC provides access into the Customer Realm Management Console for these users by providing the necessary links and initial credentials.

The Realm owners have permissions:

  • to manage Gardener Projects (only for Dedicated environments)
  • to manage users and groups of Gardener Projects
  • to manage users, groups and roles in Keycloak

The role enabling Realm owners of Dedicated environment to manage projects is called gardener.cloud:customer:osc-roles is defined with the following permissions:

core.gardener.cloud resource get / list / watch create / delete / patch / update
projects
cloudprofiles
exposureclasses
shoots

Tip

It is recommended to have at least 3 users responsible for user self-management.

Realms in Keycloak

There are two Realms created in Keycloak:

  • The User Management Realm: This realm has to be used to create Users, Groups and Roles. It is named as:

    • customer — for Dedicated environments
    • <customer_name> — for Shared environments
  • The Authentication Realm: This realm is used by the Dex clients to handle authentication requests. The User Management Realm's contents are synchronized here. It is named as:

    • <garden_cluster_name>* (e.g. garden1)

Default Roles for Shoot access

The following roles are automatically provisioned to the customer Realm for each created Shoot cluster:

  • customer:<project_name>--<shoot_name>:cluster-admin — grants administration privileges to users
  • customer:<project_name>--<shoot_name>:cluster-viewer — grants read only privileges to users

These roles can be assigned to users or groups to provide necessary access level to the respective Shoot clusters.

Custom Roles for Shoot Access

apiVersion: sso.osc.t-systems.com/v1
kind: RealmRole
metadata:
  name: myrole1
  namespace: garden-myproject
spec:
  realm: customer
  role: myproject--myshoot:myrole1

The specified Realm role will be created in Keycloak in the User Management Realm (customer), and automatically replicated to the Authentication Realm.

The Realm role then can be assigned to the needed Groups or Users in Keycloak.

Finally the needed (Cluster)RoleBindings can be created.

Tip

In the (Cluster)RoleBinding manifest, the role's name has to be prefixed with oidc:.

Example

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: myrolebinding1
  namespace: example
roleRef:
  kind: Role
  name: myrole1
  apiGroup: rbac.authorization.k8s.io
subjects:
- kind: Group
  # The oidc: prefix is necessary
  name: oidc:myproject--myshoot:role1
  apiGroup: rbac.authorization.k8s.io

Authentication

Authentication to Gardener

The user authenticates to Gardener to perform the following tasks:

  • Create and delete Gardener Projects — only on Dedicated environments
  • Manage users and groups of a Gardener Project
  • Create, modify and delete Shoot clusters

There are two methods to perform these tasks:

  • Via the Gardener Dashboard web interface
  • Via any Kubernetes management tool (kubectl, k9s, Lens, etc.), using a kubeconfig file defining OIDC authentication (commonly called "OIDC kubeconfig").

Tip

The Gardener Dashboard runs on the Garden cluster. If using standard Kubernetes management tools (kubectl, etc.) to perform tasks otherwise performed via the Gardener Dashboard, connect with them to the Garden Cluster.

Authentication to Gardener Dashboard

The Gardener Dashboards's login screen is displayed. Select the OIDC option and press LOGIN.

OIDC-login

The Dex OIDC Connector's screen is displayed. Select the Authentication Realm, with the name identical to the Garden cluster.

customer dex

A series of login screens from Keycloak will be displayed. The first screen's title is the name of the Authentication Realm. On this screen, do not enter any credentials, instead among the options listed below Or sign in with select the Customer Management Realm, which is named as customer.

customer Keycloak

The next screens title is the User Management Realm. Enter the credentials and press Sign in.

customer Keycloak2

Obtaining the Garden cluster's kubeconfig

To be able to connect to the Garden cluster via the kubectl tool, the cluster's kubeconfig file is needed. This can be downloaded from the Gardener Dashboard.

After logging in to the dashboards, click on the user profile avatar in the top right corner and select MY ACCOUNT.

my-account

On the Account page's Access panel, the kubeconfig can be displayed, downloaded or, after expanding the panel, copied to the clipboard.

gard config2

Authentication to a Shoot Cluster

The user authenticates to a Shoot cluster to work with the Kubernetes resources of the cluster, according to the user's permission level.

The Shoot cluster can be accessed via any Kubernetes management tool (kubectl, k9s, Lens, etc.) using a kubeconfig file either:

  • defining static keys — "static kubeconfig"
  • defining OIDC authentication — "OIDC kubeconfig"

Obtaining the Shoot cluster's kubeconfig

The OIDC-enabled kubeconfig is available as a Kubernetes secret on the Garden cluster. It can be obtained using the Garden's kubeconfig (see above), from the namespace of the Shoot's project.

kubectl get secret -n garden-<project_name> <shoot_name>.kubeconfig-oidc --template="{{.data.kubecfg|base64decode}}"

Authentication to Keycloak

The user authenticates to Keycloak to perform common user, group and role management tasks.

For the related documentation, see User Management in Keycloack

Using OIDC authentication with kubectl

Out of the box, the kubectl program does not support authentication via OIDC. This functionality can be enabled via the kubelogin kubectl plugin.

After the plugin is enabled and the context set to the OIDC-enabled Garden or Shoot cluster, the first kubectl command will open up the Dex login screen in the default browser. From this point on the login process is the same as described in the Authentication to Gardener Dashboard.

After a successful authentication, a page displaying "Authentication successful" is displayed, and the issued kubectl command produces its output. The browser page can be closed, the subsequent commands will use the created authentication tokens.