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