[EPIC] feat(credential): generalize WebIdentityTokenSource SPI for multi-cloud OIDC-federated credentials (S3 / OSS / GCS / Azure)
- 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
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