AWS guidance documentation change
Summary
Updated field names from 'payer_id' to 'payer_account_id', changed user/group delimiters from commas to colons, clarified RLS access rules, fixed typos, updated validation queries, corrected CLI flags, and added contributor credits.
Security assessment
Changes primarily involve field/delimiter standardization and documentation clarifications. No evidence of security vulnerability fixes. The RLS feature documentation was updated but not fundamentally changed.
Diff
diff --git a/guidance/latest/cloud-intelligence-dashboards/row-level-security.md b/guidance/latest/cloud-intelligence-dashboards/row-level-security.md index b069fc37c..3a6d75419 100644 --- a//guidance/latest/cloud-intelligence-dashboards/row-level-security.md +++ b//guidance/latest/cloud-intelligence-dashboards/row-level-security.md @@ -46 +46 @@ For CID dashboards, RLS dataset requires four essential fields: - * **payer_id** : Comma-separated list of billing accounts (management accounts) + * **payer_account_id** : Comma-separated list of billing accounts (management accounts) @@ -59 +59 @@ It is important to understand the RLS Dataset and how it works for different cas - * **Full access** : Users with empty `account_id` and `payer_id` fields have full data access (recommended for Security, FinOps and Platform teams) + * **Full access** : Users with empty `account_id` and `payer_account_id` fields have full data access (recommended for Security, FinOps and Platform teams) @@ -61 +61 @@ It is important to understand the RLS Dataset and how it works for different cas - * **Organization access** : Users with empty `account_id` but populated `payer_id` have access to all accounts in the specified AWS Organization + * **Organization access** : Users with empty `account_id` but populated `payer_account_id` have access to all accounts in the specified AWS Organization @@ -89 +89 @@ The RLS implementation follows this workflow: - 1. `cid_users`: Comma-separated list of user emails (must match Quick Suite exactly) + 1. `cid_users`: Colon-separated (`:`) list of user emails (must match Quick Suite exactly) @@ -91 +91 @@ The RLS implementation follows this workflow: - 2. `cid_groups`: Comma-separated list of Quick Suite groups with access + 2. `cid_groups`: Colon-separated (`:`) list of Quick Suite groups with access @@ -116 +116 @@ CID constructs an RLS dataset from several sources. - 1. **full_access_users** \- is a view or a table that contains a list of emails of users who supposed to have a full unrestricted access to protected datasets. This view can be edited in Athena directly (https://docs.aws.amazon.com/athena/latest/ug/views-managing.html) as [linline table](https://prestodb.io/docs/current/sql/values.htm) or it can be replaced with the tables that comes from other sources (your identity management or a simple csv file on Amazon S3). We do not recommend using individual users for this and rather prioritize user management with groups, but it can be handy on the initial setup phase. Please make sure you put exactly the same email as you have in Quick Suite. + 1. **full_access_users** \- is a view or a table that contains a list of emails of users who are supposed to have a full unrestricted access to protected datasets. This view can be edited in Athena directly (https://docs.aws.amazon.com/athena/latest/ug/views-managing.html) as [linline table](https://prestodb.io/docs/current/sql/values.htm) or it can be replaced with the tables that comes from other sources (your identity management or a simple csv file on Amazon S3). We do not recommend using individual users for this and rather prioritize user management with groups, but it can be handy on the initial setup phase. Please make sure you put exactly the same email as you have in Quick Suite. @@ -120 +120 @@ CID constructs an RLS dataset from several sources. - 3. **account_access** \- a view or a table that has following fields: + 3. **account_access** \- a view or a table that has the following fields: @@ -124 +124 @@ CID constructs an RLS dataset from several sources. - 2. `payer_id` \- an AWS Management Account Id. Users and groups that have access to the `account_id` == `payer_id` will have access to all account under the AWS Organization with this management account id. The tool supports multiple AWS Organizations. + 2. `payer_account_id` \- an AWS Management Account Id. Users and groups that have access to the `account_id` == `payer_id` will have access to all accounts under the AWS Organization with this management account id. The tool supports multiple AWS Organizations. @@ -136 +136 @@ CID constructs an RLS dataset from several sources. - 3. `payer_id` \- a comma separated list of accounts + 3. `payer_account_id` \- a comma separated list of accounts @@ -151 +151 @@ CID constructs an RLS dataset from several sources. - * if both `payer_id` and `account_id` are empty then the user or the group in this line will have a full access + * if both `payer_account_id` and `account_id` are empty then the user or the group in this line will have a full access @@ -153 +153 @@ CID constructs an RLS dataset from several sources. - * if only `payer_id` is provided but `account_id` is empty, the user or the group will have access to all account in the AWS Organization of the given payer Account + * if only `payer_account_id` is provided but `account_id` is empty, the user or the group will have access to all account in the AWS Organization of the given payer Account @@ -183 +183 @@ Choose one of the three options described above to define your RLS data source: -If you have already [CID Data Collection Stack](./data-collection.html) you can just check if Quick Suite and OrganizationData modules are activated, and continue to the next step. +If you have already [CID Data Collection Stack](./data-collection.html) you can just check if Quick Suite (IncludeQuickSightModule parameter) and OrganizationData (IncludeOrgDataModule parameter) modules are activated, and continue to the next step. @@ -191 +191 @@ Here we will use the minimal setup for managing access from AWS Organization OU - 2. Login to Data Collection/Dashboard Account and install the Data Collection Stack by clicking Launch Stack below. Put Management Account Ids parameter as a comma separated list of your Management Accounts. + 2. Login to Data Collection/Dashboard Account and install the Data Collection Stack by clicking Launch Stack below. Put Management Account Ids parameter as a comma separated list of your Management Accounts. Make sure you’ve set to 'yes' Quick Suite (IncludeQuickSightModule parameter) and OrganizationData (IncludeOrgDataModule parameter) modules. @@ -197 +197 @@ Here we will use the minimal setup for managing access from AWS Organization OU - 1. `cid_group` as comma separated Quick Suite Group. + 1. `cid_groups` as colon-separated (`:`) Quick Suite Groups. @@ -199 +199 @@ Here we will use the minimal setup for managing access from AWS Organization OU - 2. and/or `cid_user` as comma separated emails of individual users + 2. and/or `cid_users` as colon-separated (`:`) emails of individual users @@ -201 +201 @@ Here we will use the minimal setup for managing access from AWS Organization OU - 4. After update you can launch execution of the data collection using a [StepFunction](https://console.aws.amazon.com/states/home) `CID-DC-organizations-StateMachine`. + 4. After update you can launch execution of the data collection by triggering `CID-DC-organizations-StateMachine` and `CID-DC-quicksight-StateMachine` [StepFunctions](https://console.aws.amazon.com/states/home). @@ -203 +203 @@ Here we will use the minimal setup for managing access from AWS Organization OU - 5. You can validate data using following query: + 5. You can validate data using the following query: @@ -205 +205,4 @@ Here we will use the minimal setup for managing access from AWS Organization OU - SELECT * FROM "organization_data" + SELECT * FROM "optimization_data"."organization_data" + SELECT * FROM "optimization_data"."quicksight_user_data" + SELECT * FROM "optimization_data"."quicksight_group_data" -- can be empty if you don't have Quick Suite groups + SELECT * FROM "optimization_data"."quicksight_groupmembership_data" -- can be empty if you don't have Quick Suite groups @@ -226 +229 @@ The Data Collection is needed to collect data from local Quick Suite account and - ) ignored_table_name ("account_id", "payer_id", "emails", "groups") + ) ignored_table_name ("account_id", "payer_account_id", "emails", "groups") @@ -230 +233 @@ The Data Collection is needed to collect data from local Quick Suite account and - payer_id as ManagementAccountId, + payer_account_id as ManagementAccountId, @@ -246 +249 @@ The Data Collection is needed to collect data from local Quick Suite account and - "account_id", "payer_id", "emails", "groups" + "account_id", "payer_account_id", "emails", "groups" @@ -260 +263 @@ The Data Collection is needed to collect data from local Quick Suite account and - "payer_id" string, + "payer_account_id" string, @@ -285 +288 @@ The Data Collection is needed to collect data from local Quick Suite account and - payer_id as ManagementAccountId, + payer_account_id as ManagementAccountId, @@ -324 +327 @@ The Data Collection is needed to collect data from local Quick Suite account and - cid-cmd update --force --recursive --rls ENABLE + cid-cmd update --force --recursive --rls ENABLED @@ -328 +331 @@ The Data Collection is needed to collect data from local Quick Suite account and - * Disable RLS: `--rls DISABLE` + * Disable RLS: `--rls DISABLED` @@ -362 +365 @@ Use the CID-CMD tool to enable RLS on any dashboard: - cid-cmd update --force --recursive --rls ENABLE + cid-cmd update --force --recursive --rls ENABLED @@ -364 +367 @@ Use the CID-CMD tool to enable RLS on any dashboard: -**Management Options** : * Disable: `--rls DISABLE` * Remove: `--rls CLEAR` +**Management Options** : * Disable: `--rls DISABLED` * Remove: `--rls CLEAR` @@ -391,0 +395,4 @@ This guide focuses on AWS Account ID-based access, but you can adapt it for [Org + * Yin Lei, Sr. Technical Account Manager, AWS + + * Yuriy Prykhodko, Principal Technical Account Manager, AWS +