Skip to content

Static authentication class is not working #583

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
yuvalgersho opened this issue Dec 31, 2024 · 3 comments
Open

Static authentication class is not working #583

yuvalgersho opened this issue Dec 31, 2024 · 3 comments

Comments

@yuvalgersho
Copy link

yuvalgersho commented Dec 31, 2024

Affected Stackable version

24.11.1

Affected Apache Superset version

No response

Current and expected behavior

I tried to configure static authentication class for my superset cluster.

the authentication class itself worked:

apiVersion: v1
kind: Secret
metadata:
  name: superset-users-credentials  
type: kubernetes.io/opaque
stringData:
  test1: test123

---
apiVersion: authentication.stackable.tech/v1alpha1
kind: AuthenticationClass
metadata:
  name: superset-users
spec:
  provider:
    static:
      userCredentialsSecret:
        name: superset-users-credentials

but when i used this authenticationClass in the SupersetCluster instance i got this error:

2024-12-31T16:02:44.845314Z ERROR stackable_operator::logging::controller: Failed to reconcile object controller.name="supersetcluster.superset.stackable.tech" error=reconciler for object SupersetCluster.v1alpha1.superset.stackable.tech/simple-superset.analytics failed error.sources=[failed to apply authentication configuration, failed to use authentication provider "Static" for authentication class "superset-users" - supported providers: ["LDAP", "OIDC"]]

this is the SupersetCluster.yaml file:

---
apiVersion: superset.stackable.tech/v1alpha1
kind: SupersetCluster
metadata:
  name: simple-superset
  namespace: analytics
spec:
  image:
    productVersion: 4.0.2
  clusterConfig:
    credentialsSecret: simple-superset-credentials
    authentication:
    - authenticationClass: superset-users

any suggestions?

Possible solution

No response

Additional context

No response

Environment

No response

Would you like to work on fixing this bug?

None

@sbernauer
Copy link
Member

Hi @yuvalgersho,

as the error message failed to apply authentication configuration, failed to use authentication provider "Static" for authentication class "superset-users" - supported providers: ["LDAP", "OIDC"] hints, the static AuthenticationClass is not supported for Superset at the moment.
The reason is that some tools (such as Trino) just take a list of user and passwords and bam -> that's it - that's what the static AuthenticationClass is doing.
However, Superset does all the user managment on it's own via the Webinterface (it technically also has an HTTP API).

What you probably need to do is to use OIDC or LDAP (if possible), or use an off-the-shelf Superset (e.g. from the getting started guide), and use the admin account to create user accounts via the Superset webinterface.

I hope this helps!
Regards,
Sebastian

@sbernauer sbernauer removed the type/bug label Jan 2, 2025
@razvan
Copy link
Member

razvan commented Jan 6, 2025

The UI workflow may be a no-go in some cases (like CI/CD for example).

The operator should be able to create additional users (and possibly new roles) together with the admin user as part of the cluster setup.

@Maleware
Copy link
Member

Yes this is true, it should be able to do so.

However, currently the codebase of Superset dosen't allow another authority over roles and their permission except itself. It is possible to map roles from e.g. OIDC or LDAP, soonish also from OPA.

To map from OIDC / LDAP it is necessary to create used Roles either:

  • Using superset ui and create roles with their permission
  • Using AUTH_ROLES_MAPPING and map any roles to superset internal default roles ( Alpha, Gamma, Admin )

Superset just can't use users outside of its own postgres. Thus the only way to have a CI/CD workflow with user management and superset is to use a provider like Keycloak and such and leave it to them. This won't mitigate the problem that those roles do not exist and do not have permissions if not set manually in Superset.

This might change over time as they want to rework the authentication codebase upstream. For now we are left with this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants