Known Issues in Apache Knox

Known issues identified in Cloudera Runtime 7.3.2.10000 SP1

There are no new known issues identified in this release.

Known Issues identified in Cloudera Runtime 7.3.2.100 CHF 1

CDPD-104007: Tokens on Knox Token Management page might intermittently fail to display

7.3.2.100

Tokens created under the Knox Token Management page might intermittently fail to display. The issue occurs randomly upon refreshing the page, where the underlying API call to retrieve user tokens is not triggered, causing the page to appear empty.

Refresh the page again until the tokens are displayed.

Known Issues identified in Cloudera Runtime 7.3.2

The following section lists the known issues identified in this release:

OPSAPS-76713: Knox crashes under high concurrent load when using PAM authentication on RHEL 9 or Rocky Linux 9

7.3.2

On RHEL 9 or Rocky Linux 9 versions 9.1 through 9.7, a concurrency bug in libeconf 0.4.1 causes libpam to crash under high concurrent load. This affects Knox when the cdp-proxy-api topology uses PAM authentication. When Knox handles multiple concurrent requests, libpam might crash, causing Knox service to crash and requests to the Knox cdp-proxy-api topology to fail.

Use AD/LDAP authentication instead of PAM authentication for the cdp-proxy-api topology. In Cloudera Manager, go to the Knox service, select Configuration, and configure the gateway_api_authentication_provider parameter to use AD/LDAP authentication. For configuration instructions, see Configure Apache Knox authentication for AD/LDAP.

CDPD-98063: Knox service discovery fails in FIPS-enabled clusters with JDK 17 on RHEL 9

7.3.2

7.3.2.10000

Knox Gateway cannot connect to Cloudera Manager during initial service discovery or periodic configuration analysis in FIPS-enabled clusters running JDK 17 on RHEL 9.

None.

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-76490: Ranger API bulk resource deletion fails when proxied through Knox

7.3.1 and its CHFs, 7.3.2

7.3.2.10000

Ranger API bulk resource deletion fails when the request is proxied through Knox. When Ranger sends a DELETE request with a body for bulk resource deletion, Knox does not forward the request body according to RFC 9110, causing the operation to fail.

None.

CDPD-76294: Knox service can not be started in a large size Private Cloud Base Cloudera Manager cluster

7.3.1.100 through 7.3.1.700, 7.3.2

For a large size Private Cloud Base Cloudera Manager cluster installed with Cloudera Runtime 7.3.1.0, you might face the problem that Knox can not be started with the following error message:

Wait Until Knox Gateway Can Serve Requests failed on Knox Gateway

Increase the Knox configuration parameter Knox Gateway Initial/Max Heapsize from 1 GiB to 2 GiB or 4 GiB, depending on the cluster size. Then save changes and run Restart Stale Services. After these steps, the Knox service can be started.

CDPD-71751: Creation of alias from the Cloudera Manager UI fails on FIPS

7.1.9 SP1 and its CHFs, 7.3.1 and its CHFs, 7.3.2

Users attempting to create aliases through the Cloudera Manager UI face issues in FIPS.

The alias(es) can be created using the Knox CLI:

1. ssh to Knox host.
2. Export these directories: export KNOX_GATEWAY_DATA_DIR="/var/lib/knox/gateway/data"; export KNOX_GATEWAY_CONF_DIR="/var/lib/knox/gateway/conf"
3. Set the FIPS-specific options for the Knox CLI:

   export KNOX_CLI_MEM_OPTS="--add-exports=java.base/sun.security.provider=bctls --add-exports=java.base/sun.security.provider=com.safelogic.cryptocomply.fips.core --add-modules=com.safelogic.cryptocomply.fips.core --add-modules=bctls --module-path=<BCTLS_JARS_DIR> -Dcom.safelogic.cryptocomply.fips.approved_only=true"

   <BCTLS_JARS_DIR> is the directory containing the SafeLogic bctls and fips core jar files.
4. Run the following command to create the alias: /opt/cloudera/parcels/CDH/lib/knox/bin/knoxcli.sh create-alias <ALIAS_NAME> <ALIAS_VALUE>
5. Verify the addition using /opt/cloudera/parcels/CDH/lib/knox/bin/knoxcli.sh list-alias.

For HA deployments, users must do it on every Knox host (whereas the Save Alias command applies the change to all hosts automatically).

CDPD-71305: Concurrent impala shell connection failure

7.1.9 SP1 and its CHFs, 7.3.1 and its CHFs, 7.3.2

If a user makes a concurrent impala-shell connection through Knox, then the connection fails.

Use only one Knox role.

CDPD-3125: Logging out of Atlas does not manage the external authentication

7.1.9, 7.2.18, 7.3.1 and its CHFs, 7.3.2

At this time, Atlas does not communicate a log-out event with the external authentication management, Apache Knox. When you log out of Atlas, you can still open the instance of Atlas from the same web browser without re-authentication.

To prevent additional access to Atlas, close all browser windows and exit the browser.

CDPD-28431: Intermittent errors could be potentially encountered when Impala UI is accessed from multiple Knox nodes

7.1.9, 7.3.1 and its CHFs, 7.3.2

You must use a single Knox node to access Impala UI.

CDPD-22785: Improvements and issues need to be addressed in convert-topology knox cli command

7.1.9, 7.3.1 and its CHFs, 7.3.2

None.

Knox issue with JDK version

7.1.9, 7.3.1 and its CHFs, 7.3.2

jdk-1.8.0_391 is not supported.

Cloudera recommends using Cloudera supported JDKs.

CDPD-84236: Token generated by one Knox host fails with Unknown token error on another Knox host in Data Engineering High Availability clusters

7.3.1.400 through 7.3.1.700, 7.3.2

In Data Engineering High Availability clusters, a token generated by one Knox host may fail with an Unknown token error when accessed through another Knox host. This issue occurs due to a race condition in the PostgreSQL database, which prevents one of the Knox instances from properly initializing its configured token state service.

Restart Knox on all hosts.