markhoerth opened a new pull request, #12165:
URL: https://github.com/apache/gravitino/pull/12165
### What changes were proposed in this pull request?
Rewrites `docs/security/credential-vending.md` and fixes
`docs/iceberg-rest-engine/trino.md`.
**docs/security/credential-vending.md**
- Restructure around where credential vending properties are set. The two
property columns held the same setting twice, differing only by a
`gravitino.iceberg-rest.` prefix, so they collapse to one column plus a single
stated rule.
- Add a quick start showing a working catalog and engine configuration.
- Add the IAM trust and permission policies for `s3-token`, and the
equivalent role requirements for `oss-token`, `adls-token`, and `gcs-token`.
- Correct provider auto-detection. `s3-role-arn` does not select `s3-token`.
`BaseCatalog.addStorageCredentialProviders` never inspects the role ARN, so a
catalog with the key pair and a role ARN but no explicit `credential-providers`
falls back to `s3-secret-key`.
- Remove `azure-storage-account-key` from `adls-token`.
`ADLSTokenGenerator.initialize` reads only `storageAccountName`, `tenantId`,
`clientId`, and `clientSecret`.
- Correct the Iceberg GCP and Aliyun bundle links, which pointed at each
other's artifacts.
- Correct `credential-cache-max-size`. The right-hand column gave
`gravitino.iceberg-rest.cache-max-size`; `CredentialConstants` defines
`credential-cache-max-size`, so the prefix rule holds with no exception.
- Cover the Iceberg, Hive, Glue, and Paimon catalog classpaths in
Deployment, which previously covered only the Iceberg REST server and Fileset.
- State that `s3-secret-key`, `oss-secret-key`, and `azure-account-key`
return the configured long-lived key to the client.
**docs/iceberg-rest-engine/trino.md**
- Add `iceberg.rest-catalog.vended-credentials-enabled` and
`iceberg.rest-catalog.prefix`. Neither appeared anywhere in the docs, while the
page's comparison table advertised credential vending.
- Separate storage credentials from authentication so vended credentials can
be configured without static keys. Every previous example set static S3 keys.
- Warn that `s3.aws-access-key` and `s3.aws-secret-key` silently override
vended credentials, so queries succeed while vending is not in use.
- Scope the access control and credential vending claims in the comparison
table to what applies.
### Why are the changes needed?
The credential vending page carried four factual errors. The most
consequential is provider auto-detection: the page states that `s3-role-arn`
enables the `s3-token` provider. It does not. A catalog configured with the
access key pair and a role ARN, but without an explicit `credential-providers`,
falls back to `s3-secret-key` and vends the long-lived access key. Users
following the current page believe they have scoped STS credentials and are
shipping permanent ones to every engine that loads a table.
The Trino page advertised credential vending in its comparison table while
never documenting `vended-credentials-enabled`, and set static S3 keys in all
four of its configuration examples. Those keys cause Trino to ignore vended
credentials while queries continue to succeed, so the setup appears correct and
no vending occurs.
### Does this PR introduce _any_ user-facing change?
Documentation only. No API or property changes.
### How was this patch tested?
Docs build.
Behavioral claims were checked against `BaseCatalog`, `CredentialUtils`,
`CredentialConfig`, `CredentialConstants`, `ADLSTokenGenerator`, and the
catalog `build.gradle.kts` copy tasks.
The documented Trino configuration was verified end to end against Gravitino
1.3.0 with AWS S3: Spark wrote an Iceberg table and Trino 478 read it back
through the Iceberg REST endpoint using vended STS credentials, with OAuth2
client-credentials authentication and authorization enabled.
Not verified, and flagged for review: the Azure role names for `adls-token`,
the GCS role for `gcs-token`, the Alibaba RAM policy syntax for `oss-token`,
and whether the Hive and Glue catalogs take `gravitino-{cloud}` or the
`-bundle` variant. These follow each vendor's documented model and the Paimon
precedent, but were not confirmed against a running deployment.
--
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]
