ConfigMap and Secret Manifest Validation

ConfigMap and Secret Validation

ConfigMaps and Secrets store configuration data and sensitive values respectively. While structurally simpler than workload resources, they have their own validation concerns.

Example ConfigMap

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
  labels:
    app: myapp
data:
  DATABASE_HOST: postgres-primary
  DATABASE_PORT: "5432"
  LOG_LEVEL: info
  config.yaml: |
    server:
      port: 8080
      timeout: 30s
    database:
      pool_size: 10

Example Secret

apiVersion: v1
kind: Secret
metadata:
  name: app-secrets
  labels:
    app: myapp
type: Opaque
data:
  DATABASE_PASSWORD: cGFzc3dvcmQxMjM=
  API_KEY: c2VjcmV0LWtleS12YWx1ZQ==

Common Issues

1. Missing metadata.name: Required for all resources
2. Missing labels: Makes it hard to identify which app owns the ConfigMap
3. Secret data not base64-encoded: The data field in Secrets requires base64 encoding
4. Using data vs stringData: Secrets support stringData for plain text (encoded automatically)

ConfigMap vs Secret

Feature	ConfigMap	Secret
Data encoding	Plain text	Base64 in data, plain in stringData
Size limit	1 MiB	1 MiB
RBAC	Standard	Can be restricted separately
Encryption at rest	No	Optional (EncryptionConfiguration)
Use for	Config files, env vars	Passwords, tokens, keys

Best Practices

• Always add labels to identify ownership
• Use stringData in Secrets for readability (Kubernetes encodes automatically)
• Consider using external secret managers (Vault, AWS Secrets Manager) for production
• Do not commit Secret manifests with real values to version control