Secrets

Understand Kubernetes Secrets for sensitive configuration, service credentials, TLS material, image pulls, and external secret integration.

Last reviewed: June 2026

·Kubernetes 1.28+kubectl 1.28+Helm 3+Managed Kubernetes: EKS, AKS, GKE
✅
Quick Understanding: A Secret stores sensitive values for Pods, but it still needs encryption, RBAC control, and careful integration with external secret managers.

🔍 What Is It?

A Secret is a namespaced object used for sensitive values such as passwords, tokens, certificates, and image pull credentials.

Secrets can be mounted as files or exposed as environment variables.

🎯 Why Do We Need It?

Applications need credentials without baking them into images or committing them into manifests.

Common developer mistakes:

  • →Treating Kubernetes YAML as copy-paste configuration instead of production architecture
  • →Ignoring requests, limits, health probes, security context, and rollout behavior
  • →Debugging only the Pod while forgetting Services, DNS, NetworkPolicies, nodes, and admission controls
  • →Manually changing live objects without updating Git or infrastructure automation

🏗️ What Happens in Real Projects?

A payments API receives database credentials from a Secret synced from AWS Secrets Manager, Azure Key Vault, or HashiCorp Vault by an external secrets controller. RBAC limits who can read Secrets in the namespace.

⚙️ How It Works

Secrets are stored through the Kubernetes API. Pods reference them through env vars, volumes, service account tokens, TLS references, or imagePullSecrets. In production, secret encryption at rest and external rotation are important.

💻 Example

Secret reference — Using a Secret as environment variables.

yaml
apiVersion: v1
kind: Secret
metadata:
  name: db-credentials
type: Opaque
stringData:
  username: orders_app
  password: replace-with-external-secret
---
env:
  - name: DB_PASSWORD
    valueFrom:
      secretKeyRef:
        name: db-credentials
        key: password

🤔 Common Confusions

❓ Are Kubernetes Secrets encrypted automatically?

They are base64 encoded by manifest format. Encryption at rest must be configured and verified by the platform.

❓ Is base64 encryption?

No. Base64 is encoding, not security.

❓ Should secrets be committed to Git?

Plain secrets should not. Use sealed/encrypted secret workflows or external secret managers.

🚨 Common Production Issues

**Plain Secrets in Git** leak credentials permanently.

**Broad RBAC read access** lets users or workloads read secrets across namespaces.

**No rotation plan** leaves stale credentials in production.

**Secrets as env vars** can appear in process inspection or dumps.

✅ Best Practices

Use external secret managers or encrypted GitOps workflows

Enable Kubernetes secret encryption at rest

Restrict Secret access with RBAC

Rotate credentials and test reload behavior

Prefer mounted files where operationally safer

🏛️ Architect's Note

Senior Architect's Perspective

A Kubernetes Secret is not a complete secrets strategy. Production needs encryption, access control, rotation, auditability, and a source of truth outside application YAML.

💬 Frequently Asked Questions

Interview: How would you explain Secrets in a real Kubernetes project?

Secrets should be explained through the workload it supports, the Kubernetes object relationships, the failure modes, the security controls, and how it is observed and rolled back in production.

Interview: What production mistake do developers commonly make with Secrets?

The common mistake is making the object work once, then skipping ownership, resource sizing, rollout safety, monitoring, least privilege, and recovery behavior.

🎯 Key Takeaways

1Secrets hold sensitive values
2Base64 is not encryption
3RBAC and encryption at rest matter
4External secret managers are common in enterprises

🎯 Practice this topic in interviews

↗ Where this topic fits

Sources

Sources / References

Use these Kubernetes references to verify the concept in official docs and continue into the most relevant SplashRide pages.

Related SplashRide pages