fivetran-ashokborra commented on PR #1424:
URL: https://github.com/apache/polaris/pull/1424#issuecomment-2847680150
I have listed all the approaches on top of my mind to make the policy
granular
### **Approach 1: Implicit Key ARN retrieval**
In this approach, the customer doesn't need to provide any key ARNs
explicitly. However, the role must have the `GetBucketEncryption` permission to
retrieve the active key ARN.
```
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyObjectsThatAreNotSSEKMS",
"Effect": "Deny",
"Action": [
"s3:PutObject"
],
"Resource": "arn:aws:s3:::bucket-name/prefix/*",
"Condition": {
"StringNotLike": {
"s3:x-amz-server-side-encryption-aws-kms-key-id":
"arn:aws:kms:region:account:key/key_id"
}
}
},
{
"Sid": "AllowUseOfKMS",
"Effect": "Allow",
"Action": [
"kms:GenerateDataKey",
"kms:Decrypt"
],
"Resource": "arn:aws:kms:region:account:key/*",
"Condition": {
"StringEquals": {
"aws:PrincipalArn":
"arn:aws:iam::account-id:role/specific-role-name"
},
"StringLike": {
"kms:EncryptionContext:aws:s3:arn":
"arn:aws:s3:::bucket-name/prefix/*"
}
}
},
{
"Sid": "KMSEncrypt",
"Effect": "Allow",
"Action": "kms:Encrypt",
"Resource": "arn:aws:kms:region:account:key/key_id",
"Condition": {
"StringEquals": {
"aws:PrincipalArn":
"arn:aws:iam::account-id:role/specific-role-name"
},
"StringLike": {
"kms:EncryptionContext:aws:s3:arn":
"arn:aws:s3:::bucket-name/prefix/*"
}
}
}
]
}
```
**Pros:**
- No need for the customer to explicitly provide the KMS key ARN.
**Cons:**
- The IAM policy may still grant decryption access to all KMS keys within
the account’s region.
- An additional step is required to fetch the active KMS key ARN
The region is implicitly inferred from the KMS key ARN
### **Approach 2: Explicit KMS Key ARN input**
This approach requires the customer to provide the KMS Key ARN as part of
the input.
```
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyObjectsThatAreNotSSEKMS",
"Effect": "Deny",
"Action": [
"s3:PutObject"
],
"Resource": "arn:aws:s3:::bucket-name/prefix/*",
"Condition": {
"StringNotLike": {
"s3:x-amz-server-side-encryption-aws-kms-key-id":
"arn:aws:kms:region:account:key/key_id"
}
}
},
{
"Sid": "AllowUseOfKMS",
"Effect": "Allow",
"Action": [
"kms:GenerateDataKey",
"kms:Decrypt"
],
"Resource": "arn:aws:kms:region:account:key/*",
"Condition": {
"StringEquals": {
"aws:PrincipalArn":
"arn:aws:iam::account-id:role/specific-role-name"
},
"StringLike": {
"kms:EncryptionContext:aws:s3:arn":
"arn:aws:s3:::bucket-name/prefix/*"
}
}
},
{
"Sid": "KMSEncrypt",
"Effect": "Allow",
"Action": "kms:Encrypt",
"Resource": "arn:aws:kms:region:account:key/key_id",
"Condition": {
"StringEquals": {
"aws:PrincipalArn":
"arn:aws:iam::account-id:role/specific-role-name"
},
"StringLike": {
"kms:EncryptionContext:aws:s3:arn":
"arn:aws:s3:::bucket-name/prefix/*"
}
}
}
]
}
```
**Pros:**
- Eliminates the need for `GetBucketEncryption` permission to retrieve the
active KMS Key ARN.
**Cons:**
- The IAM policy may still allow decryption access to all KMS keys within
the account’s region.
- Customers are responsible for updating the catalog if the KMS key changes
- The KMS Key ARN must be stored in the entities table.
### Approach 3: Explicit Key ARN Input with Fine-Grained Control
This approach involves storing all relevant KMS Key ARNs in the table.
```
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowUseOfKMS",
"Effect": "Allow",
"Action": [
"kms:GenerateDataKey",
"kms:Decrypt",
"kms:Encrypt"
],
"Resource":
["arn:aws:kms:region:account:key/key_id1","arn:aws:kms:region:account:key/key_id2","arn:aws:kms:region:account:key/key_id3"],
"Condition": {
"StringEquals": {
"aws:PrincipalArn":
"arn:aws:iam::account-id:role/specific-role-name"
},
"StringLike": {
"kms:EncryptionContext:aws:s3:arn":
"arn:aws:s3:::bucket-name/prefix/*"
}
}
}
]
}
```
**Pros:**
- IAM policy grants access only to the specific keys required.
**Cons:**
- Customers are responsible for updating the catalog if the KMS key changes
- Persist all key changes over time.
### Approach 4: Region-Wide Key Access
This approach takes the region as input from the customer and grants access
to all KMS keys within that region
```
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowUseOfKMS",
"Effect": "Allow",
"Action": [
"kms:GenerateDataKey",
"kms:Decrypt",
"kms:Encrypt"
],
"Resource": "arn:aws:kms:region:account:key/*",
"Condition": {
"StringEquals": {
"aws:PrincipalArn":
"arn:aws:iam::account-id:role/specific-role-name"
},
"StringLike": {
"kms:EncryptionContext:aws:s3:arn":
"arn:aws:s3:::bucket-name/prefix/*"
}
}
}
]
}
```
**Pros:**
- Simplified policy requiring minimal customer input.
**Cons:**
- Broad policy grants access to all keys within a region.
I believe Approach 4 is more aligned with Polaris’s use case, even though it
involves broader access by allowing permissions to all KMS keys within a
region. Here are my thoughts:
- In practice, customers typically grant KMS key access only to specific
users and roles.
- S3 uses [Forward Access Sessions
(FAS)](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_forward_access_sessions.html)
to handle encryption and decryption. As a result, explicit KMS permissions are
often not required for the calling application.
- However, S3 doesn’t expose APIs to retrieve previously used KMS Key ARNs.
To determine which keys were used, we would need to list all objects, extract
their metadata, and infer the keys—an inefficient and complex process.
Meanwhile, Approaches 2 and 3 introduce additional maintenance overhead, and
Approach 1 requires elevated permissions (`GetBucketEncryption`), which may not
always be feasible.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@polaris.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
