AWS clean-rooms documentation change
Summary
Added note about multi-party collaboration access control using aws:SourceArn conditions
Security assessment
Explains security controls for role assumption in collaborations but does not reference a specific vulnerability
Diff
diff --git a/clean-rooms/latest/userguide/setting-up-roles.md b/clean-rooms/latest/userguide/setting-up-roles.md index 221eaa795..1b23ee512 100644 --- a//clean-rooms/latest/userguide/setting-up-roles.md +++ b//clean-rooms/latest/userguide/setting-up-roles.md @@ -204,0 +205,10 @@ JSON +###### Note + +This policy references two different AWS account IDs to support a AWS Clean Rooms collaboration where data catalog metadata and actual data storage are managed by different parties: + + * **111122223333** \- This is the account that owns the AWS Glue Data Catalog resources (databases, tables, and catalog). The first statement grants permissions to access table schemas, partition information, and metadata from this account's AWS Glue catalog. + + * **444455556666** \- This is the account that owns the Amazon S3 bucket containing the actual data files. The Amazon S3 permissions (statements 3 and 4) are restricted to buckets owned by this account through the `s3:ResourceAccount` condition. + +This configuration supports common enterprise data architectures where one team manages the data catalog and schema definitions while another team owns the underlying data storage infrastructure. The `s3:ResourceAccount` condition provides an additional security layer by ensuring Amazon S3 operations only work on buckets owned by the designated account. + @@ -404,0 +415,10 @@ JSON +###### Note + +This trust policy references two different AWS account IDs to support a AWS Clean Rooms collaboration where query execution responsibilities are distributed across multiple parties: + + * **111122223333** \- This is the account that contains a membership participating in the collaboration. This membership may own data tables, analysis rules, or other collaboration resources that require role access. + + * **444455556666** \- This is the account that contains the membership responsible for running queries (the "query runner"). This membership executes protected queries and needs to assume this role to access the necessary compute and data resources. + +This configuration enables scenarios where one party provides data or analysis templates while another party runs the actual queries. Both roles require different but complementary permissions through the same execution role. The `aws:SourceArn` condition ensures that only AWS Clean Rooms operations originating from these two specific memberships can assume the role, maintaining security while supporting the distributed job execution and result management workflow. + @@ -438,0 +459,18 @@ JSON +###### Note + +This policy references two different AWS account IDs to support a cross-account secrets management scenario: + + * **111122223333** \- This is the account that owns and stores the secret in . The first statement grants permission to retrieve the secret value from this account. + + * **444455556666** \- This is the account that owns the AWS KMS key used to encrypt the secret. The second statement grants permission to decrypt the secret using the AWS KMS key from this account. + +This configuration is common in enterprise environments where: + + * Secrets are centrally managed in one account (Account 1) + + * Encryption keys are managed by a separate security or shared services account (Account 2) + + * The AWS KMS key policy in Account 2 must also allow the service in Account 1 to use the key for encryption/decryption operations + +The `kms:EncryptionContext:SecretARN` condition ensures that the AWS KMS key can only be used to decrypt this specific secret, providing an additional layer of security for cross-account access. + @@ -503,0 +542,10 @@ JSON +###### Note + +This trust policy references two different AWS account IDs to support a multi-party AWS Clean Rooms collaboration scenario: + + * **111122223333** \- This is the account that contains the membership responsible for running queries (the "job runner"). This membership executes the analysis jobs and needs to assume this role to access the necessary resources. + + * **444455556666** \- This is the account that owns the analysis template and its associated membership (the "analysis template owner"). This membership defines what queries can be run and also needs to assume this role to manage and execute the analysis. + +This configuration is typical in AWS Clean Rooms collaborations where multiple parties participate in the same collaboration, each with their own AWS account and membership. Both the query executor and the analysis template owner need access to shared resources. The `aws:SourceArn` condition ensures that only AWS Clean Rooms operations originating from these two specific memberships can assume the role, providing precise access control for the multi-party collaboration. + @@ -598,0 +647,10 @@ JSON +###### Note + +This trust policy references two different AWS account IDs to support a AWS Clean Rooms collaboration with distinct operational roles: + + * **111122223333** \- This is the account that contains the membership responsible for running analysis jobs (the "job runner"). This membership executes the computational workloads and needs to assume this role to access processing resources. + + * **444455556666** \- This is the account that contains the membership with result receiver (RR) responsibilities. This membership is authorized to receive and access the output of analysis jobs, and needs role access to write results to designated locations. + +This configuration enables AWS Clean Rooms scenarios where one party runs the computational analysis while another party receives and manages the results. Both roles require different but complementary permissions through the same execution role. The `aws:SourceArn` condition ensures that only AWS Clean Rooms operations originating from these two specific memberships can assume the role, maintaining security while supporting the distributed job execution and result management workflow. +