Row Level Security
Last Updated
November 2022
Authors
- Stephanie Gooch, Sr. Commercial Architect, AWS OPTICS
- Veaceslav Mindru, Sr. Technical Account Manager, AWS
Introduction
Cloud Intelligence Dashboards (CID) helps you to visualize and understand AWS cost and usage data in your organization by exploring interactive dashboards. However, in order to maintain least privilege principle, customers who use CID at scale of organization often would like to provide their users access only to the data for linked accounts which they own. Using Row Level Security (RLS) enables you to restrict the data a user can see to just what they are allowed to. This also applicable for customers with Multiple Management (Payer) Accounts .
Prerequisite
For this solution you must have the following:
- Access to your AWS Organizations and ability to tag resources
- An AWS Cost and Usage Reports (CUR) or if from the multiple payers these must be replicated into a bucket, more info here
- A CID deployed over this CUR data, checkout the new single deployment method here.
- A list of users and what level of access they require. This can be member accounts, organizational units (OU) or payers.
Solution
This solution will use tags from your AWS Organization resources to create a dataset that will be used for the Row Level Security.

Step by Step Guide
Part1: Roles
If you are deploying this in a linked account you will need a Role in you Management account to let you access your AWS Organizations Data. There are two options for this:
Option1 If you already have the Optimization Data Collector Lab deployed you can use the Management role in that.
Option2 Else, you can deploy using the below:
Deployed Management Role
Log into your Management account then click Launch CloudFormation Template
Call the Stack OptimizationManagementDataRoleStack
In the Parameters section set CostAccountID as the ID of Cloud Intelligence Dashboard
Scroll to the bottom and click Next
Tick the acknowledge boxes and click Create stack.
You can see the role that was collected by clicking on Resources and clicking on the hyperlink under Physical ID.

Part2: Tag your AWS Organization Resources
You must tag the AWS Organization Resources with the emails of the Quicksight Users that you wish to allow access to see the resources cost data. The below will show you how to tag a resource and this can be repeated. We will be using AWS Quicksight User Emails, see more here. If you have a large list of accounts and want to use a script, please see the section below Use script to tag accounts
- Log into your Management account then click on the top right hand corner on your account and select Organization

- Ensure you are on the AWS accounts tab
You can select different levels of access. Tag one of the following and the use will have access to all data of that resource and any child accounts below it.
- Tag an Account
- Tag an Organization Unit
- Tag the Root
- To tag the resource click its name an scroll down to the tag section and click Manage tags

- Add the Key cid_users and the Value of any emails you wish to allow access. These are colon delimited. Once added click Save changes

- Repeat on all resources with relevant emails.
Part3: Deploy Lambda Function
Using AWS CloudFormation we will deploy the lambda function to collect these tags.
- Log into your account with your QuickSight Cloud Inteligence Dashboards also known as CID. Click Launch CloudFormation template

Click Next.
Fill in the Parameters as seen below.
- CodeBucket - aws-well-architected-labs-{REGION-NAME} e.g. aws-well-architected-labs-ireland
AllowedValues S3
- aws-well-architected-labs-ireland
- aws-well-architected-labs (Oregon)
- aws-well-architected-labs-ohio
- aws-well-architected-labs-virginia
- aws-well-architected-labs-california
- aws-well-architected-labs-oregon
- aws-well-architected-labs-singapore
- aws-well-architected-labs-frankfurt
- aws-well-architected-labs-london
- aws-well-architected-labs-stockholm
- aws-well-architected-labs-ap-sydney
- aws-well-architected-labs-mumbai
- aws-well-architected-labs-osaka
- aws-well-architected-labs-seoul
- aws-well-architected-labs-tokyo
- aws-well-architected-labs-canada
- aws-well-architected-labs-milan
- aws-well-architected-labs-paris
- CodeKey - LEAVE AS DEFAULT
- DestinationBucket - Amazon S3 Bucket in your account in the same region (this can be one from your Optimization data collector where where your CUR is stored). This bucket must have access to Amazon Quicksight
- ManagementAccountID - List of Payer IDs you wish to collect data for. Can just be one Accounts(Ex: 111222333,444555666,777888999)
- ManagementAccountRole - The name of the IAM role that will be deployed in the management account which can retrieve AWS Organization data. KEEP THE SAME AS WHAT IS DEPLOYED INTO MANAGEMENT ACCOUNT
- RolePrefix - This prefix will be placed in front of all roles created. Note you may wish to add a dash at the end to make more readable
- Schedule - Cron job to trigger the lambda using cloudwatch event. Default is once a day

Tick the boxes and click Create stack.

Wait until your CloudFormation has a status of CREATE_COMPLETE.

Part4: Test Lambda Function
Your lambda functions will run automatically on the schedule you chose at deployment and will be ready within an hour. However, if you would like to test your functions please see the steps below.
Once you have deployed your modules you will be able to test your Lambda function to get your first set of data in Amazon S3.
- From CloudFormation Click Resources and find the Lambda Function and click the Physical ID
2. To test your Lambda function open respective Lambda in AWS Console and click Test
- Enter an Event name of Test, click Create:

Click Test
The function will run, it will take a minute or two given the size of the Organizations files and processing required, then return success. Click Details and view the output.
You can go to your bucket in S3 and there should be a file in the folder CUDOS_RLS.

Download this qs_s3_manifest.json file and replace with the bucket you can see your data in.
Part5: Create RLS
We will now create the RLS Dataset in Amazon QuickSight and attach it to your datasets for CID. Please ensure the bucket you have placed the RLS file into has access to Amazon QuickSight, see here
Go to Amazon QuickSight and login
Go to Datasets and click New dataset

Create new Dataset by clicking S3

Set Data source name as CID RLS and the qs_s3_manifest.json file you edited earlier into the Upload box

Find your new dataset by searching CID RLS then click on it

Click on your new dataset and select the Refresh tab and click ADD NEW SCHEDULE

Choose Hourly and click SAVE

Go back to Datasets and select your CID data summary_view. On the Summary tab find Row-level security and click Edit

Click the toggle User-based ON then expand the User-based rules section and select the CID RLS dataset we made earlier

Scroll down and click Apply dataset

Refresh the summary_view datasets
Repeat for all other CID Datasets
Use script to tag accounts
If you have a large number of accounts that need to be tagged then please use the guide below to do a scripted method to save time.
Click here to expand guide
For this you will need:
- a list of all of your accounts you wish to tag. If you do not have one, you can export your AWS Organizations using this guide
- a list of all QuickSight users email which you wish to tag this Organization with. Currently you cannot directly download this data but you can use the following cli command replacing 111122223333 with your Management account
- cli credentials for your management account or ability to create a lambda function and you will find the file in your tmp folder
aws quicksight list-users --namespace default --output text --aws-account-id 111122223333 > /tmp/quicksight_user.txt
Steps to tag
Download this example file and this code file and save as aws_org_tagger_lambda.py
In the file, remove the example line and add your list of account id’s in the first column. Then add the relevant QuickSight users emails that you want to have access to the account. Remember if multiple they need tbe separated by :
Save this file.
You can either run the script using cli or creating a lambda function.
CLI
- If CLI then ensure your data.csv file and aws_org_tagger_lambda.py are in the same folder
- Run
python3 aws_org_tagger_lambda.py
Lambda
- Log into your Management account and go to Lambda
- Create new Lambda and call it Tag-Organization and use Python 3.9
- In the lambda, copy the code from the aws_org_tagger_lambda.py file
- Click on the left hand side of the Environment and click New File
- In the file paste your data.csv data making sure it has the comers in it*
- Click Deploy
- Click on Configuration then Permissions. There will be a Role Name in blue, click on that link.
- This will take you to IAM where you Add permissions > Attach policies
- Search for AWSOrganizationsFullAccess and add this policy
- Go back to lambda and click to the Test tab then the orange Test button.
Now your AWS Organization will have new or updated tags with the data from your excel sheet
If you would like to turn off RLS you can just toggle the User-based ON to OFF
See the impact
Now when you go to your Dashboard the users who had been tagged on the accounts will only see their data