Hey Prashant, Thank you for kicking off this discussion! Some thoughts:
> The current PR advocates for including KMS credentials within the storage credentials object. This isn't true - the KMS client is currently configured with just the catalog config client-side (though that includes the server's `getConfig` response) [1]; there is no per-table vending of KMS credentials as such. > Separation of KMS/Vault Creds from Storage Creds I agree, if/when it supports this, the AWS KMS client could choose to introduce `kms.access-key-id` and co. instead of reusing `s3.access-key-id` and co. (similar to how we have `rest.access-key-id` and co. [2]) to differentiate from storage credentials. And similarly for vending: if we'd like to support the vending of KMS credentials [3], we can discuss its format to enable separation. (Specifically on the current PR [4], I don't think that the concerns described affect it due to my first point above. I think catalog-initialised KMS clients, as implemented, are useful to support now and in the future.) Thanks, Sreesh Maheshwar [1] https://github.com/apache/iceberg/pull/13225/files#diff-86450612dbe323d6d06cbc3846aa1913f042eaedadc0ca027c36bfbe08d3a46cR284 [2] https://github.com/apache/iceberg/blob/2d54125734ddc9b9fb87db147ff255918108fa2c/aws/src/main/java/org/apache/iceberg/aws/AwsProperties.java#L193 [3] https://github.com/apache/iceberg/issues/16194 [4] https://github.com/apache/iceberg/pull/13225 >
