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

Reply via email to