Enabling Wire-level Security
Describes how to enable wire-level security.
About this task
Wire-level security encrypts data transmission between the nodes in your cluster.
When you set up a cluster, run the configure.sh
script on each node that you want to add to the cluster.
Basic Procedure
About this task
To enable wire-level encryption for the cluster, follow these steps in order:
Procedure
- If the cluster is running, shut it down.
-
Delete the
ssl_keystore
,ssl_truststore
,ssl_truststore.p12
, andssl_truststore.pem
files on a machine where wire-level security is not enabled because theconfigure.sh
script fails if you already have these files in the directory.NOTE: TheFor example, to delete the files, run the following commands:ssl_keystore
,ssl_truststore
,ssl_truststore.p12
, andssl_truststore.pem
files are generated during installation of the Web server even if you did not enable security.
If you are re-running the script due to an invocation error from a previous run, thecd /opt/mapr/conf /bin/rm -f ssl_keystore ssl_truststore ssl_truststore.p12 ssl_truststore.pem
cldb.key
andmaprserverticket
files may also have been created. Delete these files because the script fails if you already have these files in the directory. For example, run the following command to delete these files:cd /opt/mapr/conf /bin/rm -f cldb.key maprserverticket ssl_keystore ssl_truststore ssl_truststore.p12 ssl_truststore.pem
-
Run the
configure.sh
script with the-secure -genkeys
options on the first CLDB node in your cluster:/opt/mapr/server/configure.sh -secure -genkeys -Z <Zookeeper_node_list> -C <CLDB_node_list> -N <cluster_name>
where both<Zookeeper_node_list>
and<CLDB_node_list>
have the formhostname[:port_no][,hostname[:port_no]...] and -N <cluster_name>
specifies the cluster name.IMPORTANT: You must runThis command generates six files in theconfigure.sh -genkeys
only once on one CLDB node, since the resulting files must be copied to other nodes./opt/mapr/conf
directory:cldb.key
maprserverticket
ssl_keystore
ssl_truststore
ssl_truststore.p12
ssl_truststore.pem
-
Copy the
cldb.key
file to any node that has the CLDB or Zookeeper service installed. -
Copy the
maprserverticket
,ssl_keystore
,ssl_truststore
,ssl_truststore.p12
, andssl_truststore.pem
files to the/opt/mapr/conf
directory of every node in the cluster. -
Verify that the files from the previous step are owned by the user that
runs cluster services. This user is
mapr
by default. Also, themaprserverticket
andssl_keystore
files must have their UNIX permission-mode bits set to600
, and thessl_truststore
,ssl_truststore.p12
, andssl_truststore.pem
files must be readable to all users. -
Run
configure.sh -secure
on each existing node in the cluster using the same arguments as in Step 3 but without the-genkeys
option.
The/opt/mapr/server/configure.sh -secure -Z <Zookeeper_node_list> -C <CLDB_node_list> -N <cluster_name>
-secure
option indicates that wire-level security must be enabled on the node where the command is run.IMPORTANT: You must also do this on any nodes that you add to the cluster in the future. -
Copy the
ssl_truststore
,ssl_truststore.p12
, andssl_truststore.pem
files to any client nodes outside the cluster.IMPORTANT: If you runconfigure.sh -secure
on a node before you copy the necessary files to that node, the command fails. -
Log in as the mapr superuser using the maprlogin command:
maprlogin password
(in this command,password
is literal text). -
Set the volume-level encryption flag (for the volumes whose traffic you wish to
encrypt) using the
volume create
orvolume modify
command with the-wiresecurityenabled
argument set totrue
. -
If clients will connect to multiple secure clusters, merge the
ssl_truststore
files with the/opt/mapr/server/manageSSLKeys.sh
tool. See Setting Up the Client for more information on MapR clients.
Advanced Procedure
About this task
In certain situations, you may opt for variant of the basic procedure. Such situations include, but are not limited to the following:
- You are running the script on a host that is configured without a domain name.
- You have a cluster where all the machines do not have the same domain name.
- You wish to import your own custom certificates instead of the self-signed
certificates generated by the
configure.sh
utility.
Running on Hosts with no Configured Domain Name
About this task
When used without the -certdomain
argument, the
configure.sh
script discovers the domain name of the
node on which it is being executed using the hostname -d
command and then creates a 100-year self-signed certificate using the PKCS#1
v1.5 with SHA-512 hash function (SHA512withRSA) with a wildcard certificate
with the common name (CN) *.<domain>
. For
example, if hostname -d
returns the domain name
mycompany.com
, then the CN of the certificate is
*.mycompany.com
. This certificate works for all
machines within the mycompany.com
domain and can therefore
be copied to all cluster nodes as specified in Step 5 in the Basic Procedure.
Certificate generation fails if the host that you are running the
script from is configured without a domain name. To fix this, modify
your machine configuration so that hostname -d
returns a
non-empty string and then run the configure.sh
script.
Alternatively, re-run the script with the -certdomain
option
as shown in Step 3 of the Basic Procedure:
/opt/mapr/server/configure.sh -secure -genkeys -certdomain <domain_name> -Z <Zookeeper_node_list> -C <CLDB_node_list> [ -N <cluster_name> ]
Securing Clusters with Multiple Domain Names
About this task
Generally, all machines within a cluster should belong to the same domain. In
the unusual case where you have a cluster with different machines belonging
to different domains, applications that perform hostname verification can
fail if you run the configure.sh
script (as described in
Step 3 of the Basic Procedure) to
generate a single-domain wildcard certificate. In this case, you must
provide your own multi-domain wildcard certificate and import the custom
certificate into the keystore as described in Importing a Certificate Authority Signed
(CA Signed) SSL Certificate Into a MapR Cluster.
Using Custom Certificates
About this task
To import your own custom certificates into the keystore instead of using the self-signed certificates, see Importing a Certificate Authority Signed (CA Signed) SSL Certificate Into a MapR Cluster.