ConfigMap vs Secret — What's the Difference?

Detailed Answer

ConfigMaps and Secrets both store key-value configuration data for Pods, but they serve different purposes and have different security characteristics.

Side-by-Side Comparison

| Feature | ConfigMap | Secret | |---|---|---| | Purpose | Non-sensitive configuration | Sensitive data (passwords, tokens, keys) | | Encoding | Plaintext | Base64-encoded | | Encryption at rest | Not supported | Optional (EncryptionConfiguration) | | Volume mount type | Regular filesystem | tmpfs (in-memory) | | Size limit | 1 MiB | 1 MiB | | RBAC | Standard | Can be restricted more tightly | | kubectl output | Shows data by default | Hides data (shows as ***) |

ConfigMap Example

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-settings
data:
  DATABASE_HOST: "postgres.prod.svc.cluster.local"
  LOG_LEVEL: "warn"
  CACHE_TTL: "300"

Secret Example

apiVersion: v1
kind: Secret
metadata:
  name: app-credentials
type: Opaque
data:
  DATABASE_PASSWORD: cGFzc3dvcmQxMjM=    # base64 of "password123"
  API_KEY: c2VjcmV0LWFwaS1rZXk=          # base64 of "secret-api-key"

Or using stringData to avoid manual base64 encoding:

apiVersion: v1
kind: Secret
metadata:
  name: app-credentials
type: Opaque
stringData:
  DATABASE_PASSWORD: "password123"
  API_KEY: "secret-api-key"

Using Both in a Pod

apiVersion: v1
kind: Pod
metadata:
  name: app
spec:
  containers:
    - name: app
      image: myapp:v2
      envFrom:
        - configMapRef:
            name: app-settings
        - secretRef:
            name: app-credentials
      resources:
        requests:
          cpu: "250m"
          memory: "256Mi"

Security Differences in Detail

1. Base64 Is Not Encryption

Base64 is an encoding scheme, not encryption. Anyone with access to the Secret object can decode it:

echo "cGFzc3dvcmQxMjM=" | base64 -d
# password123

Base64 exists to support binary data (like TLS certificates), not for security.

2. Encryption at Rest

Enable etcd encryption to protect Secrets on disk:

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

3. tmpfs Volume Mounts

When Secrets are mounted as volumes, Kubernetes uses tmpfs (an in-memory filesystem):

# On the node, Secret volumes are in-memory
mount | grep secret
# tmpfs on /var/lib/kubelet/pods/.../volumes/kubernetes.io~secret/... type tmpfs

This prevents Secret data from being written to the node's physical disk. ConfigMap volumes are stored on disk.

4. RBAC Restrictions

You can restrict Secret access more tightly than ConfigMaps:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: app-deployer
rules:
  # Allow ConfigMap access
  - apiGroups: [""]
    resources: ["configmaps"]
    verbs: ["get", "list", "watch"]
  # Deny Secret access (by omission)
  # Only specific service accounts can read secrets

When to Use What

| Data Type | Use | |---|---| | Database hostname | ConfigMap | | Database password | Secret | | Log level | ConfigMap | | API token | Secret | | TLS certificate | Secret (type kubernetes.io/tls) | | Application config file | ConfigMap | | Docker registry credentials | Secret (type kubernetes.io/dockerconfigjson) |

Best Practices

1. Never store secrets in ConfigMaps — even "internal" passwords
2. Enable encryption at rest for Secrets in production
3. Use RBAC to restrict who can read Secrets
4. Consider external secret managers (Vault, AWS Secrets Manager) for critical credentials
5. Avoid committing Secrets to Git — use sealed-secrets or external-secrets-operator instead