Authentication

The Stackable Platform uses the AuthenticationClass as a central mechanism to handle user authentication across supported products. The authentication mechanism needs to be configured only in the AuthenticationClass which is then referenced in the product. Multiple different authentication providers are supported.

AuthenticationClass

The AuthenticationClass is a resource describing a generic authentication method like LDAP or Kerberos. It has cluster scope, so it does not belong to a specific namespace. Multiple operators use this CRD as a way to express and configure the authentication methods of their respective product.

The following authentication providers are supported:

  • LDAP: Authenticate users using an LDAP server.

  • TLS: Authenticate users with client TLS certificates.

  • Static: Authenticate users against a static list of users and passwords in a simple Kubernetes Secret.

LDAP

A very simple AuthenticationClass with LDAP Authentication looks like this:

apiVersion: authentication.stackable.tech/v1alpha1
kind: AuthenticationClass
metadata:
  name: ldap-simple
spec:
  provider:
    ldap:
      hostname: my.ldap.server (1)
      port: 389 (2)
      searchBase: ou=users,dc=example,dc=org (3)
      bindCredentials:
        secretClass: openldap-bind-credentials  (4)
1 The hostname of the LDAP server without any protocol or port
2 The port of the LDAP server. If TLS is used it defaults to 636 otherwise to 389
3 An optional searchBase where the users should be searched
4 The reference to the SecretClass for the bind credentials

In a diagram it would look like this:

image$authentication overview.drawio
Learn more in the OpenLDAP tutorial and get a full overview of all the properties in the AuthenticationClass LDAP provider CRD reference.

TLS

The TLS provider configures a product to authenticate users using TLS certificates. When establishing a connection the client will first validate the certificate of the server. This step is not influenced by this AuthenticationClass, it only affects the next step: Afterwards the server checks the validity of the certificate the client has provided. This includes the usual checks - such as checking that it hasn’t expired and matches the hostname of the client. Additionally the client certificate needs to be signed with the ca certificate, which is provided by the SecretClass specified in clientCertSecretClass.

A sample TLS provider looks as follows:

apiVersion: authentication.stackable.tech/v1alpha1
kind: AuthenticationClass
metadata:
  name: client-auth-tls
spec:
  provider:
    tls:
      clientCertSecretClass: client-auth-tls

Static

The static provider is used to represent a simple - static - set of users. Users are identified by a username and a password.

First, the AuthenticationClass needs to be defined as follows:

apiVersion: authentication.stackable.tech/v1alpha1
kind: AuthenticationClass
metadata:
  name: simple-users
spec:
  provider:
    static:
      userCredentialsSecret:
        name: simple-users-credentials (1)
1 The name of the Secret containing the credentials

Afterwards the referenced Secret needs to be created:

apiVersion: v1
kind: Secret
metadata:
  name: simple-users-credentials (1)
  namespace: default (2)
type: kubernetes.io/opaque
stringData:
  admin: admin
  alice: superpass
  bob: secret
1 The name of the Secret, which needs to match the Secret name specified in the AuthenticationClass above
2 The namespace of the Secret. The Secret needs to be in the same namespace as the product that tries to use the static AuthenticationClass

Further Reading