Securing XDR with access control, LDAP, and TLS
XDR login flowโ
The login flow applies from each source node to each destination node independently. The xdr-client tend thread follows the login process illustrated in these steps:
Establishes the connection from the source node to the destination node.
a. If the connection from the tend thread is successful, logs an info message like the below example:
INFO (xdr-client): (cluster.c:2278) connected to destdc 172.17.0.5:3116
b. If not, retries the connection to the destination node.
Once the connection is established, if access control is configured in the xdr dc sub-stanza, logs in to each destination node.
a. If login is successful, logs an info message:
INFO (xdr-client): (cluster.c:1539) logged in to node 172.17.0.5:3116 - session-ttl 120
b. If login fails, logs warning messages:
WARNING (xdr-client): (cluster.c:1470) login to node 172.17.0.5:3116 failed: 65
WARNING (xdr-client): (cluster.c:1470) (repeated:11) login to node 172.17.0.5:3116 failed: 65Then goes back to Step 1. c. If security is not enabled on the destination node, logs an info message after successfully establishing the connection by the tend thread:
INFO (xdr-client): (cluster.c:1463) security not configured on node 172.17.0.5:3116
Once the login is successful, the access token is refreshed one minute before the
session-ttl
configured on the destination node during the login. Logs an info message:INFO (xdr-client): (cluster.c:1045) refreshing session token for destdc 172.17.0.5:3116
a. If login succeeds during refreshing access token, logs an info message:
INFO (xdr-client): (cluster.c:1539) logged in to node 172.17.0.5:3116 - session-ttl 120
b. If login fails during refreshing access token, logs a warning message:
WARNING (xdr-client): (cluster.c:1470) login to node 172.17.0.5:3116 failed: 65
Then goes back to step 1.
If the connection is broken at any time after successful establishment due to node (source or destination) restart or any other reason, goes back to step 1.
These log items and flow are limited to connections and login by the xdr-client tend thread. They do not include connections by other xdr-client threads.
Authorized user and password fileโ
For either access control or LDAP, if the target cluster has security enabled, add the following parameters to the source cluster configuration:
auth-mode
specifies the mode of authentication.auth-user
specifies the name of a user with read/write permissions on the target cluster. Must be accompanied byauth-password-file
andauth-mode
auth-password-file
parameter to point to a file that contains the password of the username specified inauth-user
. Alternatively, the value ofauth-password-file
can be stored in HashiCorp Vault. See Optional security with Vault integration.- In Aerospike Database 6.4 and later, the value of
auth-password-file
can be fetched using the Secret Agent. See Integrating with secrets management services.
Make sure this file is adequately secured.
See examples of these parameters in Securing with access control and Securing with LDAP.
Example contents of security configuration file
$ less /private/security-credentials-DC1.txt
passwordOnDestination
Securing with access controlโ
For background on configuring Aerospike's local-to-the-server user access control, see Configuring Access Control.
For an explanation of the auth-user
and auth-password-file
parameters, see Authorized user and password file.
Example DC sub-stanza for access controlโ
xdr {
dc dataCenter1 {
node-address-port someIpAdress1 somePort1
...
auth-mode internal
auth-user somebodyOnDestination1
# auth-user must be accompanied by auth-password-file
auth-password-file /private/security-credentials-DC1.txt
namespace someNamespace {
...
}
}
dc dataCenter2 {
node-address-port someIpAdress2 somePort2
...
auth-mode internal
auth-user somebodyOnDestination2
# auth-user must be accompanied by auth-password-file
auth-password-file /private/security-credentials-DC2.txt
namespace someNamespace {
...
}
}
}
Securing with access control using PKI (versions 5.7+)โ
The following example secures the connection with a TLS certificate and uses the common name (CN) in the certificate as username to authenticate at the destination cluster. No need to specify password in this mode as the TLS certificate validity authenticates the user.
xdr {
dc dataCenter1 {
node-address-port someIpAdress1 somePort1 someTlsNameDefinition1
tls-name localTls
auth-mode pki
namespace someNamespace {
...
}
}
...
}
Securing with LDAPโ
For background about configuring LDAP, see Configuring LDAP.
- For an explanation of the
auth-user
andauth-password-file
parameter, see Authorized user and password file. - If you are using LDAP authentication, the
auth-mode
parameter must be set toexternal
.
Example dc sub-stanza for LDAP with auth-mode external
xdr {
dc dataCenter1 {
node-address-port someIpAdress1 somePort1
...
auth-mode external
auth-user somebodyOnDestination1
auth-password-file /private/security-credentials-DC1.txt
namespace someNamespace {
...
}
}
}
Securing with TLSโ
Consider implementing TLS among the cluster nodes. For details, see TLS Configuration.
- TLS is configured in the
tls
stanza of the configuration file. This stanza defines variable names based on TLS certificates. In this example for XDR, the variable namessomeTlsNameDefinition...
andlocalTls
are variable references to TLS certificates you have installed on your system and configured in thetls
stanza. - The
xdr
stanza only refers to those TLS variable name definitions. - Those TLS variable name definitions come after the port number of the
node-address-port
parameter.
The following example secures the connection with a TLS certificate and with LDAP user authentication auth-mode external
.
xdr {
dc dataCenter1 {
node-address-port someIpAdress1 somePort1 someTlsNameDefinition1
tls-name localTls
auth-mode external
auth-user somebodyOnDestination1
auth-password-file /private/security-credentials-DC1.txt
namespace someNamespace {
...
}
}
...
}