Using Kubernetes ConfigMaps for Proper Secret Management
Kubernetes ConfigMaps and Secrets have transformed how you manage containerized applications securely. Read on to learn how ConfigMaps have revolutionized application lifecycle processes by reducing hardcoding efforts and enhancing portability.
Save to Folio
What are ConfigMaps?
ConfigMaps enable Kubernetes to operate seamlessly across various environments, so ConfigMaps are instrumental in reducing hardcoding efforts, encouraging code reusability, and simplifying the complex processes inherent in the application lifecycle.
Think of ConfigMaps as the courier service within Kubernetes: They deliver configuration data directly to the containers. They carry non-sensitive, unencrypted settings that you can leverage to extend application configurations beyond a single environment, improving application portability. You can also use ConfigMaps across different Kubernetes Pods.
But the stakes are high when handling sensitive data within a Kubernetes environment. Mismanagement or inappropriate use of ConfigMaps could invite potential security threats. Malicious entities can exploit sensitive data like API keys, passwords, or secrets exposed through ConfigMaps, leading to unauthorized access, data breaches, downtime, or even sensitive data exfiltration.
This article discusses how to use ConfigMaps, exploring best practices for managing ConfigMaps securely and reviewing which types of data you should—and shouldn’t— include.
Understanding Kubernetes ConfigMaps
In Kubernetes, ConfigMaps are API objects that store nonconfidential data in key-value pairs. They contain information such as database connection strings, file paths, and license keys.
ConfigMaps allow you to decouple and separate environment-specific configurations from your container images, boosting the portability and resilience of your applications.
Take a look at the following simple YAML representation of a ConfigMap. Say you have an application that requires a connection to a MySQL database. Instead of hardcoding the connection string into the application, you can place it in a ConfigMap, like below.
This example defines a ConfigMap named that includes the host name of the MySQL service () and the username and password for database access (, respectively). You store the password in a Secret.
To generate a base64 encoded string, run the command below.
ConfigMaps serve as an invaluable tool in a Kubernetes environment, offering flexibility in configuration management. You can use them for:
- Storing application configurations—Instead of hardcoding application properties such as file paths, ConfigMaps let you externalize these details, making them easy to change and manage.
- Providing command-line arguments—ConfigMaps can feed command-line arguments to your containers dynamically. This approach avoids hardcoding the values and allows for easier updates.
- Setting environment variables—ConfigMaps enable you to inject environment variables into your containers, allowing you to modify the behavior of your applications without changing the application code.
But while ConfigMaps provide flexibility, you must use them correctly. Their security limitations, which can be high-risk, require careful consideration. For example, if a malicious actor manages to access a ConfigMap containing database credentials, it could lead to a system-wide compromise.
To mitigate the risk that ConfigMaps pose when storing sensitive data, you can turn to Kubernetes Secrets, as the next section explores.
Kubernetes security and secret management
Security and secret management are integral parts of a well-administered Kubernetes environment. One of the major players is Kubernetes Secrets, the guardians of sensitive information. They manage and store crucial data, such as passwords, OAuth tokens, and SSH keys. Secrets, built with added layers of protection, are specifically designed to house confidential data.
The differences between Secrets and ConfigMaps are significant. While they both provide configuration data to your Pods, they vary greatly in terms of their security features.
ConfigMaps are plain text and easily readable, making them a poor choice for storing sensitive data. In contrast, Kubernetes Secrets are base64 encoded but stored unencrypted by default. However, you can toggle “Enable Encryption at Rest for Secrets” to make them a more secure choice for storing sensitive data. Additionally, Secrets are specifically designed for sensitive information. You can configure them with a limited lifespan using Kubernetes Secret rotation policies—a feature that sets Secrets apart from ConfigMaps.
Kubernetes 1.19 introduced the concept of Immutable Secrets and ConfigMaps, adding another layer of security and stability to your Kubernetes deployments. Once you mark a Secret or a ConfigMap as immutable, it can’t be modified or deleted. This feature helps protect important data from accidental or malicious deletion and modification.
Immutable ConfigMaps safeguard crucial configuration details from unintentional changes that could disrupt application function. Similarly, for Secrets, immutability provides an added shield against accidental modifications or deletions that could expose sensitive information. It enhances both the reliability of application configuration via ConfigMaps and the security of sensitive data via Secrets.
Transitioning to immutable Secrets gives your cluster a significant performance boost. It alleviates the load on the kube-apiserver, as the kubelet no longer needs to constantly monitor any Secrets designated as immutable. This reduction in resource demand enhances the overall operational efficiency of your Kubernetes environment.
Proper secret management is crucial to maintaining security in Kubernetes. This process involves not just using Secrets for storing sensitive data but also following best practices for managing those Secrets. For example, implementing external secret management systems like HashiCorp Vault or AWS Secrets Manager can provide additional features like secret rotation, detailed audit logs, and more granular access control policies.
Hardcoding secrets in your application code or container images can lead to accidental exposure of sensitive data. To prevent such mishaps, scan your container images for hardcoded secrets to ensure that your sensitive data remains secure.
One solution that provides comprehensive container image scanning is Trend Cloud One – Container Security. This security tool offers robust visibility into vulnerabilities, malware, and compliance checks. It uses a streamlined process to scan container images during the build phase, helping you identify and remedy potential threats before are deployed into your environment. Container Security continues to monitor your running containers for suspicious behavior with runtime protection.
Another solution is Trend Cloud One™ – Open Source Security. This tool enables you to find and fix open-source code vulnerabilities and license risks easily, further strengthening the security posture of your containerized applications. It helps safeguard your sensitive data from potential threats by enabling you to manage and secure your software bill of materials and container image security effectively.
Identifying sensitive data for ConfigMaps
To use and manage ConfigMaps securely, you first need to determine what constitutes sensitive data—and then ensure it’s not included in your ConfigMaps.
Generally, ConfigMaps should only contain nonsensitive data that users can openly access and read without causing any security risks. They’re ideal for storing configuration data that might change across different deployment environments, such as:
- URLs of related services
- Network port values
- File names or locations
- External resource names
- Other nonsensitive, environment-specific values
However, you should never store sensitive data such as passwords, API keys, OAuth tokens, and SSL certificates in ConfigMaps. As discussed above, ConfigMaps don't provide any form of data encryption, either at rest or in transit, which means that any sensitive data stored in a ConfigMap is potentially exposed to unauthorized users.
Best practices for using Kubernetes ConfigMaps securely
The security of a Kubernetes environment depends on your correct use of ConfigMaps and proper management of sensitive data. When using ConfigMaps in a Kubernetes environment, implement the following best practices.
Set up role-based access control (RBAC) to manage who can access your ConfigMaps. RBAC lets you configure policies that specify who can read or write to your ConfigMaps, helping prevent unauthorized access to your configuration data.
Versioning allows you to keep track of changes to your ConfigMaps over time, helping you troubleshoot issues or roll back changes. Auditing helps maintain a record of who has accessed or modified your ConfigMaps, adding an extra layer of security and accountability for changes made.
Although ConfigMaps don’t natively support encryption at rest or in transit, Kubernetes Secrets do. Use Secrets for any configuration data that needs encryption. And for added security, consider using a key management system (KMS) to manage your Secrets' encryption keys.
Conclusion
ConfigMaps deliver nonsensitive, unencrypted configuration data to containers, enhancing application portability and promoting consistency across several application Pods. However, it’s vital to remember that ConfigMaps aren’t designed to handle sensitive data. If you mismanage ConfigMaps or use them for inappropriate or sensitive data, you’re leaving them vulnerable to potential security risks.
The key to securing your Kubernetes environment lies in understanding the unique roles of ConfigMaps and Secrets, using them correctly, and adhering to robust secret management practices. By doing so, you can maximize the potential of Kubernetes, secure in the knowledge that your configuration data and sensitive information are well-managed and protected.