HIVE-29359: Support Credential Vending in Hive Iceberg REST Catalog Client#6474
HIVE-29359: Support Credential Vending in Hive Iceberg REST Catalog Client#6474difin wants to merge 6 commits into
Conversation
c092060 to
db520b9
Compare
db520b9 to
d3274be
Compare
d3274be to
d390532
Compare
d390532 to
f40686f
Compare
f40686f to
c9d71f5
Compare
c9d71f5 to
e50bbd2
Compare
9c2ac55 to
9a8b825
Compare
9a8b825 to
4c3214e
Compare
|
|
I think we are also missing executor-side credential refresh. In Trino AbstractIcebergRestVendedCredentialsProvider re-vends near expiry via client.refresh-credentials-endpoint. |
Switched to using Ozone instead of Minio. |
| * and s3g on a shared Docker network. S3G is reachable as {@link #S3_DOCKER_ALIAS}:{@link #S3G_PORT} | ||
| * from other containers (for example Gravitino) and via the published host port from the test JVM. | ||
| */ | ||
| public final class OzoneS3GatewayContainers { |
There was a problem hiding this comment.
should we move this to hive-it-util?
| /** Writes Hadoop S3A per-bucket keys only; Iceberg secrets are carried in the serialized blob. | ||
| * First table wins on a shared bucket, matching the non-secret entries, so an endpoint and its | ||
| * key always come from the same credential. */ | ||
| private static void addSecretCredentialEntry(String bucket, String icebergKey, String value, |
There was a problem hiding this comment.
seems format specific wonder if we should refactor? how do we even know what type of storage vended credentials are for?
is it possible to have some generic abstraction?
https://gravitino.apache.org/docs/1.3.0/security/credential-vending
There was a problem hiding this comment.
Agreed. Iceberg credential transport is already generic, we serialize/restore the StorageCredential list for Iceberg FileIO on executors. The S3-specific part is the Hadoop propagation (toS3aBucketProperty() / addSecretCredentialEntry()), which maps vended config to fs.s3a.bucket.* because Tez/LLAP still use Hadoop FileSystem for some s3:// paths.
This PR intentionally keeps that scope to S3 (Gravitino q-test + S3FileIO). Can we handle provider-aware propagation for GCS/ADLS/OSS in a follow-up, deriving storage type from StorageCredential.prefix() and mapping to the right Hadoop FS / Iceberg IO settings per provider?
deniskuzZ
left a comment
There was a problem hiding this comment.
+1, pending tests
in a follow-up we should probably test integration with Polaris and vended credentials from diff object store provider:
S3: S3TokenCredential, S3SecretKeyCredential
GCS: GCSTokenCredential
ADLS: ADLSTokenCredential, AzureAccountKeyCredential
OSS: OSSTokenCredential, OSSSecretKeyCredential



What changes were proposed in this pull request?
Extended Gravitino LLAP qtest (
TestIcebergRESTCatalogGravitinoLlapLocalCliDriver) to add a vended credentials header and run against MinIO + S3 warehouse with Gravitino s3-secret-key vending and OAuth2; configure host-side S3A and Iceberg S3FileIO for the published MinIO port so Tez/LLAP on the host work reliably.Updated Hive to pass vended credentials to executors using
jobPropertiesandjobSecretsand to set S3A properties in Hive Configuration for Hadoop.Why are the changes needed?
To enable vended credentials support with REST Catalog servers.
Does this PR introduce any user-facing change?
Yes. Users configuring an Iceberg REST catalog in Hive can set the header
iceberg.catalog.<name>.X-Iceberg-Access-Delegationon REST requests to enabled vended credentials.How was this patch tested?
Updated existing test with vended credentials testing:
TestHiveRESTCatalogClient: new unit tests for vended credentials header mapping.
TestIcebergRESTCatalogGravitinoLlapLocalCliDriver with Gravitino + MinIO + OAuth2 + credentials vending.