Hi Anand, I think WIF is probably the right direction for guaranteed GCS audit attribution, because it puts the Polaris principal into the identity chain instead of depending on client forwarded headers. I'm not an expert with GCS though, I'm open to alternatives.
My main concern is the operational and performance cost. With attribution enabled, the cache becomes effectively principal scoped, so the real cost is likely cache fragmentation rather than the extra STS call itself, as the STS call could be cached. Currently, the cache keys explicitly do *NOT* include principal/context for GCS, so they are not principal-scoped: GcpStorageCredentialCacheKey.java (line 31), AzureStorageCredentialCacheKey.java (line 30). It would be good to quantify this with the expected credential vending frequency, token TTL, and number of active principals. I would also prefer making this clearly optional and well documented, since not every deployment needs principal level GCS audit attribution. Yufei On Thu, Jun 11, 2026 at 9:22 AM Anand Kumar Sankaran via dev < [email protected]> wrote: > https://github.com/apache/polaris/issues/4706 > > https://github.com/apache/polaris/pull/4707 > > Polaris can correlate vended-credential data access back to the catalog > operation that issued the credentials on AWS — via > SESSION_TAGS_IN_SUBSCOPED_CREDENTIAL, which stamps polaris:principal, > polaris:realm, polaris:catalog, etc. as AWS STS session tags that then > appear in CloudTrail S3 data events. There is no equivalent on GCP. GCS > Data Access audit logs cannot today be tied to the Polaris principal that > requested the credential, which breaks audit correlation, > chargeback/attribution, and incident response for GCS-backed catalogs. > > This issue and PR provide a way to achieve similar correlation using WIFs > in GCP. > > Please review. > > - > Anand >
