Cross Account Functionality for S3 File Connections
By using cross account functionality for S3 File Connections, you can control access to your S3 buckets in a more granular way.
With DataMasque, there are two approaches to having cross account functionality for S3 File Connections:
Using S3 Bucket Policies
This section presents a guide on enabling cross-account access to S3 buckets. We use the following example scenario to demonstrate this functionality.
Scenario
You have deployed DataMasque on an EC2 or an EKS cluster in Account A, and you want DataMasque to access buckets in Account B and Account C.
Figure 1.0 gives an overview of how this access is enabled.
Figure 1.0
| Account Name | Account ID | Description |
|---|---|---|
| Account A | 1111-1111-1111 | DataMasque is deployed on an EC2 or EKS instance in this account. |
| Account B | 2222-2222-2222 | This account has an S3 bucket to be accessed by the DataMasque instance in Account A. |
| Account C | 3333-3333-3333 | This account has an S3 bucket to be accessed by the DataMasque instance in Account A. |
Account A Setup
In Account A, perform the following setup:
Create an IAM policy that allows reading/writing to all S3 buckets. While this policy allows the DataMasque instance to attempt to access any bucket, the level of access to a bucket is specified based on the bucket policies applied on the target account (where the bucket resides).
The policy in the source account (Account A) should look like this:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "SourceBucketRead",
"Effect": "Allow",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::*"
},
{
"Sid": "SourceBucketPermissionCheck",
"Effect": "Allow",
"Action": [
"s3:ListBucket",
"s3:GetBucketAcl",
"s3:GetBucketPolicyStatus",
"s3:GetBucketPublicAccessBlock"
],
"Resource": [
"arn:aws:s3:::*"
]
},
{
"Sid": "DestinationBucketWrite",
"Effect": "Allow",
"Action": [
"s3:PutObject"
],
"Resource": "arn:aws:s3:::*"
},
{
"Sid": "DestinationBucketSecurityCheck",
"Effect": "Allow",
"Action": [
"s3:ListBucket",
"s3:GetBucketAcl",
"s3:GetBucketPolicyStatus",
"s3:GetBucketPublicAccessBlock",
"s3:GetBucketObjectLockConfiguration"
],
"Resource": [
"arn:aws:s3:::*"
]
},
{
"Sid": "AllowEventLogging",
"Effect": "Allow",
"Action": [
"logs:CreateLogStream",
"logs:DescribeLogGroups",
"logs:DescribeLogStreams",
"logs:CreateLogGroup",
"logs:PutLogEvents"
],
"Resource": "*"
},
{
"Sid": "ExportedDataAccess",
"Effect": "Allow",
"Action": [
"s3:GetBucketPublicAccessBlock",
"s3:GetBucketPolicyStatus",
"s3:GetBucketObjectLockConfiguration",
"s3:PutObject",
"s3:GetObject",
"s3:GetEncryptionConfiguration",
"s3:ListBucket",
"s3:GetBucketAcl",
"s3:DeleteObject"
],
"Resource": [
"arn:aws:s3:::*"
]
}
]
}
- This policy should be attached to an IAM role that is then attached to an EC2 instance or EKS cluster. Refer to AWS EC2 instances or AWS EKS clusters below for instructions on attaching the role.
Once the policy is created in Account A, further setup in Account B and Account C can be performed.
Target Accounts (Account B and Account C) Setup
You now need to create policies in the target account(s) that allow access to the buckets from the source account (Account A).
Create a bucket policy on the buckets in each target account to allow access from the specified role in Account A.
In this example, the bucket policy should be created in Account B and Account C.
The role that is given access is DM-Role (ARN arn:aws:iam::111111111111:role/DM-Role).
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "SourceBucketRead",
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::111111111111:role/DM-Role"
]
},
"Action": [
"s3:GetObject"
],
"Resource": [
"arn:aws:s3:::<bucket-name>",
"arn:aws:s3:::<bucket-name>/*"
]
},
{
"Sid": "SourceBucketPermissionCheck",
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::111111111111:role/DM-Role"
]
},
"Action": [
"s3:ListBucket*",
"s3:GetBucketAcl",
"s3:GetBucketPolicyStatus",
"s3:GetBucketPublicAccessBlock"
],
"Resource": [
"arn:aws:s3:::<bucket-name>",
"arn:aws:s3:::<bucket-name>/*"
]
},
{
"Sid": "DestinationBucketWrite",
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::111111111111:role/DM-Role"
]
},
"Action": [
"s3:PutObject",
"s3:GetObject*"
],
"Resource": [
"arn:aws:s3:::<bucket-name>",
"arn:aws:s3:::<bucket-name>/*"
]
},
{
"Sid": "DestinationBucketSecurityCheck",
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::111111111111:role/DM-Role"
]
},
"Action": [
"s3:ListBucket*",
"s3:GetBucketAcl",
"s3:GetBucketPolicyStatus",
"s3:GetBucketObjectLockConfiguration"
],
"Resource": [
"arn:aws:s3:::<bucket-name>",
"arn:aws:s3:::<bucket-name>/*"
]
},
{
"Sid": "AllowSSLRequestsOnly",
"Effect": "Deny",
"Principal": "*",
"Action": "s3:*",
"Resource": [
"arn:aws:s3:::<bucket-name>",
"arn:aws:s3:::<bucket-name>/*"
],
"Condition": {
"Bool": {
"aws:SecureTransport": "false"
}
}
}
]
}
- Replace the
111111111111account ID with the actual account ID of your source account (Account A in this example). - The role name
DM-Roleshould be replaced with the role name chosen.- If using EKS, the role name is set when executing the
eksctl create iamserviceaccountcommand, e.g.eks-datamasque-sa-role.
- If using EKS, the role name is set when executing the
- The role must exist before creating the bucket policy.
<bucket-name>should be replaced with the name of the bucket you are providing access to.
Remember that access won't be available until roles are created and assigned to the DataMasque instances, please continue reading below for more information.
Using Assume Role
For S3 file connections, using AWS Assume Role is possible.
With AWS Assume Role, DataMasque is able to grant itself temporary access credentials to S3 buckets for file masking.
This section presents a guide on enabling access to S3 buckets created in remote AWS accounts using cross account IAM roles. We will use the following example scenario to demonstrate this functionality.
Scenario
You have deployed DataMasque on an EC2 or an EKS cluster in Account A and you want to allow DataMasque to access one or more buckets in Account B and/or Account C.
Figure 2.0 gives an overview of how this access is enabled.
Figure 2.0
To effectively manage cross-account access control and audit S3 object permissions, we will utilise cross account IAM roles in AWS Accounts where S3 buckets reside and another IAM Role in the AWS Account where DataMasque has been deployed on EKS or EC2. The following table shows how we refer to these accounts and resources in the instructions below:
The IAM ARNs/Names mentioned in this document are for illustration purposes only. Please change it to the actual IAM Role ARNs in the source and target AWS accounts based on naming policies.
| Account Name | Account ID | IAM Policy | IAM Role | Description |
|---|---|---|---|---|
| Account A | 1111-1111-1111 | Source-DM-Policy | Source-DM-Role | DataMasque is deployed on an EC2 or EKS instance in this account. |
| Account B | 2222-2222-2222 | Target-DM-Policy (Cross Account) | Target-DM-Role (Cross Account) | This account has an S3 bucket to be accessed by the DataMasque instance in Account A. |
| Account C | 3333-3333-3333 | Target-DM-Policy (Cross Account) | Target-DM-Role (Cross Account) | This account has an S3 bucket to be accessed by the DataMasque instance in Account A. |
Account A Setup
In Account A, perform the following setup:
- Set up an IAM role named Source-DM-Role within Account A, with the EC2 service trusted. Attach this role to either the EC2 instance or the EKS cluster hosting the DataMasque instance. Also, create an IAM policy with the specified permissions and link it to the Source-DM-Role.
Note: The policy allows
sts:AssumeRolepermission for target roles in two accounts. If needed for multiple accounts, consider using*instead of individual Account ID numbers.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": ["arn:aws:iam::222222222222:role/Target-DM-Role",
"arn:aws:iam::333333333333:role/Target-DM-Role"
]
}
]
}
- Attach this Source-DM-Role IAM role created in to EC2 instances where the DataMasque application is running.
Target Accounts (Account B and Account C) Setup
Create an IAM role called Target-DM-Role with the trust policy defined below attached to it.
Note: This trust policy restricts the
sts:AssumeRoleaction to the IAM role Source-DM-Role created in the account where DataMasque is deployed.{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::111111111111:role/Source-DM-Role" }, "Action": "sts:AssumeRole" } ] }Create an IAM policy with following permissions and attach it to the Target-DM-Role IAM role:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "BucketPermissionCheck",
"Effect": "Allow",
"Action": [
"s3:ListBucket",
"s3:GetBucketAcl",
"s3:GetBucketPolicyStatus",
"s3:GetBucketPublicAccessBlock",
"s3:GetBucketObjectLockConfiguration"
],
"Resource": ["arn:aws:s3:::<source-bucket-name>","arn:aws:s3:::<target-bucket-name>"]
},
{
"Sid": "BucketReadWrite",
"Effect": "Allow",
"Action": [
"s3:PutObject",
"s3:GetObject"
],
"Resource": ["arn:aws:s3:::<source-bucket-name>/*","arn:aws:s3:::<target-bucket-name>/*"]
}
]
}
If the bucket's contents are encrypted using a custom KMS key then the IAM role will need the following KMS permissions in addition to the S3 permissions defined above:
{
"Effect": "Allow",
"Action": [
"kms:Decrypt",
"kms:Encrypt",
"kms:GenerateDataKey"
],
"Resource": "arn:aws:kms:region:account-id:key/key-id"
}
- Attach the IAM policy created in step 2 to the IAM role created in step 1.
Before updating your DataMasque target S3 file connection config, it is recommended to test these new delegated access policies in the AWS IAM policy simulator to confirm that the policies work as expected.
Updating File Connections to Use Assume Role
Specifying the AWS Role ARN for any DataMasque S3 File Connection is easy.
There are two approaches:
Through the DataMasque UI
- Navigate to the File Masking page.
- Either create a new File Connection or select Edit for an existing File Connection which you wish to update with an Assume Role ARN.
- Add the Assume Role ARN to the IAM Role ARN input box on the File Connection details.
- Select Test Connection to confirm the S3 File Connection works with the input IAM Role ARN.
- A green snackbar alert should appear confirming that it works.
- Select Save And Exit to ensure the S3 File Connection retains the Assume Role functionality.
Through the DataMasque API
To update an S3 File Connection config with an IAM Role ARN via the API, refer to the connection create API example.
You can simply add the "iam_role_arn" key value pair to the JSON request data when updating the connection config:
E.g.
{
"version": "1.0",
"name": "example-s3-connection",
…
"iam_role_arn": "arn:aws:iam::123456789012:role/example-role"
}
Note: The
…means that you must include any other relevant and already existing key-value pairs in the request JSON. This data has been omitted in the example to avoid redundancy.
If the "role_arn" key value pair is not added to the connection config,
DataMasque will attempt to connect to the S3 bucket without role assumption.