Incorrect Kerberos principals are created when external-* listener is configured on namenode

Affected Stackable version

25.3

Affected Apache HDFS version

3.4.1

Current and expected behavior

The behaviour occurs when a listenerClass of either external-unstable or external-stable is configured on the namenodes. The kerberos principals added to the namenode keytab containing the IP address of the nodes on which the NodePort is created and not the listener address as expected.

core-site.xml still contains the listener address as expected.

  <property>
    <name>dfs.web.authentication.kerberos.principal</name>
    <value>HTTP/listener-hdfs-namenode-default-0.default.svc.cluster.local@${env.KERBEROS_REALM}</value>
  </property>

This means that connections to the namenode fail since the expected Kerberos principal for the listener address is not present in the namenode keytab.

Current behaviour

The namenode keytab contains principals with the host set to the node IP.

stackable@hdfs-namenode-default-1 /stackable/hadoop-3.4.1 $ klist -kt ../kerberos/keytab
Keytab name: FILE:../kerberos/keytab
KVNO Timestamp         Principal
---- ----------------- --------------------------------------------------------
   1 09/10/25 07:28:05 nn/172.21.0.3@KNAB.COM
   1 09/10/25 07:28:05 nn/172.21.0.3@KNAB.COM
   1 09/10/25 07:28:05 nn/hdfs.default.svc.cluster.local@KNAB.COM
   1 09/10/25 07:28:05 nn/hdfs.default.svc.cluster.local@KNAB.COM
   1 09/10/25 07:28:05 HTTP/172.21.0.3@KNAB.COM
   1 09/10/25 07:28:05 HTTP/172.21.0.3@KNAB.COM
   1 09/10/25 07:28:05 HTTP/hdfs.default.svc.cluster.local@KNAB.COM
   1 09/10/25 07:28:05 HTTP/hdfs.default.svc.cluster.local@KNAB.COM

Expected behaviour

The namenode keytab contains principals with the host set to the listener address.

stackable@hdfs-namenode-default-0 /stackable/hadoop-3.4.1 $ klist -kt ../kerberos/keytab
Keytab name: FILE:../kerberos/keytab
KVNO Timestamp         Principal
---- ----------------- --------------------------------------------------------
   1 09/10/25 09:33:33 nn/listener-hdfs-namenode-default-0.default.svc.cluster.local@KNAB.COM
   1 09/10/25 09:33:33 nn/listener-hdfs-namenode-default-0.default.svc.cluster.local@KNAB.COM
   1 09/10/25 09:33:33 nn/hdfs.default.svc.cluster.local@KNAB.COM
   1 09/10/25 09:33:33 nn/hdfs.default.svc.cluster.local@KNAB.COM
   1 09/10/25 09:33:33 HTTP/listener-hdfs-namenode-default-0.default.svc.cluster.local@KNAB.COM
   1 09/10/25 09:33:33 HTTP/listener-hdfs-namenode-default-0.default.svc.cluster.local@KNAB.COM
   1 09/10/25 09:33:33 HTTP/hdfs.default.svc.cluster.local@KNAB.COM
   1 09/10/25 09:33:33 HTTP/hdfs.default.svc.cluster.local@KNAB.COM

Possible solution

No response

Additional context

No response

Environment

No response

Would you like to work on fixing this bug?

None

Start by tracing how the external-unstable and external-stable listenerClass settings affect namenode principal and keytab generation. Compare the configured listener address with the principals shown by klist and the address retained in core-site.xml. Done means the keytab contains nn and HTTP principals for the listener address and connections succeed.