kubernetes

Part 5 - Managing Applications with Kubernetes ConfigMaps and Secrets: Configuration Without Tears

AB Engineering

• 5 min read
Part 5 - Managing Applications with Kubernetes ConfigMaps and Secrets: Configuration Without Tears

In a Kubernetes world where pods come and go like weekend guests, how do you ensure they all know where to find the snacks? The answer lies in ConfigMaps and Secrets—your application's essential guide to finding everything from database connection strings to API keys without having them tattooed on their containers.

When Hardcoding Goes Wrong: A Configuration Cautionary Tale

Picture this: It's 3 AM, and you've just received an urgent call that your production environment is down. Why? Because someone hardcoded the database connection string directly into the application, pointing to a development database that just went offline for maintenance. If this scenario sounds painfully familiar, you're not alone.

In the pre-Kubernetes era, development teams often resorted to risky practices like embedding configuration values directly in code or using environment variables that needed to be manually set on each host. These approaches led to the classic "but it works on my machine" syndrome and midnight debugging sessions that developers still recount with thousand-yard stares.

Enter ConfigMaps: Configuration Made Simple

Kubernetes ConfigMaps offer a elegant solution to the configuration conundrum by providing a mechanism to decouple environment-specific settings from your container images. This separation is crucial for maintaining portable, environment-agnostic applications.

What Are ConfigMaps?

ConfigMaps store non-confidential configuration data as key-value pairs within your Kubernetes cluster. Think of them as a shared notepad accessible to all authorized pods, containing important information like:

  • Database hostnames and ports
  • Feature flags and debug settings
  • External service endpoints
  • Application parameters

Creating Your First ConfigMap

You can create ConfigMaps through YAML definitions or using the kubectl command line. Here's a simple example:

apiVersion: v1
kind: ConfigMap
metadata:
  name: application-config
data:
  database_host: "db.example.com"
  database_port: "5432"
  debug_mode: "false"
  log_level: "info"

After saving this file as application-config.yaml, you can apply it to your cluster:

kubectl apply -f application-config.yaml

Consuming ConfigMaps in Your Pods

There are three primary ways your applications can access ConfigMap data:

  1. As environment variables - Perfect for applications that already look for configuration in their environment:
apiVersion: v1
kind: Pod
metadata:
  name: config-env-example
spec:
  containers:
  - name: app
    image: myapp:1.0
    envFrom:
    - configMapRef:
        name: application-config
  1. As command-line arguments - Useful when your application expects parameters on startup:
apiVersion: v1
kind: Pod
metadata:
  name: config-cmd-example
spec:
  containers:
  - name: app
    image: myapp:1.0
    command: 
    args: 
    env:
    - name: DB_HOST
      valueFrom:
        configMapKeyRef:
          name: application-config
          key: database_host
    - name: LOG_LEVEL
      valueFrom:
        configMapKeyRef:
          name: application-config
          key: log_level
  1. As files in a mounted volume - Ideal for applications expecting configuration files:
apiVersion: v1
kind: Pod
metadata:
  name: config-volume-example
spec:
  containers:
  - name: app
    image: myapp:1.0
    volumeMounts:
    - name: config-volume
      mountPath: "/etc/config"
  volumes:
  - name: config-volume
    configMap:
      name: application-config

With this approach, each key in your ConfigMap becomes a file in the /etc/config directory, with the value as the file's content.

When Configuration Gets Sensitive: Enter Secrets

While ConfigMaps are perfect for general configuration, they're not designed for sensitive data. That's where Kubernetes Secrets come in—think of them as ConfigMaps with a security clearance.

What Are Secrets?

A Secret is a Kubernetes object specifically designed for storing sensitive information like passwords, OAuth tokens, SSH keys, or TLS certificates. While functionally similar to ConfigMaps, Secrets are treated differently by Kubernetes to provide additional protection for your confidential data.

Creating and Using Secrets

Here's how you can create a Secret for database authentication:

apiVersion: v1
kind: Secret
metadata:
  name: database-credentials
type: kubernetes.io/basic-auth
stringData:
  username: admin
  password: super-secure-password

Once created, you can access these secrets in your pods using similar methods to ConfigMaps:

apiVersion: v1
kind: Pod
metadata:
  name: secure-app
spec:
  containers:
  - name: app
    image: myapp:1.0
    env:
    - name: DB_USERNAME
      valueFrom:
        secretKeyRef:
          name: database-credentials
          key: username
    - name: DB_PASSWORD
      valueFrom:
        secretKeyRef:
          name: database-credentials
          key: password

Types of Secrets for Different Use Cases

Kubernetes provides several built-in Secret types for common scenarios:

  • Opaque (default): For arbitrary user-defined data
  • kubernetes.io/basic-auth: For basic authentication with username and password
  • kubernetes.io/ssh-auth: For SSH private keys
  • kubernetes.io/tls: For TLS certificates and keys
  • kubernetes.io/dockerconfigjson: For Docker registry authentication

This variety ensures you have the right format for your specific security needs.

The Security Elephant in the Room

Before you rush off to move all your passwords into Kubernetes Secrets, there's a critical caveat to understand: by default, Secrets are stored unencrypted in the cluster's underlying etcd database. This means anyone with API access to your Secrets or direct access to etcd can potentially view or modify them.

To address this security concern, follow these essential practices:

  1. Enable encryption at rest for your etcd database
  2. Implement RBAC (Role-Based Access Control) with least-privilege principles
  3. Restrict Secret access to specific containers that actually need them
  4. Consider external secret management systems like HashiCorp Vault or AWS Secrets Manager for enhanced security

Real-World Best Practices: Lessons from the Trenches

After witnessing numerous configuration mishaps and secret leaks, here are some battle-tested best practices:

For ConfigMaps:

  1. Keep them focused - One ConfigMap per application or component for easier management
  2. Don't exceed size limits - ConfigMaps have a 1 MiB size limit; break larger configurations into multiple ConfigMaps
  3. Consider immutability - Use the immutable field to prevent accidental changes to critical configurations

For Secrets:

  1. Never commit secrets to source control - Even in Kubernetes YAML files
  2. Implement the principle of least privilege - Each pod should only access the Secrets it needs
  3. Protect secrets after reading - Ensure your application doesn't log or expose secrets after consuming them
  4. Rotate secrets regularly - Especially for production environments

The "Aha" Moment: A DevOps Transformation Story

Let me tell you about a team I worked with last year. They were deploying a microservices application across development, staging, and production environments, with different configurations for each. Their initial approach? Maintaining separate Docker images for each environment, complete with baked-in configuration.

The result was predictable chaos: version drift between environments, configuration changes requiring full rebuilds, and the occasional production outage when someone forgot to update a hardcoded connection string.

After implementing ConfigMaps and Secrets, they could:

  • Use identical container images across all environments
  • Change configuration without rebuilding containers
  • Manage sensitive data securely through Kubernetes
  • Automate configuration updates without downtime

The time saved on managing configurations alone freed up a full day per week for feature development instead of firefighting.

Beyond the Basics: Advanced Configuration Patterns

As your Kubernetes journey continues, consider these advanced patterns:

Pattern 1: Configuration Templates with Kustomize

Use Kustomize to template your ConfigMaps and Secrets across environments:

base/
  ├── configmap.yaml
  └── kustomization.yaml
overlays/
  ├── dev/
  │   ├── kustomization.yaml
  │   └── config-patch.yaml
  ├── staging/
  │   ├── kustomization.yaml
  │   └── config-patch.yaml
  └── production/
      ├── kustomization.yaml
      └── config-patch.yaml

Pattern 2: Dynamic Configuration Updates

For applications that can reload configuration without restarting, mount ConfigMaps as volumes and use file watchers to detect changes.

Pattern 3: External Secret Stores Integration

As your security requirements grow, integrate with dedicated secret management solutions like Vault using the External Secrets Operator.

The Future of Configuration in Kubernetes

As Kubernetes continues to evolve, we're seeing exciting developments in configuration management:

  • Improved secret encryption mechanisms
  • Better integration with cloud provider secret stores
  • Enhanced validation and schema enforcement for ConfigMaps
  • GitOps approaches to configuration management

The journey from hardcoded configuration to dynamic, secure, and environment-aware settings isn't just about technical implementation—it's about enabling teams to work faster, more safely, and with greater confidence.

Parting Thoughts

Configuration may not be the most glamorous part of your Kubernetes journey, but it might be the most impactful. After all, even the most beautifully architected application falls apart with incorrect database credentials or missing API endpoints.

By embracing ConfigMaps and Secrets, you're not just managing configuration—you're unlocking the true potential of container orchestration: the ability to deploy anywhere with confidence, update without fear, and scale without secrets getting in the way.

Next time you're tempted to hardcode that database URL "just for now," remember: in Kubernetes, configuration isn't just a file—it's a first-class citizen of your infrastructure. Treat it with the respect it deserves, and it will return the favor with interest.

Now go forth and configure with confidence—your 3 AM self will thank you.