Skip to main content
Secrets store sensitive data such as passwords, OAuth tokens, SSH keys, and TLS certificates. Unlike ConfigMaps, Secrets are designed for confidential information and can be encrypted at rest.

​
Key Concepts

Secret

A Kubernetes resource that stores sensitive data as base64-encoded key-value pairs.

Type

Secret type indicates the intended use (Opaque, TLS, Docker, etc.) and may enforce required keys.

Data

Base64-encoded key-value pairs containing the actual secret values.

stringData

Plain text values that are automatically base64-encoded when the Secret is created.

​
Required Permissions

ActionPermission
View secretsiam:project:infrastructure:kubernetes:read
Create secretiam:project:infrastructure:kubernetes:write
Edit secretiam:project:infrastructure:kubernetes:write
Delete secretiam:project:infrastructure:kubernetes:delete
Secret data is masked in the list view for security. Click on a Secret to view the actual (base64-encoded) values in the detail view.

​
Secret Types

TypeLabelDescription
OpaqueOpaqueGeneric secret for arbitrary data (default)
kubernetes.io/tlsTLSTLS certificate and private key
kubernetes.io/dockerconfigjsonDockerDocker registry credentials
kubernetes.io/dockercfgDockerLegacy Docker registry credentials
kubernetes.io/service-account-tokenSA TokenServiceAccount token (auto-generated)
kubernetes.io/basic-authBasic AuthUsername and password
kubernetes.io/ssh-authSSHSSH private key
bootstrap.kubernetes.io/tokenBootstrapBootstrap token for node joining
helm.sh/release.v1HelmHelm release metadata

​
How to View Secrets

1

Select Cluster

Choose a cluster from the cluster dropdown.
2

Select Namespace

Choose a namespace or select “all” to view Secrets across all namespaces.
3

Search

Use the search box to find Secrets by name, namespace, or type.

​
How to View Secret Details

1

Find the Secret

Locate the Secret in the list.
2

Click Secret Name

Click on the Secret name to open the detail drawer.
3

Review Details

View Secret information including:
  • Overview: Name, namespace, type, key count, size, age
  • Data: Base64-encoded values (can be decoded)
  • Labels & Annotations: Metadata attached to the Secret
  • Events: Recent Kubernetes events
Secret values in the detail view are base64-encoded. Decode them with echo "<value>" | base64 -d to see the actual content.

​
How to Create a Secret

1

Click Create Secret

Click the Create Secret button in the page header.
2

Write YAML

Enter the Secret manifest in YAML format. Key fields:
  • type - Secret type (defaults to Opaque)
  • data - Base64-encoded key-value pairs
  • stringData - Plain text values (auto-encoded)
3

Select Namespace

Choose the target namespace for the Secret.
4

Create

Click Create to apply the manifest.
Use stringData instead of data when creating Secrets manually - Kubernetes automatically base64-encodes the values.

​
How to Edit a Secret

1

Open Actions Menu

Click the actions menu (three dots) on the Secret row.
2

Click Edit Secret

Select Edit Secret to open the YAML editor.
3

Modify Data

Edit the Secret content. You can:
  • Update existing values
  • Add new keys
  • Change the type (with caution)
4

Save

Click Update to apply changes.
Like ConfigMaps, updating a Secret does not automatically restart pods. Pods must be restarted to pick up new Secret values.

​
How to Delete a Secret

1

Open Actions Menu

Click the actions menu on the Secret row.
2

Click Delete

Select Delete from the menu.
3

Confirm

Confirm the deletion. Pods referencing this Secret may fail.
Deleting a Secret that is mounted by running pods or used for image pull credentials will cause those pods to fail. Ensure no pods depend on the Secret before deletion.

​
Using Secrets in Pods

​
As Environment Variables

spec:
  containers:
    - name: app
      envFrom:
        - secretRef:
            name: app-secrets
      # Or individual keys:
      env:
        - name: DATABASE_PASSWORD
          valueFrom:
            secretKeyRef:
              name: app-secrets
              key: db-password

​
As Volume Mounts

spec:
  containers:
    - name: app
      volumeMounts:
        - name: secret-volume
          mountPath: /etc/secrets
          readOnly: true
  volumes:
    - name: secret-volume
      secret:
        secretName: app-secrets

​
For Image Pull

spec:
  imagePullSecrets:
    - name: docker-registry-secret

​
Creating Common Secret Types

​
TLS Secret

apiVersion: v1
kind: Secret
metadata:
  name: tls-secret
type: kubernetes.io/tls
data:
  tls.crt: <base64-encoded-cert>
  tls.key: <base64-encoded-key>
Or use kubectl: 
kubectl create secret tls tls-secret --cert=cert.pem --key=key.pem

​
Docker Registry Secret

apiVersion: v1
kind: Secret
metadata:
  name: docker-secret
type: kubernetes.io/dockerconfigjson
data:
  .dockerconfigjson: <base64-encoded-docker-config>
Or use kubectl: 
kubectl create secret docker-registry docker-secret \
  --docker-server=registry.example.com \
  --docker-username=user \
  --docker-password=pass

​
Basic Auth Secret

apiVersion: v1
kind: Secret
metadata:
  name: basic-auth
type: kubernetes.io/basic-auth
stringData:
  username: admin
  password: secretpassword

​
Troubleshooting

  • Verify the Secret exists in the same namespace as the pod
  • Check Secret name spelling in pod spec
  • Ensure referenced keys exist in the Secret
  • Use optional: true if Secret might not exist
  • Verify imagePullSecrets is configured on the pod or ServiceAccount
  • Check the Docker Secret contains valid credentials
  • Ensure the Secret type is kubernetes.io/dockerconfigjson
  • Verify the registry URL in the Secret matches the image registry
  • Ensure type is kubernetes.io/tls
  • Verify keys are exactly tls.crt and tls.key
  • Check certificate and key are valid and match
  • Ensure values are base64-encoded
  • Values must be base64-encoded in data field
  • Use stringData for plain text (auto-encoded)
  • Don’t double-encode values
  • Verify encoding with echo "<value>" | base64 -d
  • Pods don’t automatically reload Secrets
  • Restart the deployment/pod to pick up changes
  • Volume-mounted Secrets eventually update (kubelet sync)
  • Environment variables from Secrets never auto-update
  • List view masks data for security (shows ***)
  • Click the Secret name to view actual values in detail view
  • YAML view shows base64-encoded data

​
FAQ

By default, Secrets are only base64-encoded, not encrypted. For true security, enable encryption at rest in your cluster and use RBAC to restrict access. Consider external secret managers (Vault, AWS Secrets Manager) for highly sensitive data.
data expects base64-encoded values. stringData accepts plain text and automatically encodes it. Use stringData when creating Secrets manually for convenience.
No. Secrets are namespace-scoped. A pod can only reference Secrets in its own namespace. For shared secrets, create copies in each namespace or use external secret management.
Secret types help Kubernetes validate required keys and enable specific functionality. For example, kubernetes.io/tls requires tls.crt and tls.key, and kubernetes.io/dockerconfigjson is recognized by kubelet for image pulls.
Update the Secret with new values, then restart pods that use it. For zero-downtime rotation, consider using external secret managers with automatic rotation support.
Secrets are limited to 1 MiB, same as ConfigMaps. For larger data, consider external storage or splitting into multiple Secrets.
Never commit plain Secrets to version control. Use sealed-secrets, SOPS, or external secret managers to safely store encrypted secret references in Git.
Kubernetes automatically creates kubernetes.io/service-account-token Secrets for ServiceAccounts. These contain tokens for authenticating to the API server.