Skip to content

HIVE-29359: Support Credential Vending in Hive Iceberg REST Catalog Client#6474

Open
difin wants to merge 6 commits into
apache:masterfrom
difin:vended_credentials_client
Open

HIVE-29359: Support Credential Vending in Hive Iceberg REST Catalog Client#6474
difin wants to merge 6 commits into
apache:masterfrom
difin:vended_credentials_client

Conversation

@difin

@difin difin commented May 11, 2026

Copy link
Copy Markdown
Contributor

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 jobProperties and jobSecrets and 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-Delegation on 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.

@difin difin changed the title HIVE-29359: Support Credential Vending in Hive Iceberg REST Catalog C… HIVE-29359: Support Credential Vending in Hive Iceberg REST Catalog Client May 11, 2026
@difin difin force-pushed the vended_credentials_client branch from c092060 to db520b9 Compare May 20, 2026 00:15
@difin difin force-pushed the vended_credentials_client branch from db520b9 to d3274be Compare May 27, 2026 01:15
@difin difin force-pushed the vended_credentials_client branch from d3274be to d390532 Compare May 27, 2026 15:18
@difin difin force-pushed the vended_credentials_client branch from d390532 to f40686f Compare May 28, 2026 19:51
@difin difin force-pushed the vended_credentials_client branch from f40686f to c9d71f5 Compare May 28, 2026 22:31
@difin difin force-pushed the vended_credentials_client branch from c9d71f5 to e50bbd2 Compare June 4, 2026 20:46
@difin difin force-pushed the vended_credentials_client branch from 9a8b825 to 4c3214e Compare July 13, 2026 20:37
@sonarqubecloud

Copy link
Copy Markdown

@deniskuzZ

deniskuzZ commented Jul 14, 2026

Copy link
Copy Markdown
Member

I think we are also missing executor-side credential refresh. In Trino AbstractIcebergRestVendedCredentialsProvider re-vends near expiry via client.refresh-credentials-endpoint.
Could be a follow-up

@difin

difin commented Jul 14, 2026

Copy link
Copy Markdown
Contributor Author

isn't MinIO is in "maintenance mode" and is no longer accepting new changes? the image eventually could disappear from Docker Hub so i am not sure we should be adding dead project dependency. should we use ozone instead?

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 {

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should we move this to hive-it-util?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done

/** 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,

@deniskuzZ deniskuzZ Jul 14, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@difin difin Jul 14, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 deniskuzZ left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants