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

Feature	ConfigMap	Secret
Purpose	Stores non-sensitive configuration data	Stores sensitive information (passwords, tokens)
Encoding	Plain text or any format	Base64 encoded (not encrypted by default)
Best Use Cases	Application configuration settings	Passwords, API tokens, SSH keys, certificates
Default Encryption	No	No (but can be encrypted at rest)
Access Control	RBAC controls access	RBAC controls access, can be encrypted
Visibility	Accessible by anyone with access	Only accessible by authorized users and Pods

---

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.

---

Comments

[Ravin Rau]

Good job @abhay_yt_52a8e72b213be229 on breaking down the differences between ConfigMaps and Secrets in Kubernetes. Making it easy to understand how to manage configurations and sensitive data effectively. Appreciate the practical examples for creating and using both resources—it makes the concepts much clearer for readers.

One thing I wonder is how you would recommend handling scenarios where sensitive data needs to be dynamically updated, such as API tokens that expire frequently. Would an external secrets manager be a better fit in such cases?

[Strage]

Thanks for your thoughtful feedback! I’m glad the breakdown of ConfigMaps and Secrets was helpful.

For scenarios where sensitive data like API tokens frequently expire and need to be dynamically updated, you're right to consider the need for a more flexible solution. An external secrets manager, such as HashiCorp Vault, AWS Secrets Manager, or Azure Key Vault, could be a great fit in such cases. These tools allow for more automated, secure, and centralized management of sensitive data.

With these managers, you can configure your Kubernetes applications to retrieve the secrets at runtime, ensuring they’re always up to date without requiring manual intervention. Additionally, secrets managers provide features like auditing, versioning, and access control, which further enhance security and operational efficiency.

It's always a good idea to evaluate the specific needs of your system and consider the long-term scalability and security of your approach when choosing between Kubernetes Secrets and an external secrets manager.

By the way, if you have any specific work or insights related to full-stack development that you'd like to discuss or share, feel free to reach out! I’d be happy to talk more about that as well.