rajesh-bulleddula opened a new issue, #5123: URL: https://github.com/apache/polaris/issues/5123
### Is your feature request related to a problem? Please describe. Yes, Polaris currently mints credentials locally for federated external catalogs rather than returning credentials vended by the remote Iceberg REST catalog. In this model, local credential vending requires the central Polaris service to maintain storage configuration and have permission to assume storage roles for every remote catalog. For organizations with many independently managed business units, each operating its own storage environment, this model: - Broadens the central service’s trust boundary. - Requires the central service principal to have cross-account AssumeRole access into every business unit’s storage environment. In many regulated environments, this level of centralized cross-account access is not an approved security model because it conflicts with least privilege and business unit isolation requirements. ### Describe the solution you'd like Provide an administrator controlled federation mode that allows vended credentials returned by a remote Iceberg REST catalog to be passed back to the client. The central Polaris service remains authoritative for end user authentication and RBAC. The remote catalog remains responsible for storage integration and credential vending. **Expected flow**: - The client requests an operation and vended credentials from the central Polaris service. - The central service authenticates the user and authorizes the operation. - After authorization succeeds, the request is forwarded to the remote catalog. - The remote catalog returns table metadata and credentials scoped to its storage. - The central service returns those credentials without replacing them with locally generated credentials. **Requirements:** - Existing local credential vending remains the default. - Pass through must require explicit administrator enablement - Requests must be authorized by the central service before being forwarded. - The remote catalog returns vended credentials only for the authorized operation. - The central service should preserve the remote catalog’s credential response without needing its own storage configuration. - When pass through is enabled but the remote catalog cannot vend credentials, Polaris should return a clear error rather than silently falling back to local credential vending. - The feature should use Iceberg REST vended credential semantics and remain cloud neutral. ### Describe alternatives you've considered - Replicate every remote Iceberg REST catalog storage integration in the central catalog and continue having the central catalog issue all vended credentials - Have clients access remote catalogs directly - Propagate the end user identity to the remote catalog **Propagate the end user identity to the remote catalog** Trusted propagation of the authenticated end user identity would allow the remote catalog to independently evaluate user-specific policies and is a useful potential security model. However, it is not a prerequisite for the centrally authoritative model described here. In this model, the central catalog is intentionally the only end user RBAC authority, and the remote catalog scopes credentials based on the operation already authorized and forwarded by the central catalog. Identity propagation would require a larger design covering trusted delegation, identity mapping, claims and impersonation protection. It should therefore be considered as a follow-on enhancement. ### Additional context Related discussions: [GitHub Discussion #4929: Is STS Token Passthrough Supported in Polaris Federated Catalogs?](https://github.com/apache/polaris/discussions/4929) [Polaris dev mailing-list discussion: Is Vended Credentials Passthrough Supported in Polaris Federated Catalogs?](https://lists.apache.org/thread/b4t3y96nc80dcps1jyqwo913xwbokcmq) The mailing list discussion indicated that this is a reasonable use case and suggested evaluating it through a proof of concept, preferably behind an administrator enabled configuration flag. I am interested in contributing a proof of concept after confirming the expected behavior and configuration model with the community. -- 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]
