Configure SSL Near Real-Time Monitoring on Port 50505 (Cloud)
By default, the port that Pepperdata uses for listening (port 50505
for PepAgents) is unsecured.
(In Pepperdata Supervisor v7.1.10 or earlier, PepAgents on the ResourceManager hosts also listen on port 50510
for communication in addition to the common port 50505
. Port 50510
is also unsecured.
The steps below apply both to port 50505
and 50510
in Pepperdata Supervisor
v7.1.10 or earlier. No extra step is needed to secure port 50510
separately.)
You can configure the port for secure SSL communication by using certificates and adding properties for the certificate’s keystore location, name, and password to the Pepperdata site file, pepperdata-site.xml
.
(For information about accessing the stats that Pepperdata collects through its listeners, see Pepperdata Status Views via Web Servlets.)
On This Page
Prerequisites
-
Install and activate Pepperdata in your cloud environment.
-
Provide a certificate to use for securing the HTTPS connections to port 50505.
-
PKCS #12 and JKS (Java KeyStore) certificates are supported.
- If the certificate name extension is
.jks
, Pepperdata assumes that it is a JKS certificate. - For any other extension, Pepperdata assumes that it is a PKCS #12 certificate.
- If the certificate name extension is
-
For highest security, we recommend using certificates that are signed by a trusted certificate authority (CA). Work with your security team or system administrator to obtain a certificate that complies with your organization’s security policies.
-
As a temporary measure or for non-production environments, you can use a self-signed certificate. Although not as secure as certificates from trusted CAs, self-signed certificates are better than transmitting account names and passwords in cleartext.
You can use a commercial or open source tool to generate a self-signed certificate.
-
For example, the following command uses the Java
keytool
utility (keytool ) to generate a self-signed PKCS #12 certificate namedtestpepperpkcs.pfx
, with passwordpepperdata
given in the command-line argument-storepass
, with an RSA key of size 2048, and writes it to the/etc/pepperdata
directory:keytool -genkey -storetype PKCS12 -alias testpepperdatapkcs12 -keystore /etc/pepperdata/testpepperpkcs.pfx -keyalg RSA -storepass pepperdata -validity 730 -keysize 2048
-
Similarly, the following command uses the Java
keytool
utility (keytool ) to generate a self-signed JKS certificate namedtestpepperjks.jks
, with passwordpepperdata
given in the command-line argument-storepass
, with an RSA key of size 2048, and writes it to the/etc/pepperdata
directory:keytool -genkey -storetype JKS -alias testpepperdatajks -keystore /etc/pepperdata/testpepperjks.jks -keyalg RSA -storepass pepperdata -validity 730 -keysize 2048
-
-
-
Encrypt your keystore password, and copy/note the result.
-
Run the Pepperdata password encryption script.
/opt/pepperdata/supervisor/encrypt_password.sh
-
At the
Enter the password to encrypt:
prompt, enter your keystore password. -
Copy (or make note of) the resulting encrypted password.
For example, in the following output from the script, the encrypted password is the string
W+ONY3ZcR6QLP5sqoRqcpA=2
.Encrypted password is W+ONY3ZcR6QLP5sqoRqcpA=2
-
Procedure
-
In your cloud environment (such as GDP or AWS), add the certificate’s keystore location and encrypted password to the Pepperdata configuration.
-
From the environment’s cluster configuration folder (in the cloud), download the Pepperdata site file,
/etc/pepperdata/pepperdata-site.xml
, to a location where you can edit it. -
Open the file for editing, and add the required properties.
Be sure to substitute your keystore name and keystore password for the
your-keystore
andyour-encrypted-password
placeholders in the following code snippet.<property> <name>pepperdata.supervisor.rpc.server.keystore.location</name> <value>/etc/pepperdata/your-keystore.pfx</value> </property> <property> <name>pepperdata.supervisor.rpc.server.keystore.password</name> <value>your-encrypted-password</value> </property>
Malformed XML files can cause operational errors that can be difficult to debug. To prevent such errors, we recommend that you use a linter, such asxmllint
, after you edit any .xml configuration file. -
Save your changes and close the file.
-
Upload the revised file to overwrite the original
pepperdata-site.xml
file.
If there are no already-running hosts with Pepperdata, you are done with this procedure. Do not perform the remaining steps. -
-
Open a command shell (terminal session) and log in to any already-running host as a user with
sudo
privileges.Important: You can begin with any host on which Pepperdata is running, but be sure to repeat the login (this step), check for certificate (next step), copying the bootstrap file (step 4), and loading the revised Pepperdata configuration (step 5) on every already-running host. -
Ensure that the certificate (from the prerequisites) is available on the host, and that its location matches the value that you provided in step 1 for the
pepperdata.supervisor.rpc.server.keystore.location
property in the Pepperdata site file. -
From the command line, copy the Pepperdata bootstrap script that you extracted from the Pepperdata package from its local location to any location; in this procedure’s steps, we’ve copied it to
/tmp
.-
For Amazon EMR clusters:
aws s3 cp s3://<pd-bootstrap-script-from-install-packages> /tmp/bootstrap
-
For Google Dataproc clusters:
sudo gsutil cp gs://<pd-bootstrap-script-from-install-packages> /tmp/bootstrap
-
-
Load the revised configuration by running the Pepperdata bootstrap script.
-
For EMR clusters:
-
You can use the --long-options form of the
--bucket
,--upload-realm
, and--is-running
arguments as shown or their -short-option equivalents,-b
,-u
, and-r
. -
The
--is-running
(-r
) option is required for bootstrapping an already-running host prior to Supervisor version 7.0.13. -
Optionally, you can specify a proxy server for the AWS Command Line Interface (CLI) and Pepperdata-enabled cluster hosts.
Include the
--proxy-address
argument when running the Pepperdata bootstrap script, specifying its value as a fully-qualified host address that useshttps
protocol. -
If you’re using a non-default EMR API endpoint (by using the
--endpoint-url
argument), include the--emr-api-endpoint
argument when running the Pepperdata bootstrap script. Its value must be a fully-qualified host address. (It can usehttp
orhttps
protocol.) -
If you are using a script from an earlier Supervisor version that has the
--cluster
or-c
arguments instead of the--upload-realm
or-u
arguments (which were introduced in Supervisor v6.5), respectively, you can continue using the script and its old arguments. They are backward compatible. -
Optionally, you can override the default exponential backoff and jitter retry logic for the
describe-cluster
command that the Pepperdata bootstrapping uses to retrieve the cluster’s metadata.Specify either or both of the following options in the bootstrap’s Optional arguments. Be sure to substitute your values for the
<my-retries>
and<my-timeout>
placeholders that are shown in the command.-
max-retry-attempts
—(default=10) Maximum number of retry attempts to make after the initialdescribe-cluster
call. -
max-timeout
—(default=60) Maximum number of seconds to wait before the next retry call todescribe-cluster
. The actual wait time for a given retry is assigned as a random number, 1–calculated timeout (inclusive), which introduces the desired jitter.
-
-
# For Supervisor versions before 7.0.13: sudo bash /tmp/bootstrap --bucket <bucket-name> --upload-realm <realm-name> --is-running [--proxy-address <proxy-url:proxy-port>] [--emr-api-endpoint <endpoint-url:endpoint-port>] [--max-retry-attempts <my-retries>] [--max-timeout <my-timeout>] # For Supervisor versions 7.0.13 and later: sudo bash /tmp/bootstrap --bucket <bucket-name> --upload-realm <realm-name> [--proxy-address <proxy-url:proxy-port>] [--emr-api-endpoint <endpoint-url:endpoint-port>] [--max-retry-attempts <my-retries>] [--max-timeout <my-timeout>]
-
For Dataproc clusters:
sudo bash /tmp/bootstrap <bucket-name> <realm-name>
The script finishes with a
Pepperdata installation succeeded
message. -
-
Repeat steps 2–5 on every already-running host in your cluster.
Important: Be sure to repeat steps 2–4 on every already-running host. If you skip the SSL configuration process on a host, Pepperdata cannot monitor it via the secured port.