apache / apache/gravitino

[EPIC] feat(credential): generalize WebIdentityTokenSource SPI for multi-cloud OIDC-federated credentials (S3 / OSS / GCS / Azure)

Open
#11,758 0 comments 0 reactions 0 assignees View on GitHub
epic
Dominant language
Java
Stars
3.2k
Forks
935
Avg merge
1d 15h
Merged PRs (30d)
315

Description

### Background

#11735 added a `WebIdentityTokenSource` SPI (OIDC token -> AWS STS `AssumeRoleWithWebIdentity`) scoped to AWS S3 under `bundles/aws`. The token-sourcing part (obtain an OIDC token from a file/OAuth/etc.) is cloud-agnostic; only the credential-exchange step is cloud-specific. Workload-identity / OIDC federation is a common K8s deployment pattern across clouds, and only AWS supports it in Gravitino today. This EPIC tracks generalizing the SPI and adding OIDC-federated credential paths for the other object stores.

### Subtasks

1. **Lift the token-source SPI into a shared module** — move `WebIdentityTokenSource` / `FileWebIdentityTokenSource` / `WebIdentityTokenSources` / config + `META-INF/services` from `bundles/aws` to `common/.../credential/webidentity`; make config keys storage-neutral or parameterizable (currently hardcoded `s3-*`); update `AwsIrsaCredentialGenerator` imports. Pure refactor, no behavior change.
2. **Alibaba OSS** — `OssOidcCredentialGenerator` via Aliyun STS `AssumeRoleWithOIDC` + OSS session-policy, reusing the shared token source.
3. **GCS** — Workload Identity Federation: exchange the OIDC token at `sts.googleapis.com` (+ optional service-account impersonation), combined with the existing Credential Access Boundary downscoping.
4. **Azure (ADLS/Blob)** — Workload Identity: exchange the federated OIDC token via OAuth2 `client_assertion` for an AAD token, combined with the existing User Delegation SAS scoping.

### Notes

- Subtask 1 is a small, low-risk refactor; 2-4 are per-cloud and cannot be unified (each cloud's exchange API/SDK/policy format differs).
- Tencent COS is intentionally out of scope for now (no `bundles/tencent` exists yet; can be a follow-up EPIC).
- Each per-cloud subtask should be validated against actual user demand before implementation.

Contributor guide

Open the contributing guide

Research direction

This is an EPIC, so begin with subtask 1: inspect WebIdentityTokenSource, FileWebIdentityTokenSource, WebIdentityTokenSources, the config, and META-INF/services under bundles/aws, then compare the target common/.../credential/webidentity location and AwsIrsaCredentialGenerator imports. Done for that subtask means a shared, storage-neutral or parameterizable SPI with no behavior change; the OSS, GCS, and Azure exchanges remain separate follow-up work.

Written by the indexing model from the issue text.

Assessment

Tech stack
aws, azure, google-cloud, java
Domain
authentication, cloud, security
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.