Using Kubernetes ConfigMaps and Secrets for Sensitive Data

Using Kubernetes ConfigMaps and Secrets for Sensitive Data

Kubernetes provides two important resources for managing application configurations and sensitive data: ConfigMaps and Secrets. These resources enable developers to store non-sensitive and sensitive information, respectively, and use them in Kubernetes applications.

In this article, we’ll explore how to effectively use ConfigMaps and Secrets in Kubernetes to manage configurations and sensitive data while ensuring security and flexibility.

What are ConfigMaps in Kubernetes?

ConfigMaps are Kubernetes resources used to store non-sensitive configuration data. They allow you to separate configuration details from application code and provide a way to manage settings that can be easily updated without requiring changes to the application’s source code.

A ConfigMap can contain key-value pairs, configuration files, or environment variables that your applications need to run. For example, you can store database URLs, API keys (non-sensitive), or any other configuration settings in a ConfigMap.

Creating and Using ConfigMaps

1. Creating a ConfigMap:
   You can create a ConfigMap from literal key-value pairs or from configuration files. Here’s an example of creating a ConfigMap from a literal value:

   kubectl create configmap my-config --from-literal=db_host=localhost --from-literal=db_port=3306

You can also create a ConfigMap from a file:

   kubectl create configmap my-config --from-file=config.properties

1. Referencing a ConfigMap in a Pod:
   After creating a ConfigMap, you can reference it in your Kubernetes Pods. ConfigMaps can be consumed as environment variables, volumes, or directly in the container’s command.

Example of using a ConfigMap as environment variables:

   apiVersion: v1
   kind: Pod
   metadata:
     name: my-app
   spec:
     containers:
     - name: my-app-container
       image: my-app-image
       envFrom:
       - configMapRef:
           name: my-config

In this example, the values stored in the my-config ConfigMap are injected as environment variables inside the container.

1. Updating ConfigMaps:
   You can update a ConfigMap without having to modify the application code. If a ConfigMap is updated, Kubernetes will automatically trigger a rolling update for deployments referencing the ConfigMap.

   kubectl create configmap my-config --from-literal=db_host=updated-host -o yaml --dry-run=client | kubectl apply -f -

Note: To use new ConfigMap values, you may need to restart Pods, or Kubernetes will trigger a restart depending on the application configuration.

What are Secrets in Kubernetes?

Secrets in Kubernetes are similar to ConfigMaps, but they are designed to store sensitive data like passwords, OAuth tokens, SSH keys, etc. Secrets are stored in an encoded format (Base64) and can be securely referenced by Pods and other resources.

Although Kubernetes does not encrypt Secrets by default, they are more secure than plain text in the code repository because Kubernetes provides mechanisms to restrict access to sensitive data and allows administrators to use external secrets management tools (like Vault or Cloud Key Management Systems).

Creating and Using Secrets

1. Creating a Secret:
   Kubernetes Secrets can be created in several ways, such as using literal values or from files. Here is an example of creating a Secret from literal values:

   kubectl create secret generic my-secret --from-literal=username=admin --from-literal=password=mysecretpassword

You can also create a Secret from a file:

   kubectl create secret generic my-secret --from-file=ssh-key=./ssh/id_rsa

1. Referencing Secrets in a Pod:
   Secrets can be injected into Pods as environment variables or as volumes. They can also be referenced by other resources such as Services or Deployments.

Example of using a Secret as environment variables:

   apiVersion: v1
   kind: Pod
   metadata:
     name: my-app
   spec:
     containers:
     - name: my-app-container
       image: my-app-image
       env:
       - name: DB_USERNAME
         valueFrom:
           secretKeyRef:
             name: my-secret
             key: username
       - name: DB_PASSWORD
         valueFrom:
           secretKeyRef:
             name: my-secret
             key: password

In this example, the DB_USERNAME and DB_PASSWORD environment variables are populated with values from the my-secret Secret.

1. Managing Secrets with Encryption:
   While Secrets are stored in Base64-encoded form, Kubernetes provides an option to encrypt Secrets at rest to enhance security. To enable encryption, you need to configure the encryption provider in the Kubernetes cluster configuration (e.g., kube-apiserver).

Example of enabling encryption at rest:

   apiVersion: admissionregistration.k8s.io/v1
   kind: AdmissionControl
   apiVersion: admissionregistration.k8s.io/v1

1. Access Control for Secrets:
   Kubernetes supports Role-Based Access Control (RBAC), which allows you to restrict access to Secrets based on user roles. Make sure only authorized users or service accounts have access to sensitive data.

Best Practices for Using ConfigMaps and Secrets in Kubernetes

1. Use Secrets for Sensitive Data: Always use Secrets to store sensitive data like passwords, tokens, and private keys. Never store sensitive data in ConfigMaps.

2. Encrypt Secrets at Rest: If possible, enable encryption for Kubernetes Secrets to provide an additional layer of security for sensitive information.

3. RBAC for Access Control: Ensure that access to ConfigMaps and Secrets is properly controlled using RBAC. Limit access only to Pods and users who require it.

4. Use Environment Variables for Simple Configurations: If your configuration settings are simple and non-sensitive (e.g., database URLs or API endpoints), consider using ConfigMaps as environment variables.

5. Avoid Hardcoding Configurations: Never hardcode configuration values or secrets directly in the application code. Instead, externalize them into ConfigMaps or Secrets.

6. Consider Using External Secret Management Tools: For even better security, consider using external secret management systems like HashiCorp Vault, AWS Secrets Manager, or Azure Key Vault to securely manage your secrets outside of Kubernetes.

7. Version ConfigMaps and Secrets: Use Kubernetes’ kubectl apply to update resources, and consider using version control (Git) for keeping track of changes to ConfigMaps and Secrets. This ensures traceability and easier rollbacks in case of issues.

ConfigMaps vs. Secrets: Key Differences

Conclusion

In Kubernetes, ConfigMaps and Secrets are crucial for managing configurations and sensitive data, respectively. ConfigMaps are ideal for storing non-sensitive configurations like environment variables, while Secrets should be used for managing sensitive data securely. By separating configuration from application code and following best practices for securing sensitive data, you can significantly improve the maintainability and security of your applications running on Kubernetes.