À mesure que les organisations orientées données se développent, le besoin d'un contrôle d'accès sécurisé et granulaire dans les plateformes de visualisation devient critique. Apache Superset est une puissante plateforme moderne d'exploration et de visualisation des données, mais par défaut, il traite tous les utilisateurs avec des rôles RBAC standard. Pour les environnements multi-locataires—tels que les fournisseurs SaaS servant différents clients ou les entreprises avec des équipes régionales distinctes—vous avez besoin de plus que de simples permissions « peut consulter » ou « peut modifier ». Vous avez besoin de la sécurité au niveau des lignes (RLS) combinée à une gestion sécurisée de l'identité via le Single Sign-On (SSO).
Ce guide accompagne les développeurs intermédiaires à avancés dans l'implémentation pratique de ces fonctionnalités pour garantir l'isolation des données et l'authentification centralisée.
Comprendre l'architecture
Le modèle de sécurité de Superset est construit autour des rôles et des permissions. La RLS vous permet de restreindre les lignes de données qu'un utilisateur peut voir dans un jeu de données spécifique. Le SSO intègre Superset avec votre fournisseur d'identité d'entreprise (comme Keycloak, Okta ou Azure AD) pour gérer l'authentification en externe, réduisant la prolifération des mots de passe et améliorant la posture de sécurité.
Configuration du Single Sign-On (SSO)
Superset prend en charge divers protocoles SSO, l'OpenID Connect (OIDC) étant le plus courant. Pour implémenter le SSO, vous devez configurer le fichier superset_config.py. Voici un exemple pratique utilisant un fournisseur OIDC.
# superset_config.py
AUTH_TYPE = "oid"
OAUTH_REMOTE_APP = {
"client_id": "your-client-id",
"client_secret": "your-client-secret",
"auth_uri": "https://your-idp.example.com/auth",
"token_uri": "https://your-idp.example.com/token",
"api_base_url": "https://your-idp.example.com/",
"userinfo_uri": "https://your-idp.example.com/userinfo",
"request_token_params": {},
"access_token_params": {},
"authorize_params": {"scope": "openid profile email"},
"client_kwargs": {"verify_ssl": True},
}
# Map external groups to Superset roles
OAUTH_TO_ROLE = {
"admin-group": "Admin",
"analyst-group": "Alpha", # 'Alpha' is a role you create in Superset
"viewer-group": "Public",
}Après avoir effectué cette configuration, redémarrez votre instance Superset. Les utilisateurs seront désormais redirigés vers votre IdP pour la connexion, et leurs rôles Superset seront automatiquement attribués en fonction de leur appartenance aux groupes dans l'IdP.
Implémentation de la sécurité au niveau des lignes (RLS)
La RLS est le cœur de l'isolation des données multi-locataires. Elle vous permet de définir des filtres SQL appliqués aux requêtes en fonction des attributs de l'utilisateur. Dans Superset, les règles RLS sont définies dans l'interface utilisateur, mais elles peuvent également être gérées de manière programmatique pour assurer la cohérence dans les pipelines CI/CD.
Supposons que nous ayons une table sales avec une colonne region. Nous voulons que le rôle alpha ne voie que les données de la région 'US'.
1. Naviguez vers Bases de données > Sélectionner une base de données > Sécurité au niveau des lignes.
2. Créez une nouvelle règle avec les paramètres suivants :
- Rôle : Sélectionnez
Alpha. - Jeu de données : Sélectionnez votre jeu de données
sales. - Expression SQL du filtre :
region = 'US'
Pour une RLS dynamique et spécifique à l'utilisateur (par exemple, les utilisateurs ne peuvent voir que les données de leur propre département), vous pouvez utiliser le gabarit Jinja2 dans l'expression du filtre pour accéder aux attributs de l'utilisateur transmis par votre fournisseur SSO ou des en-têtes personnalisés.
# Example Dynamic RLS Filter
# Assumes 'department' is extracted from the user's JWT or profile
{{ current_user.attributes.get('department', 'unknown') }}Meilleures pratiques pour les environnements multi-locataires
- Séparation des rôles : Créez des rôles Superset distincts pour chaque locataire ou département (par exemple,
Tenant_A_Verified,Tenant_B_Verified). Ne vous fiez pas à un seul rôle générique « Utilisateur ». - Testez la RLS de manière exhaustive : Validez toujours les règles RLS dans un environnement de préproduction. Un filtre mal configuré peut entraîner une fuite de données ou des tableaux de bord vides.
- Utilisez la correspondance de groupes SSO : Automatisez l'attribution des rôles via la correspondance de groupes SSO pour éviter les erreurs d'administration manuelles lors de l'intégration de nouveaux utilisateurs.
- Journaux d'audit : Activez la journalisation d'audit de Superset pour suivre qui a accédé à quels jeux de données, ce qui aide à la conformité et à la forensique de sécurité.
Conclusion
L'implémentation de la sécurité au niveau des lignes et du SSO dans Apache Superset le transforme d'un simple outil BI en une plateforme d'analyse robuste de niveau entreprise. En découplant l'authentification vers un IdP externe et en appliquant un filtrage granulaire des données au niveau de la base de données, vous vous assurez que chaque utilisateur ne voit que les données auxquelles il est autorisé à accéder. Cette approche non seulement renforce la sécurité, mais simplifie également la gestion des utilisateurs dans des environnements complexes et multi-locataires.
Commencez par configurer votre intégration SSO, puis ajoutez des règles RLS pour vos jeux de données les plus sensibles. Avec ces deux piliers en place, votre instance Superset est prête à évoluer en toute sécurité avec votre organisation.