Create and Sync Secrets

Create a secret, sync it to a cluster, and consume it from a workload.

Prerequisites

A Kupe Cloud tenant with at least one running cluster.
Tenant admin access in the console.

Step 1: Open the Secrets page

In the console, sign in as a tenant admin and click Secrets in the sidebar. This shows all secrets owned by your tenant across all clusters.

The table shows each secret’s name, the number of sync targets, and per-cluster sync status.

Step 2: Create the secret and add sync targets

Click Create Secret.
Enter a name for the secret (e.g., db-credentials). This becomes the Kubernetes Secret name in your cluster.
Add one or more key-value pairs:
- Key: the data key (e.g., url, username, password)
- Value: the sensitive value, entered as plain text and stored encrypted
In Sync Targets, add one or more target clusters.
For each target, select the namespace where the secret should be synced (for example backend, app, or default).
Click Create Secret.

The secret is stored in the platform vault, encrypted and isolated to your tenant, and Kupe starts syncing it to the selected targets immediately.

You can add multiple sync targets during creation if the same secret should be available in more than one cluster or namespace.

Step 3: Confirm sync status

After creation, the secret row shows each target and its sync status. A target moving to Synced means the Kubernetes Secret has been written into that cluster and namespace.

If you need to add more targets later, open the secret and edit Sync Targets from the management dialog.

Step 4: Verify the secret in your cluster

Once a sync target shows Synced status, the secret exists as a Kubernetes Secret in the selected cluster namespace.

Verify with kubectl:

kubectl get secret db-credentials -n backend

Expected output:

NAME              TYPE     DATA   AGE
db-credentials    Opaque   3      45s

Check the keys (values are base64-encoded):

kubectl get secret db-credentials -n backend -o jsonpath='{.data}' | jq

{
  "url": "cG9zdGdyZXM6Ly8uLi4=",
  "username": "YWNtZS1hcHA=",
  "password": "c3VwZXJzZWNyZXQ="
}

Step 5: Use the secret in a workload

Reference the secret in your deployment manifest. For example, inject as environment variables:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
  namespace: backend
spec:
  template:
    spec:
      containers:
        - name: app
          image: my-app:latest
          env:
            - name: DATABASE_URL
              valueFrom:
                secretKeyRef:
                  name: db-credentials
                  key: url
            - name: DB_USERNAME
              valueFrom:
                secretKeyRef:
                  name: db-credentials
                  key: username
            - name: DB_PASSWORD
              valueFrom:
                secretKeyRef:
                  name: db-credentials
                  key: password

Or mount as files:

spec:
  template:
    spec:
      containers:
        - name: app
          volumeMounts:
            - name: creds
              mountPath: /etc/secrets
              readOnly: true
      volumes:
        - name: creds
          secret:
            secretName: db-credentials

Deploy via your normal GitOps workflow. The secret is already in the namespace, so Argo CD does not need to manage it.

Updating a secret

In the console, click Edit on the secret row.
Modify key-value pairs: add, remove, or update values.
Click Save.

Editing a value is slower than you might expect. Creating a secret or adding a sync target reaches the cluster in seconds, but editing the value of an already-synced secret can take up to 15 minutes: the sync definition itself hasn’t changed, so the platform only picks the new value up on its next scheduled re-read of the vault. There is no force-sync trigger.

Once the new value does land in the cluster, workloads that mount it as a volume pick it up within about a minute (the kubelet’s own sync interval); workloads using environment variables need a pod restart. Check the cluster secret itself before restarting anything; a restart does not help while the cluster still holds the old value.

Removing a sync target

Expand the secret row and click Remove on the sync target. This stops future syncing to that cluster and namespace, but the Kubernetes Secret already created there is left in place: the platform retains it rather than deleting it. Remove it yourself if you want it gone. Other sync targets are unaffected.

Deleting a secret

Click Delete on the secret row. This:

Removes the secret from the platform vault.
Does not automatically delete Kubernetes Secret objects that were already synced to clusters.
Cannot be undone. There is no soft-delete.

Troubleshooting

Sync status shows “Pending”

The platform is waiting for the first sync to complete. This normally clears within a minute or so of creating the target. If it persists:

Verify the target cluster is in Running state.
Check that the target namespace exists in the cluster (the platform does not auto-create namespaces).

Sync status shows “Failed”

Expand the sync target to see the error message. Common causes:

Namespace not found: create the namespace in your cluster first.
Secret name conflict: a secret with the same name already exists in that namespace and was not created by the platform. Rename your secret or clean up the existing one.

Secret values are stale

The most common cause is the refresh interval: the platform re-reads the vault every 15 minutes, so a recently-changed value may not have reached the cluster yet. Deleting the secret in your cluster does not speed this up: it is a mirror, and it is restored with the same value it already had. Check the cluster secret itself (kubectl get secret <name> -o yaml) before assuming a workload problem. Once the cluster secret is current, volume mounts pick it up within about a minute and environment variables need a pod restart, which kubectl rollout restart covers for both.