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

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
```

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

Use kubectl to apply the change.
Terminal window
```
kubectl apply -f aerospike-cluster.yaml
```

Create a Secret for a password

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'
```
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
```
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.

Identify the mounted Secret.

kubectl get aerospikecluster CLUSTER_NAME -o jsonpath='{.spec.storage.secrets[*].secretName}'
# example output → aerospike-license

Create or obtain the password file.
Terminal window
```
echo "password" > xdr-password.txt
```

Convert the file to a base64 representation and patch the Secret.

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

Verify the file is present inside a pod.

kubectl exec -it <pod> -- \
  ls /etc/aerospike/secrets/aerospike-license/xdr-password.txt

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

kubectl apply -f aerocluster.yaml

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"
```

Confirm XDR is active.

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.