Skip to main content
We are excited to be a part of AWS re:Invent 2024. Visit us at booth #1844 in Las Vegas.More info
Loading

Overview of Access Control with LDAP and PKI

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​

danger

When access control is enabled with Cross-Datacenter Replication (XDR), a cluster with Aerospike EE 4.1.0.1 to 4.3.0.6 cannot ship to an Aerospike EE Database 4.6 or later. The simplest workaround is to avoid using incompatible Aerospike EE versions (4.1.0.1 to 4.3.0.6). Refer to this support article for more information.

Access Control Features by Aerospike Database versions​

  • Aerospike EE version 6.3 removed the syslog subcontext of the security config context. Audit trail messages can be sent to any log sink type (file, console or syslog) that is defined in the logging config context.
  • 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 (write, read-write, 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.

Password-based 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​

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). The 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.

Sessions​

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 session-ttl configuration parameter.

note

The password sent by the client for any mode (password-based or LDAP) is never stored in cleartext on the Aerospike server.

Last updated on