User management in Tectonic is performed in two stages. The first stage authenticates a user, and the second authorizes the user to perform a given set of tasks associated with a role. Authenticating users in Tectonic is managed by Tectonic Identity, authorizing users is controlled by Kubernetes Role-Based Access Control (RBAC). All Tectonic clusters enable RBAC which uses the user information produced by Tectonic Identity to enforce permissions.
Tectonic Identity is an authentication service for both Tectonic Console and
kubectl and allows these components to talk to the API server on an end user's behalf. Users are either defined in the Tectonic
ConfigMap or integrated with Tectonic through an external Identity Provider (IdP).
This document provides an overview of Tectonic Identity, and its use in user authentication and access control.
For more information see:
The three major components of Tectonic Identity are the API server, Tectonic Console, and kubectl.
The Tectonic API Server is expected to enable its OpenID Connect plugin, deferring to Dex for authentication. The API server is not a Dex client.
For Dex, kubectl is a public client. All kubectl instances share a
client_secret, and the
client_secret isn't considered private. kubectl communicates only with the API server.
Tectonic Console communicates with both Dex and the API server. Therefore, Tectonic Console is considered to be an admin client for Dex. To be trusted by both Kubernetes and Dex, ID Tokens are issued to both Console and kubectl. When a user logs in to a Tectonic Console, Dex creates an ID Token for both Console and kubectl allowing Console to both authenticate with Kubernetes and the Dex APIs.
Authorization in Tectonic is controlled by a set of permissions called Roles. Role Bindings grant the permissions associated with a Role to a subject. Subject is defined as a type of account used to access the Tectonic clusters.
For more information, see rbac-config.
Tectonic Identity is built on top of Dex, an open-source OpenID Connect server.
Dex runs natively on top of Tectonic clusters using third-party resources, and drives API server authentication through the OpenID Connect plugin. Clients, such as Tectonic Console and kubectl, act on behalf users who can log in to Tectonic cluster through an identity provider, such as LDAP, that both Tectonic and Dex support.
Dex server issues short-lived, signed tokens on behalf of users. This token response, called ID Token, is a signed JSON web token. ID Token contains names, emails, unique identifiers, and a set of groups that can be used to identify a user. Dex publishes public keys, and Tectonic API server uses these to verify ID Tokens. The username and group information of a user is used in conjunction with RBAC to enforce authorization policy.
Dex does not support hashing and instead strongly recommends that all administrators use TLS. This is achieved by configuring port 636 instead of 389 in the Tectonic Identity