Super admin across namespaces solution for multi-tenant analytics application

Amazon QuickSight Enterprise edition supports multi-tenancy through namespaces. A QuickSight namespace is a logical container that you can use to organize clients, subsidiaries, teams, and so on. The users in one namespace can share the data assets to the users/groups in the same namespace. But, users in one namespace can’t see or interact with users in another namespace. This design can securely isolate data and also support diverse workloads without adding additional AWS accounts.

However, when we design the enterprise multi-tenant analytics application, a common request is: enable a super admin role to be able to access and manage all the assets across all the namespaces. At the same time, the “local” user in each namespace only can access and share data assets to the users of the same namespace. Here it is a sample use case in details:

  1. The internal super admin role in default namespace:
    These users locating in default namespace should be able to browse, view, edit and delete ALL QuickSight assets, such as dashboard, analysis, and dataset. The super admin users can deploy these assets across all ISV namespaces.
    These users would like to view the aggregated usage, performance, and operational metrics and analysis across all the namespaces and regions.
  2. The external “local” user in default or custom namespace:
    The local user should be able to access the QuickSight assets shared to his/her namespace. The same person might be able to access multiple namespaces. For example, Ying Wang can access namespace called “AWS ProServe” and “AWS QuickSight”. Ying Wang has two different users to log into these two different namespaces.
  3. The internal support engineer role in all namespaces:
    Multiple namespace access is required specifically for internal support engineers. They need the ability to access different client namespaces to troubleshoot or analyze data quality of the data sources for their clients when they submit incidents or trouble tickets and also used to monitor certain client performance metrics.

The architecture of the solution:

  1. The configuration of users
  2. How to enable super admin to deploy assets across different namespaces? For every namespace, you can create a corresponding folder. For example, you can create a folder called “ns-1” for namespace 1 (“ns-1”). And then, you can create a group in “ns-1” to include all the users in “ns-1” and let group “ns-1” to be viewer of folder “ns-1”. The super admin users/groups are owner of all these folders. These super admins can put the a dashboard into folder “ns-1” and all the users in “ns-1” will be able to view this dashboard. (Please note, a user in one namespace can’t view the other users/groups in other namespaces. However, this user can view and edit the assets created by the users in other namespaces, if you enable the access.) You can further create sub-folders and groups to apply granular access control. A sample folder hierarchical architecture is shown as below:
  3. The aggregated usage metrics can be built with this solution: CloudFormation Templates of the administrative console in Amazon QuickSight
  4. QuickSight generate federated username as: federated-IAM-role/session_name (usually session name is email). The arn of user is: arn:aws:quicksight:<<region>>:<<account-id>>:user/<<namespace>>/federated-IAM-role/session_name. For the support engineer role, you can create individual user per namespace. For example, support engineer, Ying, has multiple usernames in different namespaces in this format: federated-IAM-role/namespace+email
    default name space: qs-fed-role/ying@dummy.com
    namespace 1: qs-fed-role/ns1-ying@dummy.com
    namespace 2: qs-fed-role/ns-2-ying@dummy.com

With this solution, you can isolate the users and assets in different namespaces, at the same time, you can simplify the assets deployment process and debug workload with the super admin role and support engineer role.

Enjoy it.

Wouldn’t you get billed for each user then?

Yes. You will get billed for each author or admin. For reader, it is based on sessions.

So in essence this wouldn’t be an economical solution for scaling a multi-tenant solution if each internal admin user has to be paid for each tenant?