Introduction
When deploying applications in Kubernetes, managing configuration data securely and efficiently is critical. Kubernetes provides Secrets for handling sensitive data like passwords and API keys, and ConfigMaps for storing non-sensitive configuration data such as environment variables and application settings.
In this blog, we’ll explore:
- How to use Kubernetes Secrets for sensitive data.
- How to use ConfigMaps for general configuration.
- A real-world scenario where both are used effectively.
Using Kubernetes Secrets for Secure Data Management
Secrets in Kubernetes allow you to securely store and manage sensitive information like database credentials, API keys, and TLS certificates.
Example: Creating a Secret for Database Credentials
| apiVersion: v1 kind: Secret metadata: name: db-secret namespace: my-app-namespace labels: app: my-app type: Opaque data: DB_PASSWORD: c3VwZXJzZWNyZXQ= # Base64 encoded value of ‘supersecret’ |
Injecting the Secret into a Pod
| apiVersion: v1 kind: Pod metadata: name: my-app-pod spec: containers: – name: my-app-container image: my-app:latest env: – name: DB_PASSWORD valueFrom: secretKeyRef: name: db-secret key: DB_PASSWORD |
🔹 Security Benefits: This method keeps credentials out of plain text configurations, reducing the risk of accidental exposure.
Using ConfigMaps for General Configuration Management
ConfigMaps store non-sensitive configuration data and can be used to decouple configuration from application code.
Example: Creating a ConfigMap for App Settings
| apiVersion: v1 kind: ConfigMap metadata: name: app-config namespace: my-app-namespace data: APP_MODE: “production” LOG_LEVEL: “debug” |
Injecting the ConfigMap into a Pod
| apiVersion: v1 kind: Pod metadata: name: my-app-pod spec: containers: – name: my-app-container image: my-app:latest env: – name: APP_MODE valueFrom: configMapKeyRef: name: app-config key: APP_MODE – name: LOG_LEVEL valueFrom: configMapKeyRef: name: app-config key: LOG_LEVEL |
Real-World Scenario: Securing a Database Connection in a Microservices App
Imagine a microservices-based e-commerce application that requires secure database credentials and configurable logging levels. The application architecture consists of:
- A backend API service that connects to a PostgreSQL database.
- A logging service that uses environment variables to control log levels.
Implementing the Solution
- Use Kubernetes Secrets to store database credentials:
- Securely store the database password using Secrets.
- Inject the secret into the backend API pod as an environment variable.
- Use ConfigMaps for application configuration:
- Define log levels and app mode in a ConfigMap.
- Mount the ConfigMap as an environment variable in both the API and logging services.
Deployment Example
| apiVersion: apps/v1 kind: Deployment metadata: name: backend-api spec: replicas: 2 selector: matchLabels: app: backend-api template: metadata: labels: app: backend-api spec: containers: – name: backend-api image: backend-api:v1 env: – name: DB_PASSWORD valueFrom: secretKeyRef: name: db-secret key: DB_PASSWORD – name: APP_MODE valueFrom: configMapKeyRef: name: app-config key: APP_MODE |
Best Practices for Managing Secrets and ConfigMaps
- Use Role-Based Access Control (RBAC): Restrict access to Secrets to only authorized services.
- Encrypt Secrets at Rest: Use Kubernetes encryption providers to protect stored secrets.
- Avoid Hardcoding Configurations: Always use ConfigMaps and Secrets to separate configurations from code.
- Rotate Secrets Regularly: Implement secret rotation policies to enhance security.
Conclusion
By leveraging Kubernetes Secrets and ConfigMaps, organizations can improve security and configuration management within their Kubernetes environments. These tools help maintain flexibility, security, and scalability while reducing risks associated with misconfigured applications.
Would you like to explore how to integrate ConfigMaps and Secrets with Helm charts for even more efficient deployment? Let us know in the comments!
