Supporting multitenancy with isolated namespaces - Amazon QuickSight

Important: We've redesigned the Amazon QuickSight analysis workspace. You might encounter screenshots or procedural text that doesn't reflect the new look in the QuickSight console. We're in the process of updating screenshots and procedural text.

To find a feature or item, use the Quick search bar.

For more information on QuickSight's new look, see Introducing new analysis experience on Amazon QuickSight.

Supporting multitenancy with isolated namespaces

Amazon QuickSight Enterprise edition supports multitenancy through namespaces. A QuickSight namespace is a logical container that you can use to organize clients, subsidiaries, teams, and so on. Namespaces can help you achieve the following goals:

  • You can allow the users of your QuickSight subscription to discover shared content and share with other users. At the same time, you can be sure that users in one namespace can't see or interact with users in another namespace.

  • You can securely isolate data and also support diverse workloads without adding additional AWS accounts. Access to data is still strictly controlled by AWS security features. Users can see assets (like data and dashboards) only if they have the correct resource permissions. Also, users who have permissions can't inadvertently expose content to people who outside of their namespace. For more information, see AWS security in Amazon QuickSight.

  • You can monitor data flows and usage reports, neatly partitioned by namespace. Categorizing data and reports by namespace can help simplify cost and security analysis.

  • After you've registered users into your namespace, there's no additional administrative complexity or overhead.

  • Namespaces are designed to span AWS Regions, so the use containment doesn't change even if a person signs in to a different AWS Region.

Namespaces currently have the following limitations:

  • Custom namespaces—those that are not the default namespace—are only accessible to IAM Federated Single-Sign On users.

  • Use default namespaces instead of custom namespaces if you need to support the following:

  • You can't transfer users directly from one namespace to another. You can choose to do some or all of this work programmatically. For more information, see the Amazon QuickSight API reference. At the bottom of the page of each API operation, there's a list of links to the same operation in the SDKs for other languages. To see what SDKs are available, see SDKs and toolkits in the AWS getting started resource center.

If you don't have an existing AWS account or you need to sign up for QuickSight, read the following guidelines, then follow the applicable instructions in Signing up for an Amazon QuickSight subscription:

If you already signed up for Standard edition, you can easily upgrade your subscription to Enterprise edition. The person performing the upgrade must be a QuickSight user with administrator privileges. For more information, see Upgrading your Amazon QuickSight subscription from Standard edition to Enterprise edition.

If you have an Enterprise edition subscription that you've been using for some time, it's also possible to migrate your users into namespaces. When you sign up for QuickSight and add users, all of them reside in the default namespace. All of the users can interact directly with each other and share data and dashboards with each other. To isolate your users from each other, you can create one or more additional namespaces.

Important

QuickSight assets and resources, including datasets, data sources, dashboards, analyses, and so on, exist outside of any namespace. They are visible only to users who have resource permissions granted to them.

To implement namespaces, you use the following QuickSight API operations:

Note

If you need to install the AWS CLI, see Installing the AWS CLI version 2 in the AWS Command Line Interface User Guide.

To add users to a namespace, you use the RegisterUser API operation. Each namespace has a completely independent set of users. The user ARNs include the namespace qualifier to distinguish them, as shown in the following examples:

  • QuickSight considers these two entities to be different persons:

    • arn:aws:quicksight:us-east-1:111122223333:user/namespace-123/username123

    • arn:aws:quicksight:us-east-1:111122223333:user/namespace-456/username123

  • QuickSight considers these two entities to be the same person:

    • arn:aws:quicksight:us-east-1:111122223333:user/namespace-123/username123

    • arn:aws:quicksight:us-west-2:111122223333:user/namespace-123/username123

When you use RegisterUser, you select an access level for each user. After a person's user name is assigned to one of the security cohorts, their access to the console and API is restricted. People using QuickSight can have a single access level, as follows:

  • Reader access, for read-only subscribers of a dashboard

  • Author access, for analysts and dashboard designers

  • Admin access, for QuickSight administrators

To migrate existing users in one namespace to a different namespace

  1. Identify the users that you want to transfer to a different namespace by using the QuickSight user and group API operations. For more information, see API operations for controlling access in the Amazon QuickSight API reference.

  2. Create users in the new namespace by using the RegisterUser API operation. Within a namespace, user names are unique.

    If a namespace user starts using the QuickSight console or API in a new AWS Region, that user is still constrained to the namespace that you added them to. Each namespace represents a user directory of an identity provider. As such, it originates in the primary AWS Region where QuickSight is set up. However, because the user directory is propagated globally in your AWS account, the namespace is accessible from any AWS Region where your users are using QuickSight.

  3. To identify the asset and resource permissions that the new namespace users need, use the QuickSight API operations associated with each type of asset (dashboards, datasets, and so on). For more information, see QuickSight API operations to control assets in the Amazon QuickSight API reference.

    For example, let's say you are focusing on dashboards. You can use ListDashboards to list all the dashboard IDs in your AWS account. Then, to determine which users or groups can access these dashboards, you can use DescribeDashboardPermissions on the result set generated by ListDashboards. If you need to identify specific versions of a dashboard, you can ListDashboardVersions for that. You can also collect information about the location of the data that's used in the dashboard with the data source and dataset API operations. For more information, see QuickSight API operations to control data resources in the Amazon QuickSight API reference.

    For more information about filtering API response output, see the SDK documentation for the language you're using. For information relating to the AWS Command Line Interface (AWS CLI), see Controlling command output from the AWS CLI in the AWS Command Line Interface User Guide.

  4. For QuickSight assets and resources, copy the permissions that the source namespace user has for each asset. Then use, for example, UpdateDashboardPermissions to apply the same permissions to the target namespace user. Each asset type has its own separate set of API operations for controlling the permissions that users have to use it. For more information, see QuickSight API operations for asset and resource permissions in the Amazon QuickSight API reference.

  5. When you are finished adding users and permissions, it's a good practice to allow some time for user acceptance testing. Doing this ensures that everyone is successfully using the new namespace. It also ensures that all assets and resources are accessible in the new namespace.

    After you're certain that you no longer need the original user names, you can begin to deprecate their permissions in the original namespace. Finally, when the users are ready, you can remove the unused group and user names in the source namespace. Do this in each AWS Region where your users were previously active.