Lesson 11: ConfigMaps & Secrets — Externalizing Configuration for Production Systems
What We’re Building Today
In this lesson, you’ll build a production-grade configuration management system for a distributed log analytics platform:
Multi-environment ConfigMaps with application settings, feature flags, and service discovery endpoints
Kubernetes Secrets for database credentials, API tokens, and TLS certificates with proper encryption at rest
Dynamic configuration injection through environment variables and volume mounts with hot-reload capabilities
Secret rotation patterns using external-secrets-operator integration and HashiCorp Vault references
RBAC policies restricting secret access to authorized service accounts only
Why This Matters
Netflix runs over 1,000 microservices across multiple regions, each requiring environment-specific configuration without code changes. Spotify manages secrets for 2,000+ services handling 500 million users’ authentication tokens. The twelve-factor app methodology demands strict separation of config from code—but most teams implement this incorrectly.
The failure pattern I see repeatedly: developers hardcode database passwords in Dockerfiles, commit API keys to Git, or worse, bake secrets into ConfigMaps where they’re stored unencrypted in etcd. One compromised node exposes every secret in the cluster. Configuration drift between environments causes 23% of production incidents at scale. Understanding the ConfigMap/Secret boundary isn’t just best practice—it’s the difference between a security audit pass and a breach notification.
