Hi Yong,

Thanks for your diligent debugging of this issue!

>From my POV (as I commented in GH) we should probably define a new flag in
Stogate Config (at Catalog Level):

"addKmsWildcardsOnRead" - defaulting to `true` if no explicit endpoints are
set (which is often the case for AWS S3).

I believe these defaults should be fairly backward compatible for existing
use cases.

If defaults do not work well in some special circumstances, the admin user
will be able to adjust catalog config via the Admin REST API.

WDYT?

Thanks,
Dmitri.





On Tue, Jan 20, 2026 at 10:43 PM Yong Zheng <[email protected]> wrote:

> Hello all,
>
> While working on https://github.com/apache/polaris/issues/3440, I noticed
> the way on how we are currently determining whether a S3-compatible storage
> is a bit odd where we are determining this by checking if a region property
> of catalog and account id of IAM role are being set. Now back to the
> reported issue, where the reporter is using assuming role with an
> S3-compatible backend without KMS and a catalog region property was set (as
> we didn't mention this anywhere). By doing so, it falls back to the
> wildcard KMS policy which is not valid for certain S3-compatible storage (I
> am assuming the reporter is using MinIO or something equivalent).
>
> In this case, both account id and region are set but they are actually
> valid settings (but according to the code, the comment said it should not
> be valid:
> https://github.com/apache/polaris/blob/0b54f7046295ff19d434f9f0bd47b0b612be51a5/polaris-core/src/main/java/org/apache/polaris/core/storage/aws/AwsCredentialsStorageIntegration.java#L294
> ).
>
> I think it may be better to determine is a S3-compatible storage is AWS or
> not by looking at endpoint URL instead (sample PR:
> https://github.com/apache/polaris/pull/3496). Let me know what your guys
> think.
>
> Thanks,
> Yong Zheng
>

Reply via email to