Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

OPA roles are only resolved at login, so role changes and offboarding don't reach live sessions

Aperta
  • Qualcosa non va?
#748 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
48/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Tranquilla
Stack tecnologico
flask, python
Ambito
authentication, authorization, backend

Direzione di ricerca

Inizia individuando OpaSupersetSecurityManager e il relativo wiring esistente del client OPA e di TTLCache. Traccia dove avviene attualmente la risoluzione dei ruoli durante il login, quindi determina come i controlli al momento della richiesta debbano gestire i ruoli modificati o vuoti entro il TTL. Il lavoro è completato quando le sessioni attive riflettono le modifiche ai ruoli o la disattivazione in OPA entro il ritardo configurato, con una copertura per entrambi i casi.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Use case

When configuring OPA role mapping for Apache Superset, role changes in OPA should take effect on Superset sessions that are already logged in within a predictable amount of time.
Removing someone's roles (or totally offboarding them) should actually revokes access without having to wait until they login again (which they cannot even do, if they were offboarded).

The problem

OpaSupersetSecurityManager only resolves roles on login. After that Superset uses the Flask-Login cookie and never talks to OPA again. So changing or removing a user's roles in OPA does nothing to a live session, this session will keep the roles it had at the last login.
This is especially critical, since sessions don't really have a maximum life time, but can in theory be kept alive indefinitely by not letting them become idle.

So effectively a user that is disabled in Keycloak could keep using a logged in Superset session with their last credentials forever.
Blast radius obviously depends on many things like if impersonation is used for Trino etc., but this is far from ideal.

Work-around

Partial only: shorten PERMANENT_SESSION_LIFETIME, or rotate SECRET_KEY to kill all sessions at once.
One is not really helpful, the other is overkill.

Possible solutions

Not a complete list, just what occured to me (and Claude) so far:

  • Re-check OPA on requests and log the user out (or resync roles) when their roles come back empty, gated by a TTL so we only re-check once the last result is older than X seconds
  • Push offboarding from Keycloak (event listener/webhook). Rejected as primary fix, needs control over Keycloak, which we usually don't have.
  • Generic before_request guard keyed on ab_user.active. Needs an external process to flip active and ignores OPA, our actual source of truth.
Recommendation

Personally I think option 1 makes most sense. We already wire in a custom security manager that we control and which is at the ideal place to control this. It already holds an OPA client and a TTLCache, which is a lot of the plumbing we need.

At the moment it syncs roles only on login, but we could change that to run on every request, and then restrict it to only actually do something every x seconds/minutes... This would mean that we can effectively control the maximum delay until changes in Keycloak are pushed down to Superset - instead of relying on user behavior (login) for this.

Lingua principale
Rust
Stelle
35
Fork
4
Merge medio
11h 1m
PR unite (30g)
10

Preparare l'ambiente

  • Nessun Dockerfile né file Docker Compose
  • Ha un modello di pull request
  • Nessuna guida per i contributori

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di stackabletech/superset-operator

Tutte le issue di stackabletech/superset-operator

Issue simili

Altre issue su Rust

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.