Known issues and technical limitations for Cloudera Iceberg REST Catalog are addressed in Cloudera Runtime 7.3.2, its service packs, and cumulative hotfixes.
Cloudera Runtime 7.3.2.10000 SP1
- CDPD-121196: Snowflake fails to retrieve Azure vended
credentials
- 7.3.2.10000 SP1
- When Data Sharing is configured on Azure and an external
Snowflake engine uses
ACCESS_DELEGATION_MODE =
VENDED_CREDENTIALS, Snowflake fails to parse the ADLS Gen2 vended credentials
and reports SQL Execution Error: Failed to retrieve credentials from the
Catalog. The Cloudera Cloudera Iceberg REST Catalog
vends the Azure SAS token in the standard storage-credentials array as
defined by the Apache Iceberg OpenAPI spec, but Snowflake currently expects it in the
top-level config map for Azure paths. As a result, Snowflake data
sharing with vended credentials works on AWS but fails on Azure.
- Configure Snowflake to use external volume credentials
instead. Set the catalog integration's
ACCESS_DELEGATION_MODE to
EXTERNAL_VOLUME_CREDENTIALS and provide a working
EXTERNAL_VOLUME when creating the Iceberg table in Snowflake. This
bypasses the credential-vending path entirely while still using the REST catalog for
metadata. For more information, see CREATE CATALOG INTEGRATION (Apache Iceberg REST)
and Use catalog-vended credentials for Iceberg
tables in the Snowflake documentation.
- CDPD-119352: REST Catalog port 8090 conflicts with YARN
ResourceManager on on-premises clusters
- 7.3.2.10000 SP1
- On on-premises clusters with TLS enabled for the Iceberg
REST Catalog, the default REST Catalog port 8090 can conflict with the YARN
ResourceManager HTTPS web application port. REST Catalog namespace API calls can return
HTTP 307 Temporary Redirect or fail to reach the catalog service.
- Change the YARN ResourceManager web application HTTPS port
(for example, to 8092) so it does not bind to port 8090, then retry REST Catalog API
calls through Knox.
- CDPD-119319: External client table reads fail when the client does
not request vended credentials
- 7.3.2.10000 SP1
- When an external engine (for example, EMR or standalone
Spark) reads a shared table through the Iceberg REST Catalog, the client must explicitly
request vended credentials by sending the
X-Iceberg-Access-Delegation:
vended-credentials HTTP header. If the client does not send this header, the
REST Catalog assumes the client authenticates to object storage with its own ambient or
local credentials. In that case the REST Catalog load-table and /credentials
API calls still succeed, but the client falls back to its environment credentials (for
example, the AWS EC2 instance role of the Spark host) when reading table data from S3.
Because that identity is not authorized on the shared bucket path, the object-storage
read fails with HTTP 403 Forbidden. This was originally observed on AWS mixed-mode QI 95
deployments, but the behavior is not specific to mixed-mode or TLS configuration. QI 95
refers to the Cloudera Encryption on wire everywhere (Encryption of Data-in-Motion)
quality initiative. A mixed-mode QI 95 deployment is a cluster in which the Data Lake and
Data Hub are configured with different TLS versions.
- Ensure the external client requests vended credentials by
sending the
X-Iceberg-Access-Delegation: vended-credentials header, and
use an Iceberg client version that sets this header (for example, Iceberg 1.10.2). This
behavior conforms to the Iceberg REST Catalog OpenAPI specification.
Known issues identified in Cloudera Runtime 7.3.2.100 CHF 1
There are no new known issues in this release.
Known issues identified in Cloudera Runtime 7.3.2
- CDPD-79748: Client ID and secret can access namespaces and DB
metadata
without creating a data share
- 7.3.2 and higher service packs and cumulative
hotfixes
- A client ID and secret can be used to call
namespace/database
APIs and retrieve database metadata even when no Data Share is created. The behavior is
tied
to Ranger-side policy configuration and can expose namespace or database details beyond
intended share boundaries.
- Review Ranger default policies and remove broad public
access for
external users. Configure deny and exclude policy rules so only explicitly allowed share
members
can access shared data.
- CDPD-80346: Client region provisioning for cloud credentials
- 7.3.2 and higher service packs and cumulative
hotfixes
- For S3-backed Iceberg access, the IDBroker credential
response does
not include client region information. As a result, Data Sharing relies on a configured
fallback client region, which can lead to issues for cross-region access and
multi-region
resilience scenarios.
- Configure
client_region in
hive-site.xml for the target environment.
- CDPD-90155: DataShareAdmin has access to all tables in the Data
Lake
- 7.3.2 and higher service packs and cumulative
hotfixes
- A user assigned the
DataShareAdmin role
can access all tables in the data lake without explicit grants from a data owner. This
behavior is tied to broad Ranger and Knox admin privileges inherited by the
DataShareAdmin role and can allow unintended data sharing, which impacts
separation-of-duties and least-privilege governance expectations.
- None
- CDPD-91957: Accessing a Hive table from an external client
returns an error on non-us-west-2 environments
- 7.3.2 and higher service packs and cumulative
hotfixes
- When an environment is located in a region other than
us-west-2, accessing a Hive table from an external client (such as AWS Elastic
MapReduce or Standalone Spark) using the REST catalog might return a 301 redirect error.
This occurs because the client.region value defaults to
us-west-2 when not explicitly configured, and attempting to access an Amazon S3
file with a client configured for a different region results in an error.
- Manually configure the
client.region
value in the Hive Metastore configuration for the target environment after enabling the Cloudera Iceberg REST Catalog.
Known issues identified before Cloudera Runtime 7.3.2
Known issues identified before Cloudera Runtime 7.3.2 include only
unresolved issues from previous releases that continue to affect the Cloudera Runtime 7.3.2 base release.
- CDPD-81718: Check Metering V2 Service health before starting
Rest Catalog Jetty Server
- 7.3.1.400 and higher service packs and cumulative
hotfixes
- Checking the Metering V2 Service health status before
starting the REST Catalog service has been temporarily removed. This check was causing
failures in environments where the Metering Service is not available, such as certain Cloudera Manager-based environments.
- None
- CDPD-83244: Snowflake Catalog Integration Secret Rotation
- 7.3.1.400 and higher service packs and cumulative
hotfixes
- When creating a Snowflake catalog integration, Snowflake
does not allow changing the
CLIENT ID for the integration, only the
secret. However, when using Knox to generate these credentials, both a new CLIENT
ID and a new secret are generated. Replacing the catalog integration is not
possible if it has active tables.
- Change the catalog integration for each table individually
or create a new table. Alternatively, you can use a workaround by altering the catalog
integration with only the new secret for the old
CLIENT ID, provided
you have the correct Ranger policy for the new CLIENT ID.
- CDPD-83243: Snowflake Catalog Integration with Vended
Credentials is not supported
- 7.3.1.400 and higher service packs and cumulative
hotfixes
- Snowflake catalog integration with vended credentials is
not supported. Attempting to use the
/credentials API endpoint results
in a No route to host or BadRequestException error,
and table creation fails.
- None
- CDPD-82198: Metering events are sent for deleted or unauthorized
tables
- 7.3.2
- 7.3.1.400 and higher service packs and cumulative
hotfixes
- Metering events are generated for deleted or unauthorized
tables. If API calls are made for tables that do not exist or fail on the server side
(for example, the user is not authorized on the table, or an error occurs while
processing the request on the backend in the Hive Metastore, Apache Ranger, or Apache
Knox), these calls are still metered and billed. This is expected behavior.
- None
