Access control for Aerospike on Kubernetes

Enable security

To use Aerospike access control, you must enable security for the Aerospike clusters.

Enable security for your Aerospike clusters in the aerospikeConfig section of the custom resource (CR) file like so:

aerospikeConfig:
  ...
security: {}
  ...

Aerospike Access Control includes user, role, and privilege creation and maintenance. See the Aerospike Database documentation section for more information on Aerospike Access Control.

To manage your access controls from AKO, configure the spec.aerospikeAccessControl section in the Aerospike cluster’s CR file.

Caution

Access control changes on an AKO-managed Aerospike cluster must be made through modifying the CR file. Any changes made externally (such as by using aql or asadm) will revert to the values in the CR file.

Disable security

You can disable security on a running Aerospike cluster. This is useful when you need to temporarily remove authentication requirements from the cluster.

Danger

Disabling security removes all authentication and authorization controls from your Aerospike cluster. This means anyone with network access to the cluster can read, write, or modify data without credentials. Only disable security in development or testing environments, or when you have other network-level security controls in place.

Steps to disable security

To disable security in a running cluster, remove the security section from aerospikeConfig:

spec:
  ...
  # Keep the aerospikeAccessControl section - it cannot be removed once set
  aerospikeAccessControl:
    users:
      - name: admin
        secretName: auth-secret
        roles:
          - sys-admin
          - user-admin

  aerospikeConfig:
    ...
    # Remove the security section to disable security
    # security: {}
    ...

Apply the changes:

kubectl apply -f aerospike-cluster.yaml

Important behavior notes

• aerospikeAccessControl cannot be removed: Once aerospikeAccessControl is configured, it cannot be removed from the CR. AKO validates this and rejects any attempt to remove it.

• Users persist in the server: When security is disabled, all configured users remain stored in the Aerospike server. They are not deleted.

• Users are resurrected on re-enable: When security is re-enabled, the existing users are automatically resurrected and become active again.

Re-enabling security

When re-enabling security on a cluster that previously had security disabled:

Caution

Do not modify user credentials outside of AKO while security is disabled. When security is re-enabled, AKO reconciles the access control configuration from the CR. If credentials were changed externally, authentication failures may occur during the re-enable process.

To re-enable security, add the security section back to aerospikeConfig:

spec:
  ...
  aerospikeAccessControl:
    users:
      - name: admin
        secretName: auth-secret
        roles:
          - sys-admin
          - user-admin

  aerospikeConfig:
    ...
    security: {}
    ...

Example access control tasks

Create or delete a role

Add a role in the roles list under spec.aerospikeAccessControl.

sys-admin and user-admin are standard predefined roles. Here we add a new custom role called profiler, which has read privileges.

spec:
  ...
  aerospikeAccessControl:
    roles:
      - name: profiler
        privileges:
          - read
    users:
      - name: admin
        secretName: auth-secret
        roles:
          - sys-admin
          - user-admin

To remove an existing role, delete it from the roles category.

Save and exit the CR file, then use kubectl to apply the change.

kubectl apply -f aerospike-cluster.yaml

Add or remove privileges to a role

Under privileges for a certain role under spec.aerospikeAccessControl, add any additional privileges on new lines. Here we add read-write to the profiler role. Remove a privilege from the list under a role to remove the privilege from that role.

spec:
  ...
  aerospikeAccessControl:
    roles:
      - name: profiler
        privileges:
          - read
          - read-write
    users:
      - name: admin
        secretName: auth-secret
        roles:
          - sys-admin
          - user-admin

Save and exit the CR file, then use kubectl to apply the change.

kubectl apply -f aerospike-cluster.yaml

Privilege scope

To scope privileges to a namespace or set, add the following to the profiler role in the roles list under spec.aerospikeAccessControl.

The order of the scope syntax is: privilege.namespace.set.

• To scope a read privilege to a namespace called test-namespace, add the privilege as read.test-namespace
• To scope a read-write privilege to a set called test-set on a different namespace called test-namespace-1, add the privilege as read-write.test-namespace-1.test-set

spec:
  ...
  aerospikeAccessControl:
    roles:
      - name: profiler
        privileges:
          - read.test-namespace
          - read-write.test-namespace-1.test-set
    users:
      - name: admin
        secretName: auth-secret
        roles:
          - sys-admin
          - user-admin

Save and exit the CR file, then use kubectl to apply the change.

kubectl apply -f aerospike-cluster.yaml

Create or delete a user

Password based user (auth-mode=Internal)

Create the secret for the user and add the user in the users list under spec.aerospikeAccessControl.

Create a secret profile-user-secret containing the password for the user profiler by passing the password from the command line:

kubectl  -n aerospike create secret generic profile-user-secret --from-literal=password='userpass'

Add profileUser user with the profiler role.

spec:
  ...
  aerospikeAccessControl:
    roles:
      - name: profiler
        privileges:
          - read
    users:
      - name: profileUser
        authMode: Internal
        secretName: profile-user-secret
        roles:
          - profiler

      - name: admin
        authMode: Internal
        secretName: auth-secret
        roles:
          - sys-admin
          - user-admin

PKI only user (auth-mode=PKIOnly)

For PKI only user, set the authMode to PKIOnly. When using PKIOnly authentication:

• The user authenticates using TLS client certificates where the certificate’s Common Name (CN) matches the username.
• Password-based authentication is disabled for the user.
• The secretName field is no longer required since password authentication is disabled.

spec:
  ...
  aerospikeAccessControl:
    roles:
      - name: profiler
        privileges:
          - read
    users:
      - name: profileUser
        authMode: PKIOnly
        roles:
          - profiler

      - name: admin
        authMode: PKIOnly
        roles:
          - sys-admin
          - user-admin

To remove a user, delete the entry from the users category.

Save and exit the CR file, then use kubectl to apply the change.

kubectl apply -f aerospike-cluster.yaml

Add or remove user roles

Add or remove roles in the desired user’s roles list.

Here we add user-admin and sys-admin to the profileUser roles list.

spec:
  ...
  aerospikeAccessControl:
    roles:
      - name: profiler
        privileges:
          - read
    users:
      - name: profileUser
        secretName: profile-user-secret
        roles:
          - profiler
          - user-admin
          - sys-admin

      - name: admin
        secretName: auth-secret
        roles:
          - sys-admin
          - user-admin

Save and exit the CR file, then use kubectl to apply the change.

kubectl apply -f aerospike-cluster.yaml

Change a user’s authentication mode to PKI-Only

Change a user’s authentication mode from Internal to PKIOnly to enforce certificate-based authentication only. This is useful for environments requiring stricter security controls or FIPS compliance.

Note

Before enabling PKIOnly authentication mode, ensure your Aerospike cluster has mutual TLS (mTLS) enabled. PKI-Only authentication requires client certificate verification to authenticate users. See Manage TLS Certificates for details on configuring TLS.

Caution

Once a user’s authMode is set to PKIOnly, it cannot be reverted to Internal. This change is permanent.

To change a user’s authentication mode, set the authMode to PKIOnly and remove the secretName field since password authentication is disabled:

spec:
  ...
  aerospikeAccessControl:
      - name: admin
        authMode: PKIOnly
        roles:
          - sys-admin
          - user-admin

Save and exit the CR file, then use kubectl to apply the change.

kubectl apply -f aerospike-cluster.yaml

Change a user’s password

Once a secret has been created, it cannot be changed. To change an existing password, create an entirely new secret and assign it to the user in place of the old secret.

Create a new secret new-profile-user-secret containing the password for Aerospike cluster user profileUser by passing the password from the command line:

kubectl  -n aerospike create secret generic new-profile-user-secret --from-literal=password='newuserpass'

Update the secretName for profileUser to the new secret name new-profile-user-secret.

spec:
  ...
  aerospikeAccessControl:
    roles:
      - name: profiler
        privileges:
          - read
    users:
      - name: profileUser
        secretName: new-profile-user-secret
        roles:
          - profiler
          - user-admin

      - name: admin
        secretName: auth-secret
        roles:
          - sys-admin
          - user-admin

Save and exit the CR file, then use kubectl to apply the change.

kubectl apply -f aerospike-cluster.yaml