Aerospike Database Enterprise Edition (EE) has a role-based access control (RBAC) system that supports several authentication modes. These authentication modes can be used separately or concurrently.
Administrators can either create internal users in the Aerospike server itself, assigning roles to them, or use an external LDAP system for authentication and authorization.
Configuring Access Control
For configuration instructions see Configuring Access Control.
Types of authentication
Aerospike EE supports the following types of authentication:
- Password-based authentication for internal users defined in the server itself.
- Public Key Infrastructure (PKI) authentication for internal users, using mutually-authenticated TLS certificates (mTLS).
- External authentication using an LDAP server.
Using Federal Edition (FE)
When using the FIPS 140-2 compliant Aerospike Enterprise Edition for United States Federal (AKA Federal Edition or FE), password-based authentication is disabled. Use PKI authentication or external LDAP authentication
Compatible client required for Aerospike EE 4.6
When access control is enabled with Aerospike EE versions 4.6 or later, a feature-compatible Aerospike client is required. See the list of compatible client versions.
Compatible Aerospike EE servers required for XDR
When access control is enabled with Cross-Datacenter Replication (XDR), a cluster with Aerospike EE 22.214.171.124 to 126.96.36.199 cannot ship to an Aerospike EE server 4.6 or later. The simplest workaround is to avoid using incompatible Aerospike EE versions (188.8.131.52 to 184.108.40.206). Refer to this support article for more information.
Access Control Features by Aerospike Database versions
- Aerospike EE version 6.3 removed the
syslogsubcontext of the
securityconfig context. Audit trail messages can be sent to any log sink type (
syslog) that is defined in the
- Aerospike FE version 6.0 is FIPS 140-2 compliant
- Aerospike EE version 5.7 added support for PKI authentication.
- Aerospike EE version 5.6 added the ability to limit user activity by setting rate quotas on reads and writes. See Rate Quotas for more details.
- Aerospike EE version 5.1 expanded the write privileges (
read-write-udf) to include permission to run the truncate command within scope.
- Aerospike EE version 4.7 added LDAP support for XDR.
- Aerospike EE version 4.6 added the
write(write only) privilege for use in defining custom roles, and added support for specifying network allowlists on these roles. External user authentication with LDAP is mutually exclusive with auth for internal users.
Authentication for internal users
Users created within Aerospike EE (internal users) can either use password-based authentication, or mTLS-based PKI authentication.
The administrator creates users of the Aerospike cluster with a username, password, and optionally, a role assignment.
The developer configures the client to use the
INTERNAL auth mode, and
provides a username and password. The client sends the username and a hash of
the user's password, to be matched against the one stored in the Aerospike cluster.
This is the default authentication mode of the clients.
PKI authentication is an alternative authentication mode for internal users. As with any internal user, the administrator first creates the user with a username and a strong random password. If a user is restricted to only PKI mTLS-based access, the administrator does not communicate a password to them. The Aerospike EE cluster nodes must be configured to check the client's TLS certificate.
The developer sets the client to use the
PKI auth mode, and
configures it for mTLS (refer to Managing mTLS with a Java client).
CN field of the Subject DN must contain the username of this user. The
user's certificate must be signed by the server's root CA.
External authentication with LDAP
An Aerospike Database cluster which has LDAP enabled supports authentication against an external LDAP server, without matching internal users. Currently, internal users cannot use LDAP authentication. An internal user (one that was created in the Aerospike Database cluster and given a username and password) can only use the access control modes described earlier (password-based or PKI auth).
The developer sets the client to use the
EXTERNAL auth mode, and provides a
username and password. The Aerospike server authenticates these credentials
against the external LDAP server. Authorization happens when the Aerospike
server querying the LDAP server for the user's roles. Roles that match local
role names are assigned to the user, granting the privileges associated
with these roles.
Aerospike Database caches a local copy of successful authentication and authorization. This local directory is distributed to every cluster node for lower query latency and reduced load on the LDAP server. The external LDAP server is queried on a configurable polling period for changes to the user's access.
For specific instructions, refer to Configuring LDAP.
TLS encryption between the client and server should be enabled when external authentication is used, since the external LDAP server needs a cleartext password forwarded to it.
Regardless of the authentication mode, if the authentication succeeds, an access token
is returned to the client. The client uses the access token on subsequent
TCP connections, until the session it is associated with expires. See the
The password sent by the client for any mode (password-based or LDAP) is never stored in cleartext on the Aerospike server.