Security

Authentication

Every user has to be authenticated before using Superset: there are several ways in which this can be set up.

Multiple authentication methods

Only one authentication method is supported at a time, and in case of LDAP, only one authentication class is allowed. This means, it is not possible to configure both LDAP and OIDC authentication methods at the same time, but it is possible to configure multiple OIDC classes or one LDAP authentication class.

Superset database

The default setting is to manually set up users via the web interface where they are stored in the database attached to Superset.

LDAP

Superset supports authentication of users against a single LDAP server. This requires setting up an AuthenticationClass for the LDAP server. The AuthenticationClass is then referenced in the SupersetCluster resource as follows:

apiVersion: superset.stackable.tech/v1alpha1
kind: SupersetCluster
metadata:
  name: superset-with-ldap-server
spec:
  image:
    productVersion: 4.1.1
  clusterConfig:
    authentication:
    - authenticationClass: ldap    (1)
      userRegistrationRole: Admin  (2)yaml

1	The reference to an AuthenticationClass called `ldap`
2	The default role to which all users are assigned

Users that log in with LDAP are assigned to a default Role which is specified with the userRegistrationRole property.

You can follow the Authentication with OpenLDAP tutorial to learn how to set up an AuthenticationClass for an LDAP server, as well as consulting the AuthenticationClass concepts page.

OpenID Connect

An OpenID Connect provider can be used for authentication. Unfortunately, there is no generic support for OpenID Connect built into Superset. This means that only specific OpenID Connect providers can be configured.

Superset deployments on the Stackable Data Platform only support Keycloak.

apiVersion: superset.stackable.tech/v1alpha1
kind: SupersetCluster
metadata:
  name: superset-with-oidc
spec:
  image:
    productVersion: 4.1.1
  clusterConfig:
    authentication:
    - authenticationClass: keycloak                        (1)
      oidc:
        clientCredentialsSecret: superset-keycloak-client  (2)
      userRegistrationRole: Gamma                          (3)yaml

1	The reference to an AuthenticationClass called `keycloak`
2	The reference to the Secret containing the Superset client credentials
3	The default role to which all users are assigned

Users that log in with OpenID Connect are assigned to a default Role which is specified with the userRegistrationRole property.

The Secret containing the Superset client credentials:

apiVersion: v1
kind: Secret
metadata:
  name: superset-keycloak-client
stringData:
  clientId: superset                    (1)
  clientSecret: superset_client_secret  (2)yaml

1	The client ID of Superset as defined in Keycloak
2	The client secret as defined in Keycloak

A minimum client configuration in Keycloak for this example looks like this:

{
  "clientId": "superset",
  "enabled": true,
  "clientAuthenticatorType": "client-secret", (1)
  "secret": "superset_client_secret",
  "redirectUris": [
    "*"
  ],
  "webOrigins": [
    "*"
  ],
  "standardFlowEnabled": true, (2)
  "protocol": "openid-connect" (3)
}json

1	Sets the OIDC type to confidential access type.
2	Enables the OAuth2 "Authorization Code Flow".
3	Enables OpenID Connect and OAuth2 support.

Further information for specifying an AuthenticationClass for an OIDC provider can be found at the concepts page.

Authorization

Superset has a concept called Roles which allows you to grant user permissions based on roles. Have a look at the Superset documentation on Security.

OPA role mapping

Stackable ships a custom security manager that makes it possible to assign roles to users via the Open Policy Agent integration. The roles must exist in the Superset database before they can be assigned to users. If a role is not present in the Superset database, an error will be logged by the security manager and the user login will proceed without it. Also the role names must match exactly the output of the Rego rule named user_roles. In the following example, a rego package is defined that assigns roles to the users admin and guest.

apiVersion: v1
kind: ConfigMap
metadata:
  name: superset-opa-regorules
  labels:
    opa.stackable.tech/bundle: "true"
data:
  roles.rego: |
    package superset

    default user_roles := []

    user_roles := roles if {
        some user in users
        roles := user.roles
        user.username == input.username
    }
    users := [
        {"username": "admin", "roles": ["Admin", "Test"]}, (1)
        {"username": "guest", "roles": ["Gamma"]} (2)
    ]yaml

1	Assign the roles `Admin` and `Test` to the `admin` user. The `Test` role is not a standard Superset role and must be created before the assignment.
2	Assign the `Gamma` role to the `guest` user.

OPA rules can make use of the user-info-fetcher integration.

The following snippet shows how to use the OPA security manager in a Superset stacklet.

apiVersion: superset.stackable.tech/v1alpha1
kind: SupersetCluster
metadata:
  name: superset-with-opa-role-mapping
spec:
  clusterConfig:
    authorization:
      roleMappingFromOpa:
        configMapName: superset-opa-regorules (1)
        package: superset
        cache: (2)
          entryTimeToLive: 10s (3)
          maxEntries: 5 (4)yaml

1	ConfigMap name containing rego rules
2	Mandatory Opa caching. If not set, default settings apply.
3	Time for cached entries per user can live. Defaults to 30s.
4	Number of maximum entries, defaults to 1000. Cache will be disabled for maxEntries: 0.

Any role assignments done in the Superset UI are discarded and will be overridden by the OPA security manager.

Superset database

You can view all the available roles in the web interface of Superset and can also assign users to these roles.

LDAP

Superset supports assigning Roles to users based on their LDAP group membership, though this is not yet supported by the Stackable operator. All the users logging in via LDAP get assigned to the same role which you can configure via the attribute authentication[*].userRegistrationRole on the SupersetCluster object:

apiVersion: superset.stackable.tech/v1alpha1
kind: SupersetCluster
metadata:
  name: superset-with-ldap-server
spec:
  clusterConfig:
    authentication:
    - authenticationClass: ldap
      userRegistrationRole: Admin  (1)yaml

1	All users are assigned to the `Admin` role

OpenID Connect

The mechanism for assigning roles to users described in the LDAP section also applies to OpenID Connect. Superset supports assigning Roles to users based on their OpenID Connect scopes, though this is not yet supported by the Stackable operator. All the users logging in via OpenID Connect get assigned to the same role which you can configure via the attribute authentication[*].userRegistrationRole on the SupersetCluster object:

apiVersion: superset.stackable.tech/v1alpha1
kind: SupersetCluster
metadata:
  name: superset-with-oidc
spec:
  image:
    productVersion: 4.1.1
  clusterConfig:
    authentication:
    - authenticationClass: keycloak
      oidc:
        clientCredentialsSecret: superset-keycloak-client
      userRegistrationRole: Gamma  (1)yaml

1	All users are assigned to the `Gamma` role