Security options for the headless code coverage collector

The headless code coverage collector has several options to configure security, which are outlined here. These are important as unless explicitly disabled, the headless code coverage collector includes the listing or source during collection. See the -s,savesource parameter in Starting and stopping the headless code coverage collector .

Running the code coverage collector daemon in secure mode

When running the code coverage collector daemon on any of the supported platforms, it is highly recommended to run the daemon in secure mode, but particularly when the code coverage collector is not running on z/OS or when running on a different host where the z/OS® Debugger is running. Review the syntax for the -K,daemonkeystoreproperties parameter in Starting and stopping the headless code coverage collector.

Enabling Authentication

As the code coverage collector does not support the Debug Manager, it is possible that stray or accidental incoming code coverage sessions might occur. Enabling authentication will ensure that only the designated incoming code coverage sessions will be allowed to connect to the daemon. Review the syntax for the -u,authkeystoreproperties parameter in Starting and stopping the headless code coverage collector and see to Enabling authentication for incoming TCP/IP connections.

Running Code Coverage Service

Code Coverage Service (CCS) is a REST API running in a web server as part of the headless code coverage collector. It is strongly recommended that you only run CCS when running the collector on z/OS, as the collector on Windows and Linux do not support authentication, and are deprecated in part for this reason. See to Securing Code Coverage Service on z/OS.

In addition to authentication, it is highly recommended to run CCS using a secured port. Review the syntax for -S,ccsport and -k,ccskeystoreproperties parameters in Starting and stopping the headless code coverage collector.

In addition to the command line parameters for the collector, there are additional java properties that can control the Jetty web server that serves the CCS API:

Property	Description
CCSmaxRequestsPerSec	Default: 25 Controls the maximum number of CCS requests permitted every second. Use to prevent a denial of service.
CCSmaxConcurRequests	Default: 20 Controls the maximum number of concurrent CCS requests permitted every second. Use to prevent a denial of service.
ccs_blockIPAccess	Default: false Setting this to true prevents access to CCS using the IP address, allowing only the IP name. Use to ensure internal network information remains hidden.

Property

Description

CCSmaxRequestsPerSec

Default: 25

Controls the maximum number of CCS requests permitted every second. Use to prevent a denial of service.

CCSmaxConcurRequests

Default: 20

Controls the maximum number of concurrent CCS requests permitted every second. Use to prevent a denial of service.

ccs_blockIPAccess

Default: false

Setting this to true prevents access to CCS using the IP address, allowing only the IP name. Use to ensure internal network information remains hidden.

For the Windows and Linux versions of the headless code coverage collector, modify the <install_location>/headless-cc/codecov.ini file and define the following system property in the -vmargs section:

-D<property>=<desired_value>

For the z/OS headless code coverage collector, you must set the environment variable OPENJ9_JAVA_OPTIONS with the java argument before you start headless code coverage:

export OPENJ9_JAVA_OPTIONS="$OPENJ9_JAVA_OPTIONS -D<property>=<desired_value>"

For Remote Debug Service, see Customizing with the sample job EQARMTSU.