Skip to content

Use Kubernetes Secrets for Aerospike on Kubernetes

Overview

Kubernetes Secrets let you store sensitive data with less risk of exposing the information publicly. You can create Secrets to set up Aerospike authentication, TLS, and your features.conf feature-key file. See Manage-TLS-Certificates for more details.

Create a Secret for a folder

  1. To create a Kubernetes Secret for connectivity to the Aerospike cluster, use the following command to package the Aerospike features.conf in a folder and convert it to a Secret. In this example, the features.conf file is in the config/samples/secrets directory:

    Terminal window
    kubectl -n aerospike create secret generic aerospike-secret --from-file=config/samples/secrets
  2. Update the spec.storage section of the cluster’s Custom Resource (CR) file to include the Secret. If the Secret volume already exists, update the secretName.

    spec:
    ...
    storage:
    filesystemVolumePolicy:
    cascadeDelete: true
    initMethod: deleteFiles
    blockVolumePolicy:
    cascadeDelete: true
    volumes:
    ...
    - name: aerospike-config-secret
    source:
    secret:
    secretName: aerospike-secret
    aerospike:
    path: /etc/aerospike/secret
  3. Use kubectl to apply the change.

    Terminal window
    kubectl apply -f aerospike-cluster.yaml

Create a Secret for a password

  1. Use the following kubectl command to create a Secret that contains the password for the Aerospike cluster admin user.

    Terminal window
    kubectl -n aerospike create secret generic auth-secret --from-literal=password='admin123'
  2. To deploy with AKO, you must include the names of the Secrets for each user in the cluster’s Custom Resource (CR) file.

    For example, suppose that you want to give an admin and an ordinary user access to the Aerospike cluster. In this case, create one Secret named admin-secret and another named user-secret.

    To enable security for the cluster:

    spec:
    ...
    aerospikeAccessControl:
    users:
    - name: admin
    secretName: admin-secret
    roles:
    - sys-admin
    - user-admin
    - name: user
    secret-name: user-secret
    roles:
    - data-admin
  3. Save and exit the CR file, then use kubectl to apply the change.

    Terminal window
    kubectl apply -f aerospike-cluster.yaml

Patch a Secret

You can also patch a Secret with the kubectl patch secret command. This updates the Secret in place without changing the mapping to the Secret in the CR file, and triggers a warm restart. Otherwise, if you mount a new Secret by changing the CR file to point to a new Secret, AKO triggers a rolling cold restart of all pods.

Example: Enable XDR without a cold restart

In the following example, assume you have an existing Kubernetes Secret with your feature-key file. Follow these steps to patch xdr-password.txt to an existing mounted Secret, triggering a warm restart.

  1. Identify the mounted Secret.

    Terminal window
    kubectl get aerospikecluster CLUSTER_NAME -o jsonpath='{.spec.storage.secrets[*].secretName}'
    # example output → aerospike-license
  2. Create or obtain the password file.

    Terminal window
    echo "password" > xdr-password.txt
  3. Convert the file to a base64 representation and patch the Secret.

    Terminal window
    kubectl patch secret aerospike-license \
    --type='merge' \
    -p='{"data":{"xdr-password.txt":"'$(base64 -w 0 xdr-password.txt)'"}}'
    # no new Secret, no change to spec.storage ⇒ no cold restart
  4. Verify the file is present inside a pod.

    Terminal window
    kubectl exec -it <pod> -- \
    ls /etc/aerospike/secrets/aerospike-license/xdr-password.txt
  5. Edit the aerospikeConfig section of the AerospikeCluster CR to enable XDR.

    spec:
    aerospikeConfig:
    xdr:
    enable: true
    auth-password-file: /etc/aerospike/secrets/aerospike-license/xdr-password.txt
    Terminal window
    kubectl apply -f aerocluster.yaml
  6. Examine the logs to see a warm restart only. The pod container ID and start-time should remain unchanged.

    Terminal window
    kubectl logs -f <pod> -c aerospike | grep -E "config-set|warm start"
  7. Confirm XDR is active.

    Terminal window
    kubectl exec -it <pod> -- asinfo -v "get-config:context=xdr"

Because the Secret name, mount path, and volume definitions in spec.storage stay the same, AKO’s storage hash is unchanged. The updated Secret data gets added into the existing volume, letting AKO apply the new XDR configuration with a warm restart.

Feedback

Was this page helpful?

What type of feedback are you giving?

What would you like us to know?

+Capture screenshot

Can we reach out to you?