AWS keyspaces documentation change
Summary
Updated documentation to use concrete AWS account IDs (111111111111, 222222222222, 333333333333) in examples, fixed IAM policy syntax for multiple principals, and corrected VPC endpoint policy structure.
Security assessment
Changes primarily improve example accuracy and policy syntax (e.g., using arrays for multiple principals in IAM policies). While these updates help prevent misconfiguration (which could have security implications), there's no evidence they address a specific disclosed vulnerability or security incident. The updates are documentation improvements rather than security fixes.
Diff
diff --git a/keyspaces/latest/devguide/access.cross-account.noVPC.setup.md b/keyspaces/latest/devguide/access.cross-account.noVPC.setup.md index d509a971b..7e512f114 100644 --- a//keyspaces/latest/devguide/access.cross-account.noVPC.setup.md +++ b//keyspaces/latest/devguide/access.cross-account.noVPC.setup.md @@ -7 +7 @@ -If the Amazon Keyspaces table and private VPC endpoint are owned by different accounts but are not sharing a VPC, applications can still connect cross-account using VPC endpoints. Because the accounts are not sharing the VPC endpoints, `Account A`, `Account B`, and `Account C` require their own VPC endpoints. To the Cassandra client driver, Amazon Keyspaces appears like a single node instead of a multi-node cluster. Upon connection, the client driver reaches the DNS server which returns one of the available endpoints in the account’s VPC. +If the Amazon Keyspaces table and private VPC endpoint are owned by different accounts but are not sharing a VPC, applications can still connect cross-account using VPC endpoints. Because the accounts are not sharing the VPC endpoints, `Account A:111111111111`, `Account B:222222222222`, and `Account C:333333333333` require their own VPC endpoints. To the Cassandra client driver, Amazon Keyspaces appears like a single node instead of a multi-node cluster. Upon connection, the client driver reaches the DNS server which returns one of the available endpoints in the account’s VPC. @@ -9 +9 @@ If the Amazon Keyspaces table and private VPC endpoint are owned by different ac -You can also access Amazon Keyspaces tables across different accounts without a shared VPC endpoint by using the public endpoints or deploying a private VPC endpoint in each account. When not using a shared VPC, each account requires its own VPC endpoint. In this example `Account A`, `Account B`, and `Account C` require their own VPC endpoints to access the table in `Account A`. When using VPC endpoints in this configuration, Amazon Keyspaces appears as a single node cluster to the Cassandra client driver instead of a multi-node cluster. Upon connection, the client driver reaches the DNS server which returns one of the available endpoints in the account’s VPC. But the client driver is not able to access the `system.peers` table to discover additional endpoints. Because there are less hosts available, the driver makes less connections. To adjust this, increase the connection pool setting of the driver by a factor of three. +You can also access Amazon Keyspaces tables across different accounts without a shared VPC endpoint by using the public endpoints or deploying a private VPC endpoint in each account. When not using a shared VPC, each account requires its own VPC endpoint. In this example `Account A:111111111111`, `Account B:222222222222`, and `Account C:333333333333` require their own VPC endpoints to access the table in `Account A:111111111111`. When using VPC endpoints in this configuration, Amazon Keyspaces appears as a single node cluster to the Cassandra client driver instead of a multi-node cluster. Upon connection, the client driver reaches the DNS server which returns one of the available endpoints in the account’s VPC. But the client driver is not able to access the `system.peers` table to discover additional endpoints. Because there are less hosts available, the driver makes less connections. To adjust this, increase the connection pool setting of the driver by a factor of three. @@ -13 +13 @@ You can also access Amazon Keyspaces tables across different accounts without a -`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`. @@ -15 +15 @@ You can also access Amazon Keyspaces tables across different accounts without a -###### Configuration for `Account A` +###### Configuration for `Account A:111111111111` @@ -17 +17 @@ You can also access Amazon Keyspaces tables across different accounts without a - 1. Create an Amazon Keyspaces keyspace and table in `Account A`. + 1. Create an Amazon Keyspaces keyspace and table in `Account A:111111111111`. @@ -19 +19 @@ You can also access Amazon Keyspaces tables across different accounts without a - 2. Create an IAM role in `Account A` that has full access to the Amazon Keyspaces table and read access to the Amazon Keyspaces system tables. + 2. Create an IAM role in `Account A:111111111111` that has full access to the Amazon Keyspaces table and read access to the Amazon Keyspaces system tables. @@ -31,2 +31,2 @@ You can also access Amazon Keyspaces tables across different accounts without a - "arn:aws:cassandra:region:Account-A:/keyspace/mykeyspace/table/mytable", - "arn:aws:cassandra:region:Account-A:/keyspace/system*" + "arn:aws:cassandra:us-east-1:111111111111:/keyspace/mykeyspace/table/mytable", + "arn:aws:cassandra:us-east-1:111111111111:/keyspace/system*" @@ -38 +38 @@ You can also access Amazon Keyspaces tables across different accounts without a - 3. Configure a trust policy for the IAM role in `Account A` so that principals in `Account B` and `Account C` can assume the role as trusted accounts. This is shown in the following example. + 3. Configure a trust policy for the IAM role in `Account A:111111111111` so that principals in `Account B:222222222222` and `Account C:333333333333` can assume the role as trusted accounts. This is shown in the following example. @@ -46,2 +46,4 @@ You can also access Amazon Keyspaces tables across different accounts without a - "AWS": "arn:aws:iam::AccountB:role/Cross-Account-Role-B", - "AWS": "arn:aws:iam::AccountC:role/Cross-Account-Role-C" + "AWS": [ + "arn:aws:iam::222222222222:role/Cross-Account-Role-B", + "arn:aws:iam::333333333333:role/Cross-Account-Role-C" + ] @@ -57 +59 @@ For more information about cross-account IAM policies, see [Cross-account polici - 4. Configure the VPC endpoint in `Account A` and attach permissions to the endpoint that allow the roles from `Account B` and `Account C` to assume the role in `Account A` using the VPC endpoint. These permissions are valid for the VPC endpoint that they are attached to. For more information about VPC endpoint policies, see [Controlling access to interface VPC endpoints for Amazon Keyspaces](./vpc-endpoints.html#interface-vpc-endpoints-policies). + 4. Configure the VPC endpoint in `Account A:111111111111` and attach permissions to the endpoint that allow the roles from `Account B:222222222222` and `Account C:333333333333` to assume the role in `Account A` using the VPC endpoint. These permissions are valid for the VPC endpoint that they are attached to. For more information about VPC endpoint policies, see [Controlling access to interface VPC endpoints for Amazon Keyspaces](./vpc-endpoints.html#interface-vpc-endpoints-policies). @@ -59 +61 @@ For more information about cross-account IAM policies, see [Cross-account polici - { + {{ @@ -63 +65 @@ For more information about cross-account IAM policies, see [Cross-account polici - "Sid": "Allow-access-from-specific-IAM-roles", + "Sid": "AllowAccessfromSpecificIAMroles", @@ -65 +66,0 @@ For more information about cross-account IAM policies, see [Cross-account polici - "Principal": "*", @@ -67,0 +69 @@ For more information about cross-account IAM policies, see [Cross-account polici + "Principal": "*", @@ -70,2 +72,4 @@ For more information about cross-account IAM policies, see [Cross-account polici - "aws:PrincipalArn": "arn:aws:iam::AccountB:role/Cross-Account-Role-B", - "aws:PrincipalArn": "arn:aws:iam::AccountC:role/Cross-Account-Role-C" + "aws:PrincipalArn": [ + "arn:aws:iam::222222222222:role/Cross-Account-Role-B", + "arn:aws:iam::333333333333:role/Cross-Account-Role-C" + ] @@ -81 +85 @@ 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` @@ -83 +87 @@ 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`. @@ -90 +94 @@ For more information about cross-account IAM policies, see [Cross-account polici - "Resource": "arn:aws:iam::Account-A:role/keyspaces_access" + "Resource": "arn:aws:iam::111111111111:role/keyspaces_access" @@ -96 +100 @@ 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`. 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`. 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_.