Configuring LDAP and Logging for Superset

[jusch23]

Hello,
I am currently trying to configure LDAP authentication for apache superset (using active directory as ldap directory). It does not work yet so I tried to increase log level for the superset container to get more insights. Unfortunately, I don't get this running, too.

My authentication class for ldap looks similar to this:

---
apiVersion: v1
kind: Secret
metadata:
  name: ldap-bind-credentials
  labels:
    secrets.stackable.tech/class: ldap-bind-credentials
stringData:
  user: "CN=myuser,OU=my ou,DC=ldap-test,DC=de"
  password: "password"
---
apiVersion: secrets.stackable.tech/v1alpha1
kind: SecretClass
metadata:
  name: ldap-bind-credentials
spec:
  backend:
    k8sSearch:
      searchNamespace:
        pod: {}
---
apiVersion: authentication.stackable.tech/v1alpha1
kind: AuthenticationClass
metadata:
  name: ldap-simple
spec:
  provider:
    ldap:
      hostname: ldap-test.de
      #port: 636 # first try without tls
      port: 389
      searchBase: DC=ldap-test,DC=de
      searchFilter: "(sAMAccountName=%s)"
      ldapFieldNames:
        uid: sAMAccountName
      bindCredentials:
        secretClass: ldap-bind-credentials

Inside SupersetCluster manifest I reference this authentication class. I also tried to enable DEBUG log, but as mentioned I could not set it up. Here is part of the manifest:

---
apiVersion: superset.stackable.tech/v1alpha1
kind: SupersetCluster
metadata:
  name: superset
spec:
  image:
    repo: my-registry:34567/stackable
    productVersion: 1.5.1
    stackableVersion: "23.4.0"
  credentialsSecret: superset-credentials
  authenticationConfig:
    authenticationClass: ldap-simple
    userRegistrationRole: Admin
  mapboxSecret: superset-mapbox-api-key
  databaseInitialization:
    logging:
      containers:
        superset-init-db:
          console:
            level: TRACE
          file:
            level: TRACE
          loggers:
            ROOT:
              level: TRACE
  nodes:
    roleGroups:
      default:
        replicas: 1
        config:
          logging:
            containers:
              superset:
                console:
                  level: TRACE
                file:
                  level: TRACE
                loggers:
                  ROOT:
                    level: TRACE
    # not necessary but added to be sure
    config:
      logging:
        containers:
          superset:
            console:
              level: TRACE
            file:
              level: TRACE
            loggers:
              ROOT:
                level: TRACE

The container logs (received from kubectl logs) do not contain any debug logs. How can I debug my ldap connection?
I used the following tutorials and documentations:
https://docs.stackable.tech/home/stable/tutorials/authentication_with_openldap.html
https://docs.stackable.tech/home/stable/concepts/logging.html
https://docs.stackable.tech/home/stable/superset/usage-guide/security.html

Thank you in advance for any help.

[razvan]

Hello,
thank you for your report. We need more details. Some questions for more context:

1. What exactly doesn't work ? Is there a Superset StatefulSet being created and can you open the login page ?
2. Is there anything in the superset operator logs ?
3. Did you also install the secret (1) and commons (2) operators? These are required for this setup.

Again, thank you for the report and sorry for the inconvenience.

[jusch23]

Hi,
thanks for the fast response and sorry for the missing information.

1. There is a superset StatefulSet created and I can open the login page. Using no authenticationClass, but only the admin user from superset-credentials works fine. We already got the nifi-kafka-druid-earthquake-data demo (https://docs.stackable.tech/stackablectl/stable/demos/nifi-kafka-druid-earthquake-data.html) running and now we want to enable ldap authentication for the different UIs used.
2. In the container log I can only see the following events after the start of the superset container:

2023-04-28 12:36:15,574:INFO:root:Configured event logger of type <class 'superset.utils.log.DBEventLogger'>
2023-04-28 12:36:15,577:WARNING:superset.utils.cache_manager:Falling back to the built-in cache, that stores data in the metadata database, for the followinng cache: `FILTER_STATE_CACHE_CONFIG`. It is recommended to use `RedisCache`, `MemcachedCache` or another dedicated caching backend for production deployments
2023-04-28 12:36:15,580:WARNING:superset.utils.cache_manager:Falling back to the built-in cache, that stores data in the metadata database, for the followinng cache: `EXPLORE_FORM_DATA_CACHE_CONFIG`. It is recommended to use `RedisCache`, `MemcachedCache` or another dedicated caching backend for production deployments
2023-04-28 12:36:15,828:INFO:superset.utils.screenshots:No PIL installation found
Loaded your LOCAL configuration at [/stackable/app/pythonpath/superset_config.py]
[2023-04-28 12:36:20 +0000] [1] [INFO] Starting gunicorn 20.1.0
[2023-04-28 12:36:20 +0000] [1] [INFO] Listening at: http://0.0.0.0:8088 (1)
[2023-04-28 12:36:20 +0000] [1] [INFO] Using worker: gthread
[2023-04-28 12:36:20 +0000] [53] [INFO] Booting worker with pid: 53
2023-04-28 12:36:21,472:INFO:root:Configured event logger of type <class 'superset.utils.log.DBEventLogger'>
2023-04-28 12:36:21,474:WARNING:superset.utils.cache_manager:Falling back to the built-in cache, that stores data in the metadata database, for the followinng cache: `FILTER_STATE_CACHE_CONFIG`. It is recommended to use `RedisCache`, `MemcachedCache` or another dedicated caching backend for production deployments
2023-04-28 12:36:21,477:WARNING:superset.utils.cache_manager:Falling back to the built-in cache, that stores data in the metadata database, for the followinng cache: `EXPLORE_FORM_DATA_CACHE_CONFIG`. It is recommended to use `RedisCache`, `MemcachedCache` or another dedicated caching backend for production deployments
2023-04-28 12:36:21,629:INFO:superset.utils.screenshots:No PIL installation found
2023-04-28 12:36:28,274:WARNING:superset.db_engine_specs:Unable to load SQLAlchemy dialect <module 'sqlalchemy.dialects.sybase' from '/stackable/app/lib64/python3.8/site-packages/sqlalchemy/dialects/sybase/__init__.py'>: No module named 'sqlalchemy_trino'
2023-04-28 12:36:34,822:WARNING:superset.db_engine_specs:Unable to load SQLAlchemy dialect <module 'sqlalchemy.dialects.sybase' from '/stackable/app/lib64/python3.8/site-packages/sqlalchemy/dialects/sybase/__init__.py'>: No module named 'sqlalchemy_trino'
2023-04-28 12:36:40,751:WARNING:superset.db_engine_specs:Unable to load SQLAlchemy dialect <module 'sqlalchemy.dialects.sybase' from '/stackable/app/lib64/python3.8/site-packages/sqlalchemy/dialects/sybase/__init__.py'>: No module named 'sqlalchemy_trino'

3. Yes the secret and commons operators are installed.

[razvan]

Hi,
your logging configuration looks good. Unfortunately Superset logs very little at debug level. We will investigate ActiveDirectoy.

Below you'll find a minimal configuration that works in our CI. It uses OpenLDAP instead of ActiveDirectory. Maybe you can find something of use here in the mean time:

---
apiVersion: authentication.stackable.tech/v1alpha1
kind: AuthenticationClass
metadata:
  name: superset-with-ldap-server-veri-tls-ldap
spec:
  provider:
    ldap:
      bindCredentials:
        secretClass: superset-with-ldap-bind
      hostname: openldap.kuttl-test-enabling-seasnail.svc.cluster.local
      ldapFieldNames:
        email: mail
        givenName: givenName
        group: memberof
        surname: sn
        uid: uid
      port: 1636
      searchBase: ou=users,dc=example,dc=org
      searchFilter: ""
      tls:
        verification:
          server:
            caCert:
              secretClass: openldap-tls-kuttl-test-enabling-seasnail
---
apiVersion: secrets.stackable.tech/v1alpha1
kind: SecretClass
metadata:
  name: openldap-tls-kuttl-test-enabling-seasnail
spec:
  backend:
    autoTls:
      ca:
        autoGenerate: true
        secret:
          name: openldap-tls-ca
          namespace: kuttl-test-enabling-seasnail
---
apiVersion: v1
kind: Secret
metadata:
  name: superset-with-ldap-credentials
type: Opaque
stringData:
  adminUser.username: admin
  adminUser.firstname: Superset
  adminUser.lastname: Admin
  adminUser.email: admin@superset.com
  adminUser.password: admin
  connections.secretKey: thisISaSECRET_1234
  connections.sqlalchemyDatabaseUri: postgresql://superset:superset@superset-postgresql/superset
---
apiVersion: superset.stackable.tech/v1alpha1
kind: SupersetCluster
metadata:
  name: superset-with-ldap
spec:
  authenticationConfig:
    authenticationClass: superset-with-ldap-server-veri-tls-ldap
    syncRolesAt: Registration
    userRegistration: true
    userRegistrationRole: Admin
  credentialsSecret: superset-with-ldap-credentials
  image:
    productVersion: 1.5.1
    pullPolicy: IfNotPresent
    stackableVersion: 23.4.0
  nodes:
    roleGroups:
      default:
        config:
          logging:
            enableVectorAgent: null

[razvan]

Hello,
we can login successfully using a vanilla AD setup by setting uid: userPrincipalName in the AuthenticationClass' LDAP fields.

Are you sure your AuthenticationClass is configured correctly ?

Otherwise, is it possible for you to run Wireshark to capture the LDAP traffic ? That would help spot the problem pretty fast.

PS: Also perhaps the userRegistrationRole: Admin field of the authenticationConfig property needs to be changed. , "Public" seems to work by default with AD.

[jusch23]

Hi,
thanks for the fast test. I tried a more simple AuthenticationClass and it worked both with uid: userPrincipalName and uid: sAMAccountName after I removed the searchFilter entry:

---
apiVersion: authentication.stackable.tech/v1alpha1
kind: AuthenticationClass
metadata:
  name: ldap-simple
spec:
  provider:
    ldap:
      hostname: ldap-test.de
      port: 636
      searchBase: DC=ldap-test,DC=de
      #searchFilter: "(sAMAccountName=%s)" # <- does not work if this searchFilter is used
      ldapFieldNames:
        uid: sAMAccountName
      bindCredentials:
        secretClass: ldap-bind-credentials
      tls:
        verification:
          server:
            caCert:
              secretClass: ca-cert

Thank you for your help :)

[razvan]

Good to know and thank you for the feedback.

#searchFilter: "(sAMAccountName=%s)" # <- does not work if this searchFilter is used