🧪 Test the following assumptions for Authors, Data Admins and AP Admins

[Ed-Bajo]

User Story

As Platform Engineers, I would like to carry out a pilot on managing and granting access to the QuickSight tool on the Analytical Platform, so that we ascertain if it is a tool we can recommend for data visualisation and dashboard.

Value / Purpose

Access to visualisation or dashboard tools will remove the need for teams to build visualisation tools from scratch.

Useful Contacts

@julialawrence
@Ed-Bajo

Proposal

We are currently offering QuickSight to 45 active users on an adhoc basis with management being entirely manual. We would like to carry out a pilot on managing this offering in code as maintainability and scaling will form a part of our selection criteria.

Hypothesis

Test the following assumptions for data owners and dashboard designers

QuickSight New User Experience:

• API endpoint exists to automate user invites to QS (this process is automatable)
• If a password is needed to authenticate, users can reset their password.
• By default, AP users are created as AUTHORS in QuickSight
• By default, AP admins are created as ADMINS in QuickSight

QuickSight Author Functionality

• QuickSight Users are able to create dashboards and share them with other QuickSight Users.

Operations

• QuickSight Can maintain a regularly synced copy of data in its datasource (realtime??? Scheduled??)
• QuickSight Users in DPAT/London can access data in AP Data Production Ireland (cross-account)
• QuickSight User access to datasources can be managed directly in QS and can be derived from their IAM permissions
• QuickSight Users’ IAM permissions DO NOT require lengthy policy statements (one policy for all QS access)

Security Considerations

• Users are unable to share datasets with users whose IAM does grant them access to this data.
• Users' data access is restricted to data permissions granted in the Control Panel
• Quicksight allows restricting creation of Authors and Admins to IAM users/identities only
• QuickSight Users’ IAM permissions can be programmatically replicated and constrained in QS
• Combining QuickSight datasource/dataset management approaches allows permission granularity to the S3 object/Athena table level
• Viewers can’t just roll up and create an account even if they don’t get datasource access
• Non-admin users can be prevented from managing permissions on datasources directly in QuickSight.

User Experience

• Dashboards can be made public (capture cost implications)

Additional Information

• This will require carrying out a click-ops deployment in Modernisation Platform Apps & Tools Development Account
• Users might not be mapped to justice email, github emails can be personal. Therefore consider limiting or enabling this private beta for justice identity only.
• Additional blocking assumptions might be identified in the process of implementation and follow-on stories might be required.

Definition of Done

• Deployment stood up
• Assumptions tested
• Conclusions collated and presented to the team
• Way forward agreed
• Subsequent stories raised

[Gary-H9]

Work done on Friday 2nd / Monday 5th captured in this Slack Canvas.

TLDR:

• Users receive email invitations when they are added to a Dashboard, either as a Viewer or Co-Owner.
• Dashboards can be shared with everyone in the AWS account by making them "viewable for all users in the account" and "discoverable in QuickSight," which allows all users to see the dashboard. However, mass sharing could impact the user experience and raise security concerns by potentially exposing data to unauthorized parties.
• Sharing a dashboard also provides access to the associated analyses and the data used in them.
• When a user requests QuickSight Q, Admins are notified via email for approval. Usage is contingent on proper licensing.
• There's a possibility to include the author's name in the Dashboard title, which can be achieved using parameters, as outlined in the provided QuickSight documentation link.

[Gary-H9]

Assumption testing is being done in this Slack Canvas. This will provide context to the above Checkboxes being completed or not.

Actions from yesterdays call were:

• Decide which AWS account the new QuickSight should be built in. Update this issue with this information.
• Create an issue for the work required in Control Panel - ✨ Button to access QuickSight from Control Panel #3228
• Decide which login flow we want the users in the new QuickSight to take
• Document user first login
• Create architectural diagram 🗺️ Create Diagram of the AWS QuickSight Implementation #3229
• Add quicksight:CreateReader permissions to the alpha users via terraform - 🛂 Placeholder - Alpha User QuickSight Permissions #3233

[jacobwoffenden]

Closing as complete, work has been spun out into separate stories