HonahX opened a new pull request, #2736:
URL: https://github.com/apache/polaris/pull/2736
<!--
Possible security vulnerabilities: STOP here and contact
[email protected] instead!
Please update the title of the PR with a meaningful message - do not
leave it "empty" or "generated"
Please update this summary field:
The summary should cover these topics, if applicable:
* the motivation for the change
* a description of the status quo, for example the current behavior
* the desired behavior
* etc
PR checklist:
- Do a self-review of your code before opening a pull request
- Make sure that there's good test coverage for the changes included in
this PR
- Run tests locally before pushing a PR (./gradlew check)
- Code should have comments where applicable. Particularly
hard-to-understand
areas deserve good in-line documentation.
- Include changes and enhancements to the documentation (in
site/content/in-dev/unreleased)
- For Work In Progress Pull Requests, please use the Draft PR feature.
Make sure to add the information BELOW this comment.
Everything in this comment will NOT be added to the PR description.
-->
## Overview
This PR extracts credential vending entrypoint `getAccessConfig` from
IcebergCatalog into a new centralized `AccessConfigProvider` class, decoupling
credential generation from catalog implementations.
## Motivation
When implementing credential vending for catalog federation, the current
model proved difficult to extend. The existing approach models credential
vending similar to Iceberg's capability interfaces (SupportsNamespace,
ViewCatalog) using inheritance to determine whether a catalog possesses certain
functionality.
This inheritance-based approach works well for Iceberg-native interfaces
like SupportsNamespace because:
- The interface is defined in the upstream Iceberg SDK
- All catalog implementations naturally follow the upstream contract
However, for SupportsCredentialDelegation:
- It's a Polaris-specific interface, not part of upstream Iceberg
- External/federated catalogs won't naturally implement this
Polaris-specific interface
- We only perform check in one place in `IcebergCatalogHandler`
- The "get subscoped credential" is not a standard API defined in our
catalog spec
The inheritance approach provides that much value in this case.
Additionally, as outlined in our [federation design
doc](https://docs.google.com/document/d/19Vm0Uy-EyEYtgd2-bZpPICODOB3rYQJvHeqL1ODOOLc/edit?disco=AAABndOGNsU),
we plan to make getAccessConfig a unified entry point for all storage access.
Extracting this logic to a shared service prepares the codebase for that
unification.
I considered introducing a wrapper class (e.g.,
CredentialVendingCatalogWrapper) to add credential vending capability to
external catalogs. However, IcebergCatalogHandler already serves as an adapter
layer between REST APIs and catalog implementations (both internal and
federated). Adding another wrapping layer would over-complicate the
architecture with minimal benefit, especially since the capability check
happens in only one location.
--
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]
