netapp-acheng commented on issue #3440: URL: https://github.com/apache/polaris/issues/3440#issuecomment-3769717881
Hi team, I want to clarify why PR #3445, if merged as‑is, will actually break S3 write‑paths for any catalog configured with STS + AssumeRole, even if it fixes the KMS inline‑policy issue. Root problem (not addressed by PR‑3445) With an STS-enabled catalog, Polaris correctly calls AssumeRole and obtains temporary STS credentials (AccessKey + SecretKey + SessionToken). Polaris must use those temporary credentials for all subsequent S3 operations. Here’s what currently happens: Table creation works When creating the table, Polaris correctly uses the STS temporary credentials to PUT metadata.json — this succeeds. Data inserts fail (using PR #3445) During INSERT, Polaris does not reuse the temporary STS credentials. Instead, it falls back to the original static AWS access key + secret key, which were intended only for acquiring the STS token. Since these static credentials do not have direct S3 access, the data file PUT fails with: 403 AccessDenied. PR‑3445 does not touch this credential path The PR removes KMS actions (because it is NOT using AssumeRole inline policy, it is using static AWS access key + secret key), but the S3 FileIO layer continues using the wrong credentials. That means after merging PR‑3445, STS catalogs will still fail on data writes. What the correct fix needs to include Polaris must continue using the STS temporary credentials (including the SessionToken) for all S3 I/O: metadata files manifest files data files deletes / updates When allowedKmsKeys is empty: Do not add any KMS actions to the inline STS policy But still return STS temporary credentials, and Polaris must keep using them Right now, STS credentials are used only during table creation, and then silently discarded — causing the insert‑path breakage. Summary The fix cannot be limited to removing KMS actions. The core bug is that Polaris stops using STS temporary credentials after table creation and reverts to the static key, causing 403 failures during data inserts. PR‑3445 does not address this, so merging it alone will still result in broken STS catalogs. -- 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: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
