By default, Kontena Lens support authentication with tokens.
Authentication of normal users will require additional configuration since normal users are assumed to be managed by an outside, independent service. For this purpose, Kubernetes support OpenID Connect ("OIDC") authentication flow. Kontena Lens comes with OIDC provider that will automatically integrate with Kubernetes OIDC authentication flow (unless disabled / already in use; see important note below) and will provide connectors to following identity providers:
Once configured, users may access Kontena Lens using the same credentials as in the selected identity provider.
IMPORTANT NOTE! Some managed Kubernetes solutions (for example Amazon AWS EKS and Google Cloud GKE) are made available with a vendor specific, built-in OIDC provider that can not be replaced or configured. This OIDC provider is often pre-configured and connected to IAM for authentication. Kontena Lens OIDC provider or connectors can not be used in any such environment. You are stuck using IAM (or whatever your vendor has decided) and generating tokens for your users to authenticate themselves.
Regardless of your authentication settings, OIDC providers or not, you can also authenticate and open secure access to Kontena Lens directly from command line using kubectl lens plugin. If you want to improve quality of life for yourself or your team, you should definitely check it out!
GitHub connector uses the GitHub OAuth2 flow to identify the end user through their GitHub account. When a client redeems a refresh token through Kontena Lens, Lens will re-query GitHub to update user information in the ID Token. To do this, Kontena Lens stores a readonly GitHub access token in its datastore. Users that reject Kontena Lens access through GitHub will also revoke all clients which authenticated them through GitHub.
Register a new application with GitHub ensuring the callback URL is
https://kontena-lens-address/idp/callback. Registered application client id and client secret needs to be configured via
apiVersion: v1 kind: Secret metadata: name: idp-connector-github namespace: kontena-lens type: Opaque data: client-id: "base64-encoded-client-id" client-secret: "base64-encoded-client-secret"
Kontena Lens Installer configuration
authentication: connectors: - type: github id: github name: github config: clientID: $GITHUB_CLIENT_ID clientSecret: $GITHUB_CLIENT_SECRET # Optional organizations and teams, communicated through the "groups" scope. # # Kontena Lens queries the following organizations for group information if the # "groups" scope is provided. Group claims are formatted as "(org):(team)". # For example if a user is part of the "engineering" team of the "acme" # org, the group claim would include "acme:engineering". # # If orgs are specified in the config then user MUST be a member of at least one of the specified orgs to # authenticate with Kontena Lens. # # If neither 'org' nor 'orgs' are specified in the config and 'loadAllGroups' setting set to true then user # authenticate with ALL user's Github groups. Typical use case for this setup: # provide read-only access to everyone and give full permissions if user has 'my-organization:admins-team' group claim. orgs: - name: my-organization # Include all teams as claims. - name: my-organization-with-teams # A white list of teams. Only include group claims for these teams. teams: - red-team - blue-team # Flag which indicates that all user groups and teams should be loaded. loadAllGroups: false # Optional choice between 'name' (default), 'slug', or 'both'. # # As an example, group claims for member of 'Site Reliability Engineers' in # Acme organization would yield: # - ['acme:Site Reliability Engineers'] for 'name' # - ['acme:site-reliability-engineers'] for 'slug' # - ['acme:Site Reliability Engineers', 'acme:site-reliability-engineers'] for 'both' teamNameField: slug # flag which will switch from using the internal GitHub id to the users handle (@mention) as the user id. # It is possible for a user to change their own user name but it is very rare for them to do so useLoginAsID: false
GitLab connector uses the GitLab OAuth2 flow to identify the end user through their GitLab account. You can use this option with gitlab.com, GitLab community or enterprise edition.
When a client redeems a refresh token through Kontena Lens, Lens will re-query GitLab to update user information in the ID Token. To do this, Kontena Lens stores a readonly GitLab access token in its datastore. Users that reject Kontena Lens access through GitLab will also revoke all clients which authenticated them through GitLab.
Register a new application via User Settings -> Applications ensuring the callback URL is
https://kontena-lens-address/idp/callback. The application requires the user to grant the
openid scopes. The latter is required only if group membership is a desired claim.
Registered application client id and client secret needs to be configured via
apiVersion: v1 kind: Secret metadata: name: idp-connector-gitlab namespace: kontena-lens type: Opaque data: client-id: "base64-encoded-application-id" client-secret: "base64-encoded-client-secret"
Kontena Lens Installer configuration
authentication: connectors: - type: gitlab id: gitlab name: GitLab config: # optional, default = https://gitlab.com # baseURL: https://gitlab.com # Credentials can be string literals or pulled from the environment. clientID: $GITLAB_APPLICATION_ID clientSecret: $GITLAB_CLIENT_SECRET # Optional groups whitelist, communicated through the "groups" scope. # If `groups` is omitted, all of the user's GitLab groups are returned when the groups scope is present. # If `groups` is provided, this acts as a whitelist - only the user's GitLab groups that are in the configured `groups` below will go into the groups claim. Conversely, if the user is not in any of the configured `groups`, the user will not be authenticated. groups: - my-group
The LDAP connector allows email/password based authentication, backed by a LDAP directory.
The connector executes two primary queries:
- Finding the user based on the end user's credentials.
- Searching for groups using the user entry.
User entries are expected to have an email attribute (configurable through
emailAttr), and a display name attribute (configurable through
*Attr attributes could be set to "DN" in situations where it is needed but not available elsewhere, and if "DN" attribute does not exist in the record.
For the purposes of configuring this connector, "DN" is case-sensitive and should always be capitalised.
Kontena Lens Installer example configuration
authentication: connectors: - type: ldap # Required field for connector id. id: ldap # Required field for connector name. name: LDAP config: # Host and optional port of the LDAP server in the form "host:port". # If the port is not supplied, it will be guessed based on "insecureNoSSL", # and "startTLS" flags. 389 for insecure or StartTLS connections, 636 # otherwise. host: ldap.example.com:636 # Following field is required if the LDAP host is not using TLS (port 389). # Because this option inherently leaks passwords to anyone on the same network # as dex, THIS OPTION MAY BE REMOVED WITHOUT WARNING IN A FUTURE RELEASE. # # insecureNoSSL: true # If a custom certificate isn't provide, this option can be used to turn on # TLS certificate checks. As noted, it is insecure and shouldn't be used outside # of explorative phases. # # insecureSkipVerify: true # When connecting to the server, connect using the ldap:// protocol then issue # a StartTLS command. If unspecified, connections will use the ldaps:// protocol # # startTLS: true # A raw certificate file can be provided inline. # rootCAData: ( base64 encoded PEM file ) # The DN and password for an application service account. The connector uses # these credentials to search for users and groups. Not required if the LDAP # server provides access for anonymous auth. # Please note that if the bind password contains a `$`, it has to be saved in an # environment variable which should be given as the value to `bindPW`. bindDN: uid=seviceaccount,cn=users,dc=example,dc=com bindPW: password # The attribute to display in the provided password prompt. If unset, will # display "Username" usernamePrompt: SSO Username # User search maps a username and password entered by a user to a LDAP entry. userSearch: # BaseDN to start the search from. It will translate to the query # "(&(objectClass=person)(uid=<username>))". baseDN: cn=users,dc=example,dc=com # Optional filter to apply when searching the directory. filter: "(objectClass=person)" # username attribute used for comparing user entries. This will be translated # and combined with the other filter as "(<attr>=<username>)". username: uid # The following three fields are direct mappings of attributes on the user entry. # String representation of the user. idAttr: uid # Required. Attribute to map to Email. emailAttr: mail # Maps to display name of users. No default value. nameAttr: name # Group search queries for groups given a user entry. groupSearch: # BaseDN to start the search from. It will translate to the query # "(&(objectClass=group)(member=<user uid>))". baseDN: cn=groups,dc=freeipa,dc=example,dc=com # Optional filter to apply when searching the directory. filter: "(objectClass=group)" # Following two fields are used to match a user to a group. It adds an additional # requirement to the filter that an attribute in the group must match the user's # attribute value. userAttr: uid groupAttr: member # Represents group name. nameAttr: name
The LDAP connector first initializes a connection to the LDAP directory using the
bindPW. It then tries to search for the given username and bind as that user to verify their password. Searches that return multiple entries are considered ambiguous and will return an error.
Using a Active Directory server with groups
authentication: connectors: - type: ldap name: ActiveDirectory id: ad config: host: ad.example.com:636 insecureNoSSL: false insecureSkipVerify: true bindDN: cn=Administrator,cn=users,dc=example,dc=com bindPW: admin0! usernamePrompt: Email Address userSearch: baseDN: cn=Users,dc=example,dc=com filter: "(objectClass=person)" username: userPrincipalName idAttr: DN emailAttr: userPrincipalName nameAttr: cn groupSearch: baseDN: cn=Users,dc=example,dc=com filter: "(objectClass=group)" userAttr: DN groupAttr: member nameAttr: cn
Microsoft connector uses the Microsoft OAuth2 flow to identify the end user through their Microsoft account.
When a client redeems a refresh token through Kontena Lens, Lens will re-query Microsoft to update user information in the ID Token. To do this, Kontena Lens stores a readonly Microsoft access and refresh tokens in its datastore. Users that reject Kontena Lens access through Microsoft will also revoke all clients which authenticated them through Microsoft.
groups claim in is only supported when tenant is specified in Microsoft connector config. In order for Kontena Lens to be able to list groups on behalf of logged in user, an explicit organization administrator consent is required. To obtain the consent do the following:
- when registering dex application on https://apps.dev.microsoft.com add an explicit
Directory.Read.Allpermission to the list of Delegated Permissions
- open the following link in your browser and log in under organization administrator account:
https://login.microsoftonline.com/<tenant>/adminconsent?client_id=<lens client id>
Register a new application on https://apps.dev.microsoft.com via Add an app ensuring the callback URL is
Registered application client id and client secret needs to be configured via
apiVersion: v1 kind: Secret metadata: name: idp-connector-microsoft namespace: kontena-lens type: Opaque data: client-id: "base64-encoded-application-id" client-secret: "base64-encoded-client-secret"
Kontena Lens example configuration:
authentication: connectors: - type: microsoft id: microsoft name: microsoft config: clientID: $MICROSOFT_APPLICATION_ID clientSecret: $MICROSOFT_CLIENT_SECRET # tenant: organizations # onlySecurityGroups: false # groups: # - developers # - devops
tenant configuration parameter controls what kinds of accounts may be authenticated. By default, all types of Microsoft accounts (consumers and organizations) can authenticate via Microsoft. To change this, set the tenant parameter to one of the following:
common- both personal and business/school accounts can authenticate via Microsoft (default)
consumers- only personal accounts can authenticate
organizations- only business/school accounts can authenticate
<tenant name>- only accounts belonging to specific tenant identified by either
<tenant name>can authenticate
groups claim is present and tenant is configured, Kontena Lens will query Microsoft API to obtain a list of groups the user is a member of.
onlySecurityGroups configuration option restricts the list to include only security groups. By default all groups (security, Office 365, mailing lists) are included.