Thanks for working on this, I Ting! I think the PR is moving in the right direction.
I asked for a discussion on the dev mailing list mainly because this requires a REST spec change. I just wanted to bring it to the community's attention and see if anyone has compatibility concerns before we move forward. Yufei On Tue, Jul 28, 2026 at 8:34 AM ITing Lee <[email protected]> wrote: > Hello all, > > > I would like to request feedback on a proposed change for historical AWS > > KMS keys. > > > Issue: #3338[1] > > PR: #5192[2] > > > Currently, every explicitly configured KMS key receives encryption > > permissions when Polaris vends write capable credentials. During key > > rotation, this allows an older key retained for reading existing data to > > also be used for new writes. > > > The proposal adds `legacyKmsKeys` to AWS catalog storage configuration: > > > * `allowedKmsKeys` receive encrypt, decrypt, and data-key generation > > permissions for write-capable credentials. > > * `legacyKmsKeys` receive only kms:DescribeKey and kms:Decrypt. > > * `currentKmsKey` is deprecated in favor of allowedKmsKeys, while retaining > > its existing behavior for compatibility. > > > The configuration rejects keys that appear in both `legacyKmsKeys` and an > > encrypt-capable category. This is necessary because AWS combines > > permissions from applicable Allow statements, so overlapping entries > > would restore encryption permissions to a legacy key. > > > A typical rotation would move the previous key from `allowedKmsKeys` to > > `legacyKmsKeys` after new writes have switched to the replacement key. > > > > I would appreciate feedback on this PR. > > > [1] https://github.com/apache/polaris/issues/3338 > > [2] https://github.com/apache/polaris/pull/5162 > > > > Thanks, > > I-Ting >
