Authentication and authorization architecture

Details on distributed authentication and authorization between clusters

Authentication

DKP UI comes with a pre-configured authentication Dex identity broker and provider.

Kubernetes, Kommander, and Dex do not store any user identities. The Kommander installation comes with default admin static credentials. These credentials should only be used to access the DKP UI for configuring an external identity provider. Currently, there is no way to update these credentials, so they should be treated as backup credentials and not used for normal access.

The DKP UI admin credentials are stored as a secret. They never leave the boundary of the UI cluster and are never shared to any other cluster.

The Dex service issues an OIDC ID token on successful user authentication. Other platform applications use the ID token as an authentication proof. User identity to the Kubernetes API server is provided by the kube-oidc-proxy platform service that reads the identity from an ID token. Web requests to DKP UI access are authenticated by the traefik forward auth platform service.

The kube-oidc-proxy service authenticates kubectl CLI requests using the Kubernetes API Server Go library. This library requires that if an email_verified claim is present, it must be set to true, even if the insecureSkipEmailVerified: true flag is configured in the Dex connector. Thus, ensure that the OIDC provider is configured to set the email_verified field to 'true'.

A user identity is shared across a UI cluster and all other attached clusters.

Attached clusters

A newly attached cluster has federated kube-oidc-proxy, dex-k8s-authenticator, and traefik-forward-auth platform applications. These platform applications are configured to accept UI cluster Dex issued ID tokens.

When the traefik-forward-auth is used as a Traefik Ingress authenticator, it checks if the user identity was issued by the Kommander cluster Dex service. An anonymous user is redirected to the UI cluster Dex service to authenticate and confirm their identity.

Never enter your own credentials on any of the attached clusters. On the UI cluster use the static admin credentials or an external identity provider (IDP).

Authorization

There is no centralized authorization component in Kommander. Each component and service makes its own authorization decisions based on user identity.