-
Language:
English
-
Language:
English
Chapter 9. Security for Cluster Traffic
9.1. Node Authentication and Authorization (Remote Client-Server Mode)
Security can be enabled at node level via SASL protocol, which enables node authentication against a security realm. This requires nodes to authenticate each other when joining or merging with a cluster. For detailed information about security realms, see Section 8.7.1, “About Security Realms”.
The following example depicts the <sasl /> element, which leverages the SASL protocol. Both
DIGEST-MD5
or GSSAPI
mechanisms are currently supported.
Example 9.1. Configure SASL Authentication
<management> <security-realms> ... <security-realm name="ClusterRealm"> <authentication> <properties path="cluster-users.properties" relative-to="jboss.server.config.dir"/> </authentication> <authorization> <properties path="cluster-roles.properties" relative-to="jboss.server.config.dir"/> </authorization> </security-realm> </security-realms> ... </security-realms> </management> <stack name="udp"> ... <sasl mech="DIGEST-MD5" security-realm="ClusterRealm" cluster-role="cluster"> <property name="client_name">node1</property> <property name="client_password">password</property> </sasl> ... </stack>
In the provided example, the ndoes use the
DIGEST-MD5
mechanism to authenticate against the ClusterRealm
. In order to join, nodes must have the cluster
role.
The
cluster-role
attribute determines the role all nodes must belong to in the security realm in order to JOIN
or MERGE
with the cluster. Unless it has been specified, the cluster-role
attribute is the name of the clustered <cache-container>
by default. Each node identifies itself using the client-name
property. If none is specified, the hostname on which the server is running will be used.
This name can also be overridden by specifying the
jboss.node.name
system property that can be overridden on the command line. For example:
$ clustered.sh -Djboss.node.name=node001
Note
JGroups AUTH protocol is not integrated with security realms, and its use is not advocated for Red Hat JBoss Data Grid.
9.1.1. Configure Node Authentication for Cluster Security (DIGEST-MD5)
The following example demonstrates how to use
DIGEST-MD5
with a properties-based security realm, with a dedicated realm for cluster node.
Example 9.2. Using the DIGEST-MD5 Mechanism
<management> <security-realms> <security-realm name="ClusterRealm"> <authentication> <properties path="cluster-users.properties" relative-to="jboss.server.config.dir"/> </authentication> <authorization> <properties path="cluster-roles.properties" relative-to="jboss.server.config.dir"/> </authorization> </security-realm> </security-realms> </management> <subsystem xmlns="urn:infinispa:server:jgroups:6.1" default-stack="${jboss.default.jgroups.stack:udp}"> <stack name="udp"> <transport type="UDP" socket-binding="jgroups-udp"/> <protocol type="PING"/> <protocol type="MERGE2"/> <protocol type="FD_SOCK" socket-binding="jgroups-udp-fd"/> <protocol type="FD_ALL"/> <protocol type="pbcast.NAKACK"/> <protocol type="UNICAST2"/> <protocol type="pbcast.STABLE"/> <protocol type="pbcast.GMS"/> <protocol type="UFC"/> <protocol type="MFC"/> <protocol type="FRAG2"/> <protocol type="RSVP"/> <sasl security-realm="ClusterRealm" mech="DIGEST-MD5"> <property name="client_password>...</property> </sasl> </stack> </subsystem> <subsystem xmlns="urn:infinispan:server:core:6.1" default-cache-container="clustered"> <cache-container name="clustered" default-cache="default"> <transport executor="infinispan-transport" lock-timeout="60000" stack="udp"/> <!-- various clustered cache definitions here --> </cache-container> </subsystem>
In the provided example, supposing the hostnames of the various nodes are
node001
, node002
, node003
, the cluster-users.properties
will contain:
node001=/<node001passwordhash>/
node002=/<node002passwordhash>/
node003=/<node003passwordhash>/
The
cluster-roles.properties
will contain:
- node001=clustered
- node002=clustered
- node003=clustered
To generate these values, the following
add-users.sh
script can be used:
$ add-user.sh -up cluster-users.properties -gp cluster-roles.properties -r ClusterRealm -u node001 -g clustered -p <password>
The
MD5
password hash of the node must also be placed in the "client_password
" property of the <sasl/> element.
<property name="client_password>...</property>
Note
To increase security, it is recommended that this password be stored using a Vault. For more information about vault expressions, see the Red Hat Enterprise Application Platform Security Guide
Once node security has been set up as discussed here, the cluster coordinator will validate each
JOIN
ing and MERGE
ing node's credentials against the realm before letting the node become part of the cluster view.
9.1.2. Configure Node Authentication for Cluster Security (GSSAPI/Kerberos)
When using the
GSSAPI
mechanism, the client_name
is used as the name of a Kerberos-enabled login module defined within the security domain subsystem. For a full procedure on how to do this, see Section 8.7.7.1, “Configure Hot Rod Authentication (GSSAPI/Kerberos)”.
Example 9.3. Using the Kerberos Login Module
<security-domain name="krb-node0" cache-type="default"> <authentication> <login-module code="Kerberos" flag="required"> <module-option name="storeKey" value="true"/> <module-option name="useKeyTab" value="true"/> <module-option name="refreshKrb5Config" value="true"/> <module-option name="principal" value="jgroups/node0/clustered@INFINISPAN.ORG"/> <module-option name="keyTab" value="${jboss.server.config.dir}/keytabs/jgroups_node0_clustered.keytab"/> <module-option name="doNotPrompt" value="true"/> </login-module> </authentication> </security-domain>
The following property must be set in the <sasl/> element to reference it:
<sasl ...> <property name="login_module_name">...</property> </sasl>
As a result, the
authentication
section of the security realm is ignored, as the nodes will be validated against the Kerberos Domain Controller. The authorization
configuration is still required, as the node principal must belong to the required cluster-role.
In all cases, it is recommended that a shared authorization database, such as LDAP, be used to validate node membership in order to simplify administration.
By default, the principal of the joining node must be in the following format:
jgroups/$NODE_NAME/$CACHE_CONTAINER_NAME@REALM