Authentication

By default Kontena Lens will accept only tokens at login. It's possible to configure authentication connectors which will enable OpenID Connect login for supported identity providers. Authentication connectors work only on Kubernetes clusters which allow to configure OIDC settings. For example Amazon EKS and Google GKE don't support this.

Supported authentication connectors:

GitHub

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.

Configuration

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 idp-connector-github secret:

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

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.

Configuration

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 read_user and 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 idp-connector-gitlab secret:

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

LDAP

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.

Configuration

User entries are expected to have an email attribute (configurable through emailAttr), and a display name attribute (configurable through nameAttr). *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 bindDN and 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

LinkedIn

WIP

Microsoft

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.

Caveats

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.All permission 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>

Configuration

Register a new application on https://apps.dev.microsoft.com via Add an app ensuring the callback URL is https://kontena-lens-address/idp/callback.

Registered application client id and client secret needs to be configured via idp-connector-microsoft secret:

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 uuid> or <tenant name> - only accounts belonging to specific tenant identified by either <tenant uuid> or <tenant name> can authenticate

When the 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.

results matching ""

    No results matching ""