Kubernetes ConfigMaps and Secrets: What Are They and When to Use Them?
Data breaches are almost always caused by human error, so security always starts with efficient container configuration. Kubernetes ConfigMaps and Secrets are two key objects that can help you store config data securely.
Read on to learn how ConfigMaps and Secrets work, discover if they interact with CAST AI, and what that means for your overall configuration security.
What are Kubernetes ConfigMaps?
A ConfigMap is an API object that stores configuration data for other objects. It lets you decouple environment-specific configuration from container images, so moving your applications gets easier.
The ConfigMap API resource stores config data as key-value pairs. That information can be consumed in pods or provide the configurations for other system components such as controllers.
Kubernetes ConfigMaps are mainly used to configure settings for containers running in a pod in the same namespace. You can write a pod spec that refers to a ConfigMap and configures the containers in that pod based on its ConfigMap data.
The ConfigMap object must exist before you reference it in a pod specification, or the pod won’t start.
Why use Kubernetes ConfigMaps?
Many applications rely on configuration data used during either initialization or runtime. This process often requires adjusting values assigned to configuration parameters — and Kubernetes uses ConfigMaps to inject application pods with configuration data.
Keeping configuration data separate from your app code is one of the essential parts of the Twelve-factor Application methodology1. It lets you easily change configuration depending on the environment (development, production, testing) and dynamically introduce changes at runtime.
A ConfigMap also doesn’t provide secrecy or encryption. If the data you want to store in a ConfigMap is confidential, Kubernetes Secrets will be much better suited for the job.
What are Kubernetes Secrets?
Similar to ConfigMaps, Kubernetes Secrets are API objects specifically built to store confidential data.
Kubernetes Secrets contain small amounts of sensitive data, such as passwords, tokens, or keys. This type of information might be put in pod specs or a container image. However, thanks to a Secret, you can keep your confidential data separate from your app code.
You can create a Secret independently of the pod that uses it. This ability reduces the risk of the data being exposed in the process of creating and editing your pods.
There are several types of Secrets to choose from, depending on the kind of data you wish to keep private. The most commonly used type is Opaque for handling arbitrary user-defined data. For basic authentication, the common choice is basic-auth.
ConfigMaps and Secrets vs CAST AI
Connecting your cluster is a necessary step if you want to get CAST AI’s cost monitoring and optimization recommendations. The same action unlocks security vulnerability scanning and best practice checks.
This requires installing a read-only agent, which sometimes raises questions about how it may affect your configuration security — so here’s what you need to know.
First of all, you can review the agent’s code in GitHub before running it.
The script runs a kubectl command which affects the cluster you connect to CAST AI, but it never touches any of your configuration data, including ConfigMaps and Secrets.
When connecting the cluster for the first time, you can expect the agent to create the following elements:
- namespace/castai-agent
- serviceaccount/castai-agent
- clusterrole.rbac.authorization.k8s.io/castai-agent
- clusterrolebinding.rbac.authorization.k8s.io/castai-agent
- role.rbac.authorization.k8s.io/castai-agent
- rolebinding.rbac.authorization.k8s.io/castai-agent
- secret/castai-agent
- configmap/castai-agent-autoscaler
- deployment.apps/castai-agent
Once installed, the agent pulls metadata about your workloads, their names, pods, and nodes to determine your cluster’s efficiency. The agent’s ClusterRole has only permission to get, list, and watch limited resources.
Moreover, the read-only agent can’t change your configuration and poses no risk of downtime. Its CPU, memory, and network use is minimal and typically lower than the rounding error for compute.
When you decide to remove it from your cluster, you can do it with a single command in the terminal:
kubectl delete namespace castai-agent
Enhance Kubernetes configuration security
As mentioned, connecting your cluster to CAST AI lets you achieve two distinct sets of goals.
What may have originally brought you to the platform are powerful cost and performance optimization ideas for your cluster. CAST AI users usually save around 65% off their regular Kubernetes bill.
But apart from that, the platform also lets you automatically check and improve your cluster configuration security.
The security report from CAST AI scans your cluster for potential vulnerabilities, compares its state against industry best practices, and suggests ways to secure it optimally. You can find its documentation here.
You can use CAST AI’s demo cluster to explore the security report without connecting your cluster. Sign up and it will be available on the main screen.
Over to you
Kubernetes ConfigMaps and Secrets reduce the risk of exposing cluster data by decoupling application code and configurations.
While ConfigMaps are sufficient for storing non-sensitive config details in key-value pairs, for sensitive data Secrets work better, as they allow for encryption and access restriction. Enabling RBAC lets you further limit who can retrieve your Secrets and ConfigMaps and reduce the odds of unauthorized configuration changes.
By adding CAST AI’s security report to the strategy, you can quickly spot any potential vulnerabilities in your configurations and check your posture against the industry’s standards.