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

[difin]

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.

[sonarqubecloud]

Quality Gate passed

Issues
4 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.3% Duplication on New Code

See analysis details on SonarQube Cloud

[okumin]

I am feeling the prefix information is gone.

[difin]

Good catch, added an assertion that prefix() remains s3://my-bucket/ in the deserialized blob, along with the overridden endpoint and vended keys in config().

[okumin]

Most Iceberg clients don't need to ser/de credentials on their own, probably. We need it. That's because we serialize an Iceberg table in Hadoop's configuration as an intermediate expression? I guess we should store the credentials as they are and just restore them, without refining or normalizing the content on the Hive side

[difin]

You're right that most Iceberg clients don't need to ser/de credentials themselves. Hive does, because we serialize the Iceberg Table (SerializableTable) into JobConf for Tez/LLAP, and vended credentials on FileIO typically don't survive that round-trip. Executors rebuild the table from job conf and don't re-run REST loadTable, so we propagate credentials separately (VENDED_STORAGE_CREDENTIALS + S3A bucket keys) and restore them in deserializeTable via applyFromJobConf.

The main place we mutate vended credential content is withConfigurationOverrides() method. REST catalogs can vend connectivity settings from their network view (e.g. http://minio:9000 when the catalog runs in Docker), while Hive session config sets a host-reachable endpoint (iceberg.catalog.ice01.s3.endpoint=http://host:9000). That method overrides only non-secret fields (s3.endpoint, s3.path-style-access) so Iceberg FileIO and S3A agree on connectivity; vended keys are preserved. It runs at both store time (propagateToJob, so the blob on executors is self-contained) and restore time (applyFromJobConf, e.g. when commit still has the catalog-internal endpoint on FileIO from loadTable).

[okumin]

vended credentials on FileIO typically don't survive that round-trip

Is this tested? I presume it is part of serializable objects

[difin]

I tested in the Gravitino q-test: you are correct — vended credentials in table.io().properties() survive ser/de to executors. We still need to extract those credentials and stage them in Hive job configuration for two reasons:

1. Hadoop S3A. Iceberg FileIO and Hadoop S3A do not share state; S3A only reads Configuration, and Tez/LLAP use S3A for s3:// paths. At compile time (configureInputJobProperties / configureInputJobCredentials) we have TableDesc, not the final task JobConf, so vended credentials are staged in jobProperties and jobSecrets per HIVE-20651. At job submit, those maps are merged into JobConf / Hadoop Credentials and sent to executors before tasks run.

2. Iceberg FileIO endpoint override. applyFromJobConf in HiveTableUtil.deserializeTable is still needed when REST catalogs vend S3 connection settings for their own network while Hive runs elsewhere. In the Gravitino q-test, Gravitino (in Docker) vends s3.endpoint=http://minio:9000, which tasks on the host cannot reach; session config sets a reachable endpoint (http://<host>:9000). applyFromJobConf takes vended credentials (from job conf or FileIO.properties()), replaces endpoint and path-style with session values, leaves access keys unchanged, and installs the result on the FileIO via setCredentials(). In my debug, deserialized table.io().properties() still had http://minio:9000, so this step is required even when vended keys survive ser/de.

[sonarqubecloud]

Quality Gate passed

Issues
3 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.3% Duplication on New Code

See analysis details on SonarQube Cloud

[deniskuzZ]

isn't MinIO is in "maintenance mode" and is no longer accepting new changes? should we use ozone instead?