Skip to main content
Loading

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 does the login process.

  1. Establish the connection from the source node to the destination node.

    a. If the connection from tend thread is successful, log an info message like the below example:

    INFO (xdr-client): (cluster.c:2278) connected to destdc 172.17.0.5:3116

    b. Else retry the connection to the destination node.

  2. Once the connection is established, if access control is configured in the xdr dc sub-stanza, login to each destination node.

    a. If login is successful, log an info message like the below example:

    INFO (xdr-client): (cluster.c:1539) logged in to node 172.17.0.5:3116 - session-ttl 120

    b. If login fails, log warning messages like the below example and go back to step 1:

    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: 65

    c. If security is not enabled on the destination node, log an info message like the below example 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
  3. Once the login is successful, the access token will get refreshed one minute before the session-ttl configured on the destination node during the login. Log an info message like the below example:

    INFO (xdr-client): (cluster.c:1045) refreshing session token for destdc 172.17.0.5:3116

    a. If login succeeds during refreshing access token, log an info message like the below example:

    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, log a warning message like the below example and go back to step 1:

    WARNING (xdr-client): (cluster.c:1470) login to node 172.17.0.5:3116 failed: 65
  4. If the connection is broken at any time after successful establishment due to nodes (source or destination) restart or any other reason, go back to step 1.

note

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, on the source cluster add the following parameters:

Make sure this file is adequately secured.

See examples of this parameter 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 is used to authenticate 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 and auth-password-file parameter is, see Authorized user and password file.
  • As of Aerospike version 4.7, if you are using LDAP authentication, the auth-mode parameter should be set to external.
note

Aerospike strongly recommends that you do not set auth-mode to external-insecure.

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 names someTlsNameDefinition... and localTls are variable references to TLS certificates you have installed on your system and configured in the tls 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 {
...
}
}
...
}