# Use Kubernetes Secrets for Aerospike on Kubernetes

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 [TLS certificates for Aerospike on Kubernetes](https://aerospike.com/docs/kubernetes/4.1.x/manage/security/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
    
    ```shell
    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`.
    
    ```yaml
    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
    
    ```shell
    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
    
    ```shell
    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:
    
    ```yaml
    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
    
    ```shell
    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 of the Aerospike process. 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 the Aerospike process inside all pods.

### Example: Enable XDR without a cold start

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

1.  Identify the mounted Secret.
    
    Terminal window
    
    ```bash
    kubectl get aerospikecluster CLUSTER_NAME -o jsonpath='{.spec.storage.secrets[*].secretName}'
    
    # example output → aerospike-license
    ```
    
2.  Create or obtain the password file.
    
    Terminal window
    
    ```bash
    echo "password" > xdr-password.txt
    ```
    
3.  Convert the file to a base64 representation and patch the Secret.
    
    Terminal window
    
    ```bash
    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 start
    ```
    
4.  Verify the file is present inside a pod.
    
    Terminal window
    
    ```bash
    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.
    
    ```yaml
    spec:
    
      aerospikeConfig:
    
        xdr:
    
          enable: true
    
          auth-password-file: /etc/aerospike/secrets/aerospike-license/xdr-password.txt
    ```
    
    Terminal window
    
    ```bash
    kubectl apply -f aerocluster.yaml
    ```
    
6.  Examine the logs to see a _warm_ Aerospike process restart only. The `pod container ID` and `start-time` should remain unchanged.
    
    Terminal window
    
    ```bash
    kubectl logs -f <pod> -c aerospike | grep -E "config-set|warm start"
    ```
    
7.  Confirm XDR is active.
    
    Terminal window
    
    ```bash
    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 of the Aerospike process.