Thanks I-ting for your patience. I did another round of review. I think PR 5162 is in good shape. I suggest merging it once the CI is happy.
Yufei On Mon, Aug 10, 2026 at 12:03 PM Dmitri Bourlatchkov <[email protected]> wrote: > Hi I-ting, > > Thanks for working on this issue! I posted my review in GH. > > Cheers, > Dmitri. > > > On Tue, Jul 28, 2026 at 11: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 > > >
