Hardening Security on cloudera Cluster

[#1]

Hello,

During a security scan, two issues have been discovered in my Cloudera cluster (Cloudera Manager version 7.13.1, Cloudera Runtime 7.3.1).

Zookeeper issue (Zookeeper version 3.8.1.7.3.1.0-197):

• On the nodes where zookeeper runs, I have the bellow issue:
• HTTP TRACE / TRACK Methods Allowed - Debugging functions are enabled on the remote web server - port 7000

Mapreduce HSTS header:

• HSTS Missing From HTTPS Server / port 13562

Can you please assist on how to mitigate these issues?

Thank you!

[#2]

1. We can see the PORT 7000 is not used by any service from cloudera
https://docs.cloudera.com/cdp-private-cloud-base/7.1.9/installation/topics/cdpdc-ports-used-by-runti...

Please confirm and update
for disallow or disable HTTP TRACE please follow the below link https://access.redhat.com/solutions/198813

2. The  Port 13562 is part of MapReduce Shuffle Port. This port is listening on all Yarn nodeManager nodes.  If SSL is enabled for MapReduce , this port shall operate with SSL. You can set the HSTS credentials in configurations. 

[#3]

hello,

Thank you for your answer.

1. port 7000

• here: https://access.redhat.com/solutions/198813 it says to modify 'echo TraceEnable off >>/etc/httpd/conf/httpd.conf' & and restart 'service httpd reload' apache server. The problem is that on none of my servers in the cluster, the httpd service is not actually running.

Do you have any other suggestions?

2. For MapReduce -> I enabled HTTS on MapReduce Shuffle with:

but I still don't understand where I should add the HSTS header configuration. In ssl-server.xml? How would the config look like? Like in the image bellow?

I tested with what I stated in the images above and HSTS header is not present.

Thank you!

[#4]

Sorry, just an update regarding port 7000. From my debug on the server, this port is opened by a java process running the zookeeper-server process. This is why I mentioned it here. 

Also, the configuration in the zookeeper service -> Server -> metrics

Thanks!

[#5]

I ran into the same findings in a Cloudera 7.x setup. For the Zookeeper TRACE/TRACK warning on port 7000, you can mitigate it by disabling these methods in the embedded Jetty config or, more commonly, by placing a reverse proxy (Apache/Nginx) in front of ZooKeeper and blocking TRACE/TRACK.

For the MapReduce HSTS warning (port 13562), HSTS isn’t enabled by default. The fix is to add the Strict Transport Security header either through the service’s HTTPS response configuration or again via a reverse proxy. This enforces HTTPS and clears the scan finding.

[#6]

Hi @dimi_yu

I am also facing same issue could you please let me know where can I get this jeety confi file and what parameters need to add in this config file ? From CM is there any way or from backend only needs to do this?

[#7]

For zookeeper on port 7000 security team observer the same http trace/track vulnerability 

[#8]

@Raufshaikh @teo123 @dimi_yu -

Starting with CDP 7.1.9, Cloudera rebased ZooKeeper to version 3.8 (3.8.1.7.1.9.0-387). Beginning with ZooKeeper version 3.6.0, a new a new monitoring feature (New Metrics System ) was introduced where you can enable the Prometheus MetricsProvider [0]. By default, the Port is set to the default port number of 7000 (which is configurable by setting "metricsProvider.httpPort"). While Prometheus itself does not require the HTTP TRACE method for normal operation, this behaviour is a result of the upstream ZooKeeper implementation ZOOKEEPER-3731.

We at Cloudera, actively working internally to disable HTTP TRACE in the Prometheus MetricsProvider endpoint in an upcoming CDP release as part of our continued focus on security hardening.

Which will be fixed in CDP 7.3.2, released in early 2026.

As a workaround for now, you can just uncheck the "Enable the Prometheus MetricsProvider" option to disable the port for Prometheus metrics.

[0] = https://zookeeper.apache.org/doc/r3.9.3/zookeeperAdmin.html#:~:text=metricsProvider.httpPort