Managing Kubernetes Secrets and ConfigMaps for Secure DevOps

📖 Introduction

Modern applications rely heavily on configuration data and sensitive information such as API keys, database credentials, certificates, and environment variables. Hardcoding these values into application code or container images introduces serious security and operational risks.

Kubernetes solves this challenge using Secrets and ConfigMaps, which allow teams to decouple configuration from application code, improve security, and enable flexible deployments across environments like development, staging, and production.

🔐 Secrets vs ConfigMaps

Feature Secrets ConfigMaps

Purpose Store sensitive data (passwords, tokens, certificates) Store non-sensitive configuration (env vars, settings)

Data Format Base64-encoded Plain text

Security Can be encrypted at rest, protected with RBAC RBAC-controlled but less strict

Typical Use Credentials, API keys, TLS certs App configs, feature flags, log levels

👉 Rule of thumb:

Use Secrets for anything confidential and ConfigMaps for general configuration.

🔑 Creating a Kubernetes Secret

You can create a Secret directly from the CLI:

kubectl create secret generic db-secret \

  --from-literal=username=admin \

  --from-literal=password=Pa55w0rd

Injecting a Secret into a Pod

Secrets can be exposed as environment variables:

env:

  - name: DB_USER

    valueFrom:

      secretKeyRef:

        name: db-secret

        key: username

This ensures credentials are never stored in source code or images.

⚙️ Creating a ConfigMap

ConfigMaps store non-sensitive application settings.

kubectl create configmap app-config \

  --from-literal=APP_MODE=production \

  --from-literal=LOG_LEVEL=debug

Using a ConfigMap in a Pod

Inject all values at once:

envFrom:

  - configMapRef:

      name: app-config

This allows applications to adapt behavior without rebuilding containers.

🔄 Mounting Secrets and ConfigMaps as Volumes

Both Secrets and ConfigMaps can be mounted as files:

volumes:

  - name: config-volume

    configMap:

      name: app-config

This approach is useful for:

Configuration files

Certificates

Application properties

🛡️ Security Best Practices

To ensure secure and scalable configuration management:

✅ Never hardcode secrets in YAML manifests or container images

✅ Restrict access using RBAC — only authorized workloads should read Secrets

✅ Enable encryption at rest for Secrets in etcd

✅ Rotate secrets regularly

✅ Externalize secrets using tools like:

HashiCorp Vault

Kubernetes External Secrets

Sealed Secrets

Cloud-native secret managers (AWS Secrets Manager, Azure Key Vault)

✅ Separate ConfigMaps by environment (dev, staging, prod)

🚀 DevOps & CI/CD Considerations

Secrets and ConfigMaps integrate seamlessly into CI/CD pipelines:

Inject environment-specific configs at deploy time

Avoid storing secrets in Git repositories

Enable safe rollbacks and configuration changes

Support GitOps workflows with encrypted secrets

🏁 Conclusion

Kubernetes Secrets and ConfigMaps are foundational building blocks for secure, flexible, and maintainable deployments. By separating configuration from code, enforcing access controls, and integrating with external secret managers, teams can significantly reduce risk while improving deployment agility.

In the next post, we’ll explore Kubernetes Ingress and Service Routing, covering traffic management, load balancing, and TLS termination.