Kubernetes Secrets and config

A cluster's Secrets & config section holds the Secrets and ConfigMaps your workloads read: database addresses, API keys, settings and the like. Pick a namespace, then the Secrets or the ConfigMaps tab.

Create one

1. Open the cluster's Secrets & config section and pick the namespace.
2. Choose New Secret or New ConfigMap, and give it a name.
3. Add the keys and their values, one row each, or choose Paste a .env file and paste KEY=value lines. A key already in the list takes the pasted value.
4. Choose Create.

Each value fits on one line. Keys and sizes have limits.

Protected Secrets

A new Secret is protected. Once it is saved, the console shows its key names, their sizes and when it last changed, never its values. To change a value, type a new one; a key you leave empty keeps its value.

Turn Protected off to see a Secret's values in the console, behind a reveal for each key. Anyone who may change the Secret can create it unprotected or protect it again. Only a cluster admin can turn protection off on a protected Secret, and the audit log records who did.

Protection hides values in the console. It does not stop someone whose cluster role lets them read Secrets with kubectl: admins and editors can, viewers cannot. See Kubernetes access.

The choice is kept on the Secret itself, as the annotation sahabti.com/protected. A Secret without it counts as protected.

ConfigMaps are not secret, so their values are always shown.

Change or delete one

Choose one in the list to see its keys, then Edit or Delete. Editing adds, replaces or removes keys and leaves the others as they are. A value of several lines, such as a config file, opens in a larger box. A ConfigMap's binary key cannot be typed over, only kept or removed. If someone changed it after you opened it, the console says so and loads the new version, keeping what you typed; save again. Deleting asks you to type confirm.

Pods read Secrets and ConfigMaps when they start. After a change, restart the workloads that use it:

kubectl rollout restart deployment/web

Use it in a Deployment

Each Secret and ConfigMap shows snippets to copy: every key as an environment variable, one key as an environment variable, and every key as a file. Together:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
        - name: web
          image: nginx:1.27-alpine
          envFrom:
            - secretRef:
                name: app-env
            - configMapRef:
                name: app-config
          env:
            - name: API_TOKEN
              valueFrom:
                secretKeyRef:
                  name: app-env
                  key: API_TOKEN
            - name: LOG_LEVEL
              valueFrom:
                configMapKeyRef:
                  name: app-config
                  key: LOG_LEVEL
          volumeMounts:
            - name: app-config
              mountPath: /etc/app-config
              readOnly: true
      volumes:
        - name: app-config
          configMap:
            name: app-config

Who can do what

Every change is made as you, with your role on the cluster. The system namespaces (kube-system, kube-public, kube-node-lease and the two the managed gateway runs in) are not shown here. API keys, connected apps and PromptOps cannot read or change Secrets and ConfigMaps here, so their values never reach an AI provider.

Made elsewhere

Every Secret and ConfigMap in the namespace is listed, also those the console did not make: from Helm, from kubectl, from the cluster itself such as kube-root-ca.crt, and other kinds of Secret such as TLS certificates, service account tokens and registry logins. Each is labelled with where it comes from. The console marks what it makes with the label app.kubernetes.io/managed-by: sahabti-console.

You can edit a ConfigMap or a key/value (Opaque) Secret whatever made it. The editor warns you first: what made it may replace your change, and for Helm that can be your next deploy. Editing keeps its labels and annotations, so it still belongs to Helm or whatever made it. Like any Secret without the annotation, a Secret from elsewhere counts as protected: its values stay hidden, and a key you leave empty keeps its value. The console deletes only what it made, so delete the rest the way it was made.

These stay read-only, so change them the way they were made: kube-root-ca.crt, Helm's own release records, every other kind of Secret, and what the platform manages in the cluster. Helm's release records and kube-root-ca.crt are hidden until you switch on Show system objects above the list.

Limits

What the platform keeps

None of the values. They go from your browser to the cluster's API over encrypted connections, and the platform does not store, cache or log them. The audit log records who created, changed or deleted which Secret or ConfigMap, with its key names and never its values. Like every object in the cluster, Secrets and ConfigMaps are part of the cluster's encrypted state backups, so a deleted one stays in those backups until they expire.