Cluster Security
The Enterprise Edition of the Terracotta kit provides standard authentication methods to control access to Terracotta servers. Enabling one of these methods causes a Terracotta server to require credentials before allowing a JMX connection to proceed.
Configuring Security
You can configure security using the Lightweight Directory Access Protocol (LDAP) or JMX authentication.
LDAP security is based on JAAS and requires Java 1.6. Using an earlier version of Java will not prevent Terracotta servers from running; however security will not be enabled.
To configure security using LDAP, follow these steps:
Save the following configuration to the file .java.login.config:
Terracotta {
com.sun.security.auth.module.LdapLoginModule REQUIRED
java.naming.security.authentication="simple"
userProvider="ldap://orgstage:389"
authIdentity="uid={USERNAME},ou=People,dc=terracotta,dc=org"
authzIdentity=controlRole
useSSL=false
bindDn="cn=Manager"
bindCredential="****"
bindAuthenticationType="simple"
debug=true;
};
Save the file .java.login.config to the directory named in the Java property user.home.
Add the following configuration to each <server> block in the Terracotta configuration file:
<server host="myHost" name="myServer">
...
<authentication>
<mode>
<login-config-name>Terracotta</login-config-name>
</mode>
</authentication>
...
</server>
Start the Terracotta server and look for a log message containing "INFO - Credentials: loginConfig[Terracotta]" to confirm that LDAP security is in effect.
NOTE: Incorrect Setup
|
If security is set up incorrectly, the Terracotta server can still be started. However, you may not be able to shut down the server using the shutdown script (stop-tc-server) or the Terracotta console.
|
Terracotta can use the standard Java security mechanisms for JMX authentication, which relies on the creation of .access and .password files with correct permissions set. The default location for these files for JDK 1.5 or higher is $JAVA_HOME/jre/lib/management.
To configure security using JMX authentication, follow these steps:
- Ensure that the desired usernames and passwords for securing the target servers are in the JMX password file
jmxremote.password and that the desired roles are in the JMX access file jmxremote.access.
If both jmxremote.access and jmxremote.password are in the default location ($JAVA_HOME/jre/lib/management), add the following configuration to each <server> block in the Terracotta configuration file:
<server host="myHost" name="myServer">
...
<authentication />
...
</server>
If jmxremote.password is not in the default location, add the following configuration to each <server> block in the Terracotta configuration file:
<server host="myHost" name="myServer">
...
<authentication>
<mode>
<password-file>/path/to/jmx.password</password-file>
</mode>
</authentication>
...
</server>
If jmxremote.access is not in the default location, add the following configuration to each <server> block in the Terracotta configuration file:
<server host="myHost" name="myServer">
...
<authentication>
<mode>
<password-file>/path/to/jmxremote.password</password-file>
</mode>
<access-file>/path/to/jmxremote.access</access-file>
</authentication>
...
</server>
File Not Found Error
If the JMX password file is not found when the server starts up, an error is logged stating that the password file does not exist.
Using Scripts Against a Server with Authentication
A script that targets a secured Terracotta server must use the correct login credentials to access the server. If you run a Terracotta script such as backup-data or server-stat against a secured server, pass the credentials using the -u (followed by username) and -w (followed by password) flags.
For example, if Server1 is secured with username "user1" and password "password", you run the server-stat script by entering the following:
UNIX/LINUX
[PROMPT]${TERRACOTTA_HOME}/bin/server-stat.sh -s Server1 -u user1 -w password
MICROSOFT WINDOWS
[PROMPT]%TERRACOTTA_HOME%\bin\server-stat.bat -s Server1 -u user1 -w password
Extending Server Security
Since JMX messages are not encrypted, server authentication does not provide secure message transmission once valid credentials are provided by a listening client. To extend security beyond the login threshold, consider the following options:
- Place Terracotta servers in a secure location on a private network.
- Restrict remote queries to an encrypted tunnel such as provided by SSH or stunnel.
- If using public or outside networks, use a VPN for all communication in the cluster.
- If using Ehcache, add a cache decorator to the cache that implements your own encryption and decryption.
