netapp-acheng commented on issue #3440:
URL: https://github.com/apache/polaris/issues/3440#issuecomment-3774359822
I ran additional tests today to see whether omitting the --region option
during catalog creation would avoid the residual KMS behavior described in this
issue.
Test setup: I created a new S3 catalog without specifying --region:
"storageConfigInfo": {
"storageType": "S3",
"allowedLocations": ["s3://sts2-polaris"],
"roleArn": "arn:aws:iam::<acct>:role/assumerole",
"currentKmsKey": null,
"allowedKmsKeys": [],
"region": null,
"endpoint": "https://sgdemo.example.com";,
"stsEndpoint": "https://sgdemo.example.com";
}
Results
Spark can list namespaces and create tables
The catalog loads correctly and Polaris vends temporary STS credentials
during table creation, just like before.
Spark INSERT still fails
INSERT INTO sts2_catalog.ns1.table1 VALUES (1,'alpha'), …
Failed with S3Exception: Access Denied (403)
On the S3 object storage server side, I can see that Polaris sends the data
file PUT using the static AWS access key, not the temporary STS credentials.
This is the same failure mode we saw before Jan 19: INSERT falls back to the
long‑lived IAM credentials instead of using vended STS credentials.
So even with region=null, Polaris still does not use the temporary
AssumeRole credentials during data writes.
Conclusion
Removing the --region field does not fix the problem, and it does not
disable KMS.
This confirms that the underlying issue remains in the policy‑generation
logic (addKmsKeyPolicy) and not in how the catalog is configured.
--
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]
