[Feature] Access table data with the temporary credentials issued by the REST catalog
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 30/100
Research direction
Start by tracing Catalog::GetTableFileSystem, ReadContextBuilder, ScanContextBuilder, WriteContextBuilder, and CredentialProviderFactory::Get to understand the existing catalog and file-system extension points. Done means data-token.enabled remains backward-compatible, table credentials refresh independently before expiry, the builder and provider APIs work, and static built-in file-system credentials remain unchanged.
Written by the indexing model from the issue text.
Description
Search before asking
- I searched in the issues and found nothing similar.
Motivation
The C++ REST catalog can only read and write table data with the static credentials configured in the catalog options (fs.oss.accessKeyId and friends). A REST catalog that issues per-table temporary credentials (data tokens, e.g. DLF) has no way to have those credentials used for that table's data IO, and no way to keep them fresh before they expire. Callers that bring their own FileSystem also have no supported abstraction for sourcing credentials that expire.
Solution
Add data-token support to the REST catalog: when data-token.enabled=true, the catalog loads a table's temporary credentials and serves a refreshing FileSystem for that table through Catalog::GetTableFileSystem(identifier). ReadContextBuilder, ScanContextBuilder and WriteContextBuilder gain WithCatalog(catalog, identifier) so the table's schema and file system are resolved from the catalog in one call. The credentials are cached and reloaded before expiry by rebuilding the delegate file system keyed by the issued token, so a rotation of one table's credentials does not disturb the others.
Also add a generic CredentialProvider + CredentialProviderFactory extension point: a caller that brings its own FileSystem builds a provider with CredentialProviderFactory::Get and consults GetCredentials() at each access, then passes that file system in through Catalog::Create or a builder's WithFileSystem. The built-in file systems (oss, s3, local, jindo) keep signing with the static credentials of their own options.
Anything else?
data-token.enabled defaults to false, and the new API is additive, so the change is backward compatible.
Are you willing to submit a PR?
- I'm willing to submit a PR!
- Dominant language
- C++
- Stars
- 65
- Forks
- 29
- Avg merge
- 2d 30m
- Merged PRs (30d)
- 77
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from apache/paimon-cpp
-
enhancement
apache/paimon-cpp#381 · 1 assignee ·
-
Difficulty 4/5 3-5 days Newbie friendliness 30/100
apache/paimon-cpp#375 · 1 assignee ·
-
enhancement
Difficulty 5/5 Over a week Newbie friendliness 45/100
apache/paimon-cpp#361 · 1 assignee ·
-
bug
Difficulty 4/5 3-5 days Newbie friendliness 68/100
apache/paimon-cpp#347 · 1 assignee ·
-
enhancement
Difficulty 4/5 3-5 days Newbie friendliness 45/100
apache/paimon-cpp#325 · 1 assignee ·
All issues in apache/paimon-cpp
Similar issues
-
Difficulty 1/5 Under an hour Newbie friendliness 90/100
AXERA-TECH/ax-llm#77 ·
-
Difficulty 1/5 Under an hour Newbie friendliness 90/100
games-on-whales/wolf#509 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
-
bug-unconfirmed
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
NVIDIA/cuda-samples#453 ·