Hi, we have an in-house Quick Sight account (adsbi) for Ads wide reporting and Analytics needs. We onboard customers on this account through cross-account Glue catalog access.
For one of our use-cases, one of our customers requested us to add a KMS policy to the Quick Sight IAM role to access customer side decrypt keys (CMK). We followed the SOP (Allowing users in other accounts to use a KMS key - AWS Key Management Service), but faced an error.
If we create a policy to give access to the CMK to our Quick Sight IAM role, we get an error - “Quick Sight has detected unknown policies attached to the following role”, and then we need to delete and reset the Quick Sight role. This causes customer frustration, and a very negative experience. Is there a solution here?
Thank you for explaining the situation. I can understand the frustration caused when attaching additional policies to the Quick Sight IAM role results in errors.
There might be a workaround to allow accessing cross-account KMS keys from Quick Sight without modifying the Quick Sight role directly:
-
Create a new IAM role in your account that has the permissions to access the cross-account KMS key. Attach the customer’s key policy to this role.
-
Create an IAM user in your account and assign the newly created IAM role to this user.
-
Use this IAM user’s access key and secret to authenticate to Quick Sight as a data source. When connecting to data sources like Amazon Redshift, you can specify IAM credentials to use for authentication.
-
The queries made by Quick Sight using this data source will now use the IAM role with access to the cross-account KMS key.
This allows Quick Sight to access the required key without modifying the Quick Sight managed role directly. The key thing is to authenticate to data sources using an IAM user with the appropriate role rather than using the Quick Sight role.
Let me know if this helps resolve the issue!
If yes, please go ahead and mark this as a solution.
Thank you!
GL
Hi @gillepa , Thanks for the alternative approach. Do we have any SOP / Blog on the Step No. 3?
Thanks @gillepa. I’m curious - why is there only a workaround for this? Why does Quicksight cause problems when we make changes to IAM rather than in Quicksight console? This is unnecessary work for admins given we need to create and maintain a unique IAM user for each of our 100+ customer teams. Can Quicksight fix this issue so we don’t need to use a workaround solution?
+1, we’re using Athena connection not Redshift… so there’s not an option to provide IAM user’s access key/secret
another helpful resource is:
Thanks @gillepa . I have gone through this article - and it calls for modifying (or updating the Quick Sight IAM role) outside of Quick Sight console. I am not very inclined to take this risk - as Quick Sight strictly prohibits us to modify the IAM role outside of the console. We have tried attaching policies to the role 3 times, and have led to the IAM role being reset