Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
14 changes: 9 additions & 5 deletions demos/end-to-end-security/README.md
Original file line number Diff line number Diff line change
@@ -1,10 +1,14 @@
# How to persist changes in Superset

1. Log into Keycloak as the user `admin` (in the master realm) and create a user called `admin` in the demo realm.
2. Use that to log into Superset with the `Admin` role.
3. Optional: Add Database connection
4. Add admin user in Keycloak to all relevant groups (so that he has access to the tables, so he can create datasets, charts and dashboards).
5. `pgdump` the Postgres and update the dump in Git. For that shell into `postgresql-superset-0` and execute
Note: User role assignments no longer need to be maintained in the dump.
They are assigned by OPA on every login based on the Keycloak group memberships
(see `stacks/end-to-end-security/superset-regorules.yaml`).

1. Log into Superset via `Sign in with Keycloak` as the user `admin` (default password `adminadmin`).
The user is part of the demo realm in `keycloak-realm-config.yaml` and is automatically assigned the Superset `Admin` role by OPA.
2. Optional: Add Database connection
3. Add admin user in Keycloak to all relevant groups (so that he has access to the tables, so he can create datasets, charts and dashboards).
4. `pgdump` the Postgres and update the dump in Git. For that shell into `postgresql-superset-0` and execute

```sh
export PGPASSWORD=$(cat "${POSTGRES_POSTGRES_PASSWORD_FILE}")
Expand Down
Binary file modified docs/modules/demos/images/end-to-end-security/overview.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
25 changes: 24 additions & 1 deletion docs/modules/demos/pages/end-to-end-security.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -4,6 +4,7 @@
:k8s-cpu: https://kubernetes.io/docs/tasks/debug/debug-cluster/resource-metrics-pipeline/#cpu
:rego: https://www.openpolicyagent.org/docs/latest/policy-language/
:trino-policies: https://github.com/stackabletech/demos/blob/main/stacks/end-to-end-security/trino-policies.yaml
:superset-regorules: https://github.com/stackabletech/demos/blob/main/stacks/end-to-end-security/superset-regorules.yaml

This is a demo to showcase what can be done with Open Policy Agent around authorization in the Stackable Data Platform.
It covers the following aspects of security:
Expand All @@ -16,7 +17,7 @@ This demo will:
** *Spark*: A multi-language engine for executing data engineering, data science, and machine learning. This demo uses it to create a (rather simple) report and write the results back into the persistence.
** *HDFS*: A distributed file system that is designed to scale up from single servers to thousands of machines, each offering local computation and storage.
** *Hive metastore*: A service that stores metadata related to Apache Hive and other services. This demo uses it as metadata storage for Trino and Spark.
** *Open policy agent (OPA)*: An open-source, general-purpose policy engine unifies policy enforcement across the stack. This demo uses it as the authorizer for Trino and HDFS, which decides which user can query which data.
** *Open policy agent (OPA)*: An open-source, general-purpose policy engine unifies policy enforcement across the stack. This demo uses it as the authorizer for Trino and HDFS, which decides which user can query which data. It also assigns Superset roles based on the Keycloak group memberships.
** *Superset*: A modern data exploration and visualization platform. This demo utilizes Superset to retrieve data from Trino via SQL queries and build dashboards on top of that data.
* Configure security to showcase the following features
** Column- and row-level filtering
Expand Down Expand Up @@ -101,6 +102,10 @@ The following user accounts are configured in Keycloak:
|mark.ketting
|mark.ketting
|Head of Marketing

|admin
|adminadmin
|Superset administrator, not member of any department
|===

[#ruleset]
Expand Down Expand Up @@ -323,6 +328,24 @@ When clicking on the button, you are redirected to the Superset UI being already

image::end-to-end-security/superset_2.png[]

=== Superset role assignment via OPA

Which dashboards a user can see in Superset is determined by Superset roles.
Instead of assigning these roles manually, Superset asks OPA for the roles of a user at every login (configured via `roleMappingFromOpa` on the SupersetCluster).
OPA derives the roles from the Keycloak group memberships using the user-info-fetcher - the same group lookup the Trino rules are based on.
The mapping is defined in the {superset-regorules}[superset-regorules ConfigMap]:

* Every user gets the `Gamma` and `sql_lab` roles, granting access to the Superset UI including SQL Lab.
* Members of a department additionally get the role granting access to the datasets of their department, e.g. members of `/Customer Service/Analytics` get the `Customer Service Analytics` role and with it the `Customer analytics` dashboard.
* The `admin` user is assigned the Superset `Admin` role, so Superset can be administered via Single Sign On as well.

You can try this out by logging in to Superset as `pamela.scott` (Customer Analytics) and `william.lewis` (Compliance Analytics) and comparing the dashboards each of them sees.
Adding a user to a department group in Keycloak is all that is needed: on the next login, the user is assigned the matching Superset roles automatically.

Note that the Superset roles only control which dashboards and datasets are visible.
The data shown in the charts is still protected by Trino and OPA, because Superset impersonates the logged-in user when querying Trino.
Also note that role assignments made in the Superset UI are overwritten on the next login of the affected user - the Rego rules are the single source of truth.

=== Open Policy Agent for the utmost flexibility in building access rules

Some examples of access rules you can define for the Open Policy Agent authorization mechanism were already shown in the <<column-row-filtering, Column- and row-level filtering section>>. For more examples, check out the {trino-policies}[trino-policies ConfigMap] of this demo and also the https://www.youtube.com/watch?v=ATlq_l3WNiA&t=1970s[ACL section of the 'Mastering Data Platform Security' recording from above].
18 changes: 18 additions & 0 deletions stacks/end-to-end-security/keycloak-realm-config.yaml
Original file line number Diff line number Diff line change
Expand Up @@ -46,6 +46,24 @@ stringData:
"subGroups" : [ ]
} ],
"users" : [ {
"username" : "admin",

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this be something more specific to superset?

Suggested change
"username" : "admin",
"username" : "superset_admin",

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the admin user name is predefined by superset and as far as I suspect we need to match the user name in Keycloak - however I can give it a try to see whether we can rename it.

"enabled" : true,
"totp" : false,
"emailVerified" : true,
"firstName" : "Superset",
"lastName" : "Admin",
"email" : "admin@superset.com",
"credentials" : [ {
"type" : "password",
"value" : "{{ supersetAdminPassword }}",
"temporary" : false
} ],
"disableableCredentialTypes" : [ ],
"requiredActions" : [ ],
"realmRoles" : [ "default-roles-demo" ],
"notBefore" : 0,
"groups" : [ ]
}, {
"id" : "e44a09fa-bce1-40e8-a1da-28902b79dcf0",
"createdTimestamp" : 1711375603780,
"username" : "daniel.king",
Expand Down
Loading
Loading