Kubernetes Secrets Management Done Right

Secrets in Kubernetes store sensitive data like passwords, tokens, and certificates. However, by default, they’re only base64 encoded—not encrypted. Let’s explore how to properly secure your secrets.

The Problem with Default Secrets

apiVersion: v1
kind: Secret
metadata:
  name: db-credentials
type: Opaque
data:
  username: YWRtaW4=  # Just base64!
  password: cGFzc3dvcmQxMjM=

Anyone with access to etcd or the API can decode these values instantly.

Enable Encryption at Rest

Configure the API server to encrypt secrets in etcd:

apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
  - resources:
      - secrets
    providers:
      - aescbc:
          keys:
            - name: key1
              secret: <base64-encoded-key>
      - identity: {}

External Secrets Management

Consider using external secret stores:

HashiCorp Vault

apiVersion: secrets-store.csi.x-k8s.io/v1
kind: SecretProviderClass
metadata:
  name: vault-secrets
spec:
  provider: vault
  parameters:
    vaultAddress: "https://vault.example.com"
    roleName: "k8s-role"
    objects: |
      - objectName: "db-password"
        secretPath: "secret/data/myapp"
        secretKey: "password"

AWS Secrets Manager

Use the External Secrets Operator to sync secrets from AWS.

Best Practices

1. Rotate secrets regularly - Automate rotation with operators
2. Limit access - Use RBAC to restrict who can read secrets
3. Audit access - Enable audit logging for secret access
4. Avoid environment variables - Mount secrets as files instead
5. Use sealed secrets - For GitOps workflows

Secret Scanning

Implement pre-commit hooks to prevent secrets from being committed to version control. Tools like gitleaks and detect-secrets can help.