whua3 opened a new pull request, #12199: URL: https://github.com/apache/gravitino/pull/12199
### What changes were proposed in this pull request? Add credential vending support for the Tencent Cloud COS fileset backend introduced in #11713. This is a follow-up subtask under #6490. - Add `COSTokenCredential` to the public credential API, alongside the existing `S3TokenCredential`, `OSSTokenCredential`, `GCSTokenCredential`, and `ADLSTokenCredential`. - Add `cos-token` credential provider implementation (`COSTokenProvider` + `COSTokenGenerator`) that calls Tencent Cloud STS `AssumeRole` and returns temporary credentials scoped to the requested table path via a generated CAM policy. - Add lightweight CAM policy model classes (`Policy`, `Statement`, `Effect`, `Condition`, `StringLike`) shared by the token generator and covered by unit tests. - Reuse the existing `cos-secret-key` provider so the two providers share the same `cos-access-key-id` / `cos-secret-access-key` configuration surface. - Register both providers via `META-INF/services` so they are picked up by `CredentialProviderFactory` and by `CredentialFactory` on the client side. - Wire `COSCredentialsProvider` (the Hadoop `AWSCredentialsProvider`) to consume vended `COSTokenCredential`s, in addition to the static secret-key credential. - Update `bundles/tencent` and `bundles/tencent-bundle` to include the new sources and the Tencent STS SDK dependency. - Update `CredentialConstants`, `COSCredentialConfig`, and `COSProperties` to expose the new provider name and configuration keys (`cos-role-arn`, `cos-region`, `cos-app-id`, `cos-external-id`, `cos-token-expire-in-secs`). Tests: - Unit tests for `COSTokenGenerator`, `COSCredentialConfig`, `COSCredentialProvider` SPI registration, and `TestCredentialFactory` round-trip. - Integration test `GravitinoVirtualFileSystemCOSCredentialIT` exercising the end-to-end vending path against a real COS bucket through GVFS. Documentation: - Add a `## COS` section to `docs/security/credential-vending.md`, documenting `cos-token` and `cos-secret-key`, their properties, and the required CAM trust and permission policies. - Update `docs/fileset-catalog-with-cos.md` with credential-vending configuration examples. ### Why are the changes needed? #11713 added COS as a fileset storage backend but only supported the static access-key path. Without credential vending, every client that loads a fileset receives long-lived, coarse-grained Tencent Cloud credentials, which is inconsistent with how Gravitino already handles S3, OSS, GCS, and ADLS. This PR closes that gap so COS fileset deployments can hand out temporary, table-scoped STS credentials. ### Does this PR introduce _any_ user-facing change? Yes. Two new credential providers, `cos-token` and `cos-secret-key`, are now available for catalogs using the COS storage backend, together with the associated `cos-role-arn` / `cos-region` / `cos-app-id` / `cos-external-id` / `cos-token-expire-in-secs` catalog properties. Existing catalogs continue to work unchanged. ### How was this patch tested? - New unit tests under `bundles/tencent` and `catalogs/catalog-common`. - New integration test `GravitinoVirtualFileSystemCOSCredentialIT` run locally against a Tencent Cloud COS bucket with an assumable CAM role, covering both read and write paths through GVFS with vended credentials. Fix: #12198 Related: #6490, #11713, #11748 -- 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]
