obelix74 commented on code in PR #4707:
URL: https://github.com/apache/polaris/pull/4707#discussion_r3425667845
##########
polaris-core/src/main/java/org/apache/polaris/core/config/FeatureConfiguration.java:
##########
@@ -209,6 +209,64 @@ public static void enforceFeatureEnabledOrThrow(
.defaultValue(List.<String>of())
.buildFeatureConfiguration();
+ //
---------------------------------------------------------------------------
+ // GCS principal attribution via Workload Identity Federation
+ //
+ // GCP downscoped credentials have no session-tag mechanism (unlike AWS
STS), and custom audit
+ // headers only reach GCS audit logs if the client forwards them. To
attribute GCS data access
+ // to the Polaris principal for ANY client, credential vending can chain
+ // catalog-signed JWT -> STS token exchange -> per-catalog service-account
impersonation, so the
+ // principal appears in serviceAccountDelegationInfo of every GCS Data
Access audit log entry.
+ //
+ // Attribution activates automatically once the audience, issuer, and
signing key file are all
+ // set (no on/off flag); it additionally requires a gcpServiceAccount on the
storage config.
+ //
---------------------------------------------------------------------------
+
+ public static final FeatureConfiguration<String>
GCS_PRINCIPAL_ATTRIBUTION_WIF_AUDIENCE =
Review Comment:
The WIF signing infrastructure (signing key, issuer, WIF pool audience) is
naturally a deployment-level concern — Polaris uses a single RSA key to sign
all attribution JWTs regardless of which catalog the token is for. The
per-catalog variation is handled entirely by `gcpServiceAccount` on the
`StorageConfiguration`: each catalog's service account can live in a different
GCP project, and GCP STS will impersonate it regardless of which project hosts
the WIF pool. So a single WIF pool (single audience) can serve catalogs across
multiple GCP projects as long as each SA has the WIF service account binding.
The limit would be a case where different catalogs need *different WIF
pools* (e.g. isolated orgs with separate OIDC trust configs) — that is not
supported today. If that is a real concern, happy to explore moving
`WIF_AUDIENCE` to `StorageConfiguration` in a follow-up, but I would lean
toward keeping it deployment-level for now since the common multi-project
scenario is covered by the per-SA impersonation.
--
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]
