Secrets Overview

At some point you’ll need to pass a password, connection string, API token, or other sensitive value into a pod (or multiple pods). In Kubernetes, that object is called a Secret. Secrets are intended for small pieces of sensitive data such as:

Passwords
API keys or tokens
Database connection strings
Usernames or short configuration strings (it can even be a simple hello world string)

You can store essentially any small piece of sensitive data as a Secret.

Key facts about Kubernetes Secrets

Default type: Opaque.
Storage: Secret data is stored in the API as base64-encoded values. Base64 is an encoding, not encryption.
Persistence: Secret objects are stored in etcd.
Access: Anyone with direct etcd access or API access with sufficient RBAC privileges can read them unless you enable encryption or restrict access.

For production clusters you should enable Kubernetes encryption at rest (for example, envelope encryption of secrets in etcd) or integrate an external secrets manager such as HashiCorp Vault, AWS Secrets Manager, or Azure Key Vault. Even when using an external manager, understanding how Kubernetes Secrets work and how to create and consume them is important. When a Secret is made available to a pod (mounted as files or injected as environment variables), the secret data is presented to the container in plain text at runtime. Because of these trade-offs, many production deployments combine Kubernetes Secrets with encryption at rest, strict RBAC, audit logging, and external secret managers.

Treat Kubernetes Secrets as sensitive. By default they are base64-encoded only. For production, enable encryption at rest and/or use an external secrets manager (Vault, AWS Secrets Manager, Azure Key Vault, etc.).

Common ways to create and consume Secrets

Create a Secret from literals (CLI)

# Create a generic secret with a single key "password"
kubectl create secret generic my-secret --from-literal=password='s3cr3t'

Create a Secret from files (CLI)

# Create a TLS-style Secret from certificate and key files
kubectl create secret tls tls-secret --cert=path/to/tls.crt --key=path/to/tls.key

# Or a generic secret from files, mapping filenames to keys
kubectl create secret generic app-creds --from-file=username=./username.txt --from-file=password=./password.txt

Secret manifest (YAML)

apiVersion: v1
kind: Secret
metadata:
  name: my-secret
type: Opaque
data:
  # values must be base64-encoded
  username: bXktdXNlcg==
  password: c3VwZXItc2VjcmV0

Inspecting and decoding secrets

# View secret metadata and base64-encoded values
kubectl get secret my-secret -o yaml

# Decode a value locally
echo 'c3VwZXItc2VjcmV0' | base64 --decode

How pods consume Secrets

Environment variables (individual keys)

apiVersion: v1
kind: Pod
metadata:
  name: secret-env-pod
spec:
  containers:
    - name: app
      image: busybox
      command: ["sh", "-c", "echo SECRET_USERNAME=$SECRET_USERNAME; sleep 3600"]
      env:
        - name: SECRET_USERNAME
          valueFrom:
            secretKeyRef:
              name: my-secret
              key: username

Environment variables (all keys from a secret)

envFrom:
  - secretRef:
      name: my-secret

Mounted as files (volume)

volumes:
  - name: secret-vol
    secret:
      secretName: my-secret
containers:
  - name: app
    image: busybox
    volumeMounts:
      - name: secret-vol
        mountPath: /etc/secret
        readOnly: true

When mounted, each key becomes a file under /etc/secret/<key> containing the decoded value. Security considerations and best practices

Do not store secrets in container images, Git repositories, or plain-text manifests checked into source control.
Restrict access to Secrets via RBAC and audit access to the API server and etcd.
Prefer type: kubernetes.io/tls for TLS artifacts and type: dockerconfigjson for image pull secrets—use specific types when applicable.
Use encryption at rest for secrets in etcd: https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/
Consider external secret management (Vault, AWS Secrets Manager, Azure Key Vault) for centralized lifecycle, rotation, and fine-grained access control.

Quick reference table

Topic	Purpose	Example/Command
Create from literal	Quick secret creation	`kubectl create secret generic my-secret --from-literal=password='s3cr3t'`
Create from file	Use existing files	`kubectl create secret generic app-creds --from-file=./creds`
TLS secret	Store certificate + key	`kubectl create secret tls tls-secret --cert=crt --key=key`
Inspect secret	View encoded values	`kubectl get secret my-secret -o yaml`
Decode value	Convert base64 to plain	`echo 'cGFzc3dvcmQ=' \| base64 --decode`

Secrets are only base64-encoded in the API by default—not encrypted. Without encryption at rest or an external secrets manager, Secrets stored in etcd can be read by anyone with sufficient privileges. Do not treat default Secrets as fully secure.

Next steps The following demo shows how to create Secrets and how they are consumed by pods — including examples for CLI, YAML manifests, and runtime consumption patterns. For more details, see the Kubernetes documentation on Secrets: https://kubernetes.io/docs/concepts/configuration/secret/

Introduction

Pre-Requisite – Docker and Kubernetes

Getting Started with OpenShift

OpenShift Concepts – Projects and Users

Concepts – Builds and Deployments

Networks, Services, Routes and Scaling

Storage, Templates and Catalog

OpenShift Security

Conclusion and APPENDIX

Watch Video