Configuration Management
Managing application configuration with ConfigMaps, Secrets, and environment variables in Kubernetes.
ConfigMaps
ConfigMaps allow you to decouple configuration artifacts from container images, making applications more portable and easier to manage.
What are ConfigMaps?
- Key-value store: Store non-confidential data in key-value pairs
- Decoupled config: Separate configuration from application code
- Environment-specific: Different configs for dev, staging, production
- Size limit: Maximum 1MB per ConfigMap
- Multiple formats: Literal values, files, or directories
Usage Patterns
Environment Variables
Inject config as env vars into containers
Volume Mounts
Mount as files in container filesystem
Command Arguments
Use in container command and args
Init Containers
Configure init containers with ConfigMaps
Secrets
Secrets are similar to ConfigMaps but specifically designed to hold sensitive information like passwords, tokens, and keys.
Secret Types
Opaque (Generic)
Default type for arbitrary user-defined data
Use Case: API keys, database passwords, tokens
kubernetes.io/dockerconfigjson
Docker registry authentication credentials
Use Case: Pulling images from private registries
kubernetes.io/tls
TLS certificate and private key
Use Case: HTTPS ingress, secure communications
kubernetes.io/service-account-token
Service account token for API access
Use Case: Automatic pod authentication
Security Considerations
- Base64 encoded: Not encrypted by default, only encoded
- Encryption at rest: Enable etcd encryption for better security
- RBAC: Restrict access with proper role-based policies
- External secret management: Consider Vault, AWS Secrets Manager, Azure Key Vault
- Never commit secrets: Use sealed secrets or external secret operators
Environment Variables
Methods to Define Environment Variables
Direct Definition
Define directly in pod spec
env: [{ name: 'ENV', value: 'production' }]From ConfigMap
Reference entire ConfigMap or specific keys
envFrom: [{ configMapRef: { name: 'app-config' } }]From Secret
Inject secret values as environment variables
envFrom: [{ secretRef: { name: 'db-credentials' } }]Field Selectors
Reference pod/container metadata
fieldRef: { fieldPath: 'metadata.name' }Resource Requests/Limits
Expose resource values as env vars
resourceFieldRef: { resource: 'limits.memory' }Best Practices
- Prefer ConfigMaps/Secrets over hardcoded values in manifests
- Use volume mounts for large configuration files instead of env vars
- Namespace your env var names to avoid conflicts (e.g., APP_DATABASE_URL)
- Document required environment variables in your deployment docs
Advanced Configuration Patterns
Immutable ConfigMaps and Secrets
Mark as immutable to prevent accidental updates and improve performance
Benefits:
- • Better cache performance
- • Prevents accidental mutations
- • Requires pod restart for changes
Projected Volumes
Combine multiple sources (ConfigMaps, Secrets, downward API) into a single volume
Benefits:
- • Single mount point
- • Mix different sources
- • Simplified pod specs
External Secret Operators
Sync secrets from external systems (Vault, AWS, Azure, GCP)
Benefits:
- • Centralized secret management
- • Automatic rotation
- • Audit trails
Config Reloading
Applications that watch for config changes without restart
Benefits:
- • Zero-downtime updates
- • Dynamic reconfiguration
- • Improved availability
Key Takeaways
- ConfigMaps separate configuration from container images for better portability
- Secrets provide a mechanism for handling sensitive data with RBAC integration
- Always enable encryption at rest for secrets and use external secret management for production
- Environment variables, volume mounts, and projected volumes offer flexible configuration options
- Immutable configurations improve performance and prevent accidental changes