AWS keyspaces documentation change
Summary
Added explicit AWS account IDs and role ARNs in cross-account access documentation, replacing placeholder values with concrete examples
Security assessment
The changes improve documentation clarity by adding specific account IDs and role ARNs in cross-account IAM policies, but do not address a specific security vulnerability. While this enhances security configuration examples, there's no evidence of a security incident being fixed. The modifications demonstrate proper security practices rather than patching a weakness.
Diff
diff --git a/keyspaces/latest/devguide/access.cross-account.sharedVPC.md b/keyspaces/latest/devguide/access.cross-account.sharedVPC.md index 30b0392e5..ce06e7e57 100644 --- a//keyspaces/latest/devguide/access.cross-account.sharedVPC.md +++ b//keyspaces/latest/devguide/access.cross-account.sharedVPC.md @@ -13 +13 @@ In this example we use the following three accounts in a shared VPC: - * `Account A` – This account contains infrastructure, including the VPC endpoints, the VPC subnets, and Amazon Keyspaces tables. + * `Account A:111111111111` – This account contains infrastructure, including the VPC endpoints, the VPC subnets, and Amazon Keyspaces tables. @@ -15 +15 @@ In this example we use the following three accounts in a shared VPC: - * `Account B` – This account contains an application in a development environment that needs to connect to the Amazon Keyspaces table in `Account A`. + * `Account B:222222222222` – This account contains an application in a development environment that needs to connect to the Amazon Keyspaces table in `Account A:111111111111`. @@ -17 +17 @@ In this example we use the following three accounts in a shared VPC: - * `Account C` – This account contains an application in a production environment that needs to connect to the Amazon Keyspaces table in `Account A`. + * `Account C:333333333333` – This account contains an application in a production environment that needs to connect to the Amazon Keyspaces table in `Account A:111111111111`. @@ -24 +24 @@ In this example we use the following three accounts in a shared VPC: -`Account A` is the account that contains the resources (an Amazon Keyspaces table) that `Account B` and `Account C` need to access, so `Account A` is the _trusting_ account. `Account B` and `Account C` are the accounts with the principals that need access to the resources (an Amazon Keyspaces table) in `Account A`, so `Account B` and `Account C` are the _trusted_ accounts. The trusting account grants the permissions to the trusted accounts by sharing an IAM role. The following procedure outlines the configuration steps required in `Account A`. +`Account A:111111111111` is the account that contains the resources (an Amazon Keyspaces table) that `Account B:222222222222` and `Account C:333333333333` need to access, so `Account A:111111111111` is the _trusting_ account. `Account B:222222222222` and `Account C:333333333333` are the accounts with the principals that need access to the resources (an Amazon Keyspaces table) in `Account A:111111111111`, so `Account B:222222222222` and `Account C:333333333333` are the _trusted_ accounts. The trusting account grants the permissions to the trusted accounts by sharing an IAM role. The following procedure outlines the configuration steps required in `Account A:111111111111`. @@ -26 +26 @@ In this example we use the following three accounts in a shared VPC: -###### Configuration for `Account A` +###### Configuration for `Account A:111111111111` @@ -28 +28 @@ In this example we use the following three accounts in a shared VPC: - 1. Use AWS Resource Access Manager to create a resource share for the subnet and share the private subnet with `Account B` and `Account C`. + 1. Use AWS Resource Access Manager to create a resource share for the subnet and share the private subnet with `Account B:222222222222` and `Account C:333333333333`. @@ -30 +30 @@ In this example we use the following three accounts in a shared VPC: -`Account B` and `Account C` can now see and create resources in the subnet that has been shared with them. +`Account B:222222222222` and `Account C:333333333333` can now see and create resources in the subnet that has been shared with them. @@ -36 +36 @@ In this example we use the following three accounts in a shared VPC: - 4. Create an IAM role in `Account A` that has full access to the Amazon Keyspaces table, read access to the Amazon Keyspaces system tables, and is able to describe the Amazon EC2 VPC resources as shown in the following policy example. + 4. Create an IAM role in `Account A:111111111111` that has full access to the Amazon Keyspaces table, read access to the Amazon Keyspaces system tables, and is able to describe the Amazon EC2 VPC resources as shown in the following policy example. @@ -54 +54 @@ In this example we use the following three accounts in a shared VPC: - 5. Configure a trust policy for the IAM role in `Account A` so that `Account B` and `Account C` can assume the role as trusted accounts. This is shown in the following example. + 5. Configure a trust policy for the IAM role in `Account A:111111111111` so that `Account B:222222222222` and `Account C:333333333333` can assume the role as trusted accounts. This is shown in the following example. @@ -62,2 +62,4 @@ In this example we use the following three accounts in a shared VPC: - "AWS": "arn:aws:iam::AccountB:role/Job-role-B", - "AWS": "arn:aws:iam::AccountC:role/Job-role-C" + "AWS": [ + "arn:aws:iam::222222222222:role/Cross-Account-Role-B", + "arn:aws:iam::333333333333:role/Cross-Account-Role-C" + ] @@ -76 +78 @@ For more information about cross-account IAM policies, see [Cross-account polici -###### Configuration in `Account B` and `Account C` +###### Configuration in `Account B:222222222222` and `Account C:333333333333` @@ -78 +80 @@ For more information about cross-account IAM policies, see [Cross-account polici - 1. In `Account B` and `Account C`, create new roles and attach the following policy that allows the principal to assume the shared role created in `Account A`. + 1. In `Account B:222222222222` and `Account C:333333333333`, create new roles and attach the following policy that allows the principal to assume the shared role created in `Account A:111111111111`. @@ -95 +97 @@ Allowing the principal to assume the shared role is implemented using the `Assum - 2. In `Account B` and `Account C`, you can create applications that utilize the SIGV4 authentication plugin, which allows an application to assume the shared role to connect to the Amazon Keyspaces table located in `Account A` through the VPC endpoint in the shared VPC. For more information about the SIGV4 authentication plugin, see [Create credentials for programmatic access to Amazon Keyspaces ](./programmatic.credentials.html). For more information on how to configure an application to assume a role in another AWS account, see [Authentication and access](https://docs.aws.amazon.com/sdkref/latest/guide/access.html) in the _AWS SDKs and Tools Reference Guide_. + 2. In `Account B:222222222222` and `Account C:333333333333`, you can create applications that utilize the SIGV4 authentication plugin, which allows an application to assume the shared role to connect to the Amazon Keyspaces table located in `Account A:111111111111` through the VPC endpoint in the shared VPC. For more information about the SIGV4 authentication plugin, see [Create credentials for programmatic access to Amazon Keyspaces ](./programmatic.credentials.html). For more information on how to configure an application to assume a role in another AWS account, see [Authentication and access](https://docs.aws.amazon.com/sdkref/latest/guide/access.html) in the _AWS SDKs and Tools Reference Guide_.