In Kubernetes, ConfigMaps and Secrets are used to store configuration data and secrets, respectively. ConfigMaps store configuration data as key-value pairs, while Secrets store sensitive data in an encrypted form.

• Example :- Imagine you're in charge of a big spaceship (Kubernetes cluster) with lots of different parts (containers) that need information to function properly. ConfigMaps are like a file cabinet where you store all the information each part needs in simple, labeled folders (key-value pairs). Secrets, on the other hand, are like a safe where you keep the important, sensitive information that shouldn't be accessible to just anyone (encrypted data). So, using ConfigMaps and Secrets, you can ensure each part of your spaceship (Kubernetes cluster) has the information it needs to work properly and keep sensitive information secure! 🚀

In this blog post, we'll explore ConfigMaps and Secrets, two fundamental Kubernetes resources for managing application configurations.

ConfigMaps

A ConfigMap is a Kubernetes resource used to store non-confidential data in key-value pairs. It allows you to decouple environment-specific configuration from your containerized application, making your application more portable.

Use Cases for ConfigMaps:

• Storing configuration files

• Setting environment variables for a container

• Command-line arguments for your application

• Populating configuration files via templates

Creating a ConfigMap:

You can create a ConfigMap using a YAML file or directly from the command line. Here's an example using a YAML file:

Create Namespace

kubectl create namespace config-secret

Create configmap.yml file

kind: ConfigMap
apiVersion: v1
metadata:
  name: mysql-config
  namespace: config-secret
  labels:
    app: my-app
data:
  MYSQL_DB: "my-db"

Apply it with:

kubectl apply -f configmap.yml -n config-secret

Verify that the ConfigMap has been created by checking the status of the ConfigMaps in your Namespace.

kubectl get configmaps -n config-secret

Secrets

Secrets, as the name suggests, are intended for storing confidential information, like passwords, API keys, or tokens. Kubernetes ensures that the data stored in Secrets is more secure by default; it's stored encrypted at rest and can be accessed in a controlled manner.

Use Cases for Secrets: Storing database credentials, API tokens, SSL certificates

Creating a Secret:

Before we create a secret, we need to create a base64 encoded string of the database password that we will use in our deployment.yml file.

I'm taking the following details as secret key. Following details as secret key:

• Password : test123

echo -n 'test123' | base64

For verifying the secret key, we can use the following command:

echo -n 'dGVzdDEyMw==' | base64 --decode

Create a Secret that stores the database password and mount it as a volume in the deployment.

apiVersion: v1
kind: Secret
metadata:   
  name: my-secret
  namespace: config-secret
type: Opaque
data:
  password: dGVzdDEyMw==

What is the Opaque type? : The opaque type is used to store arbitrary data in secret objects.

Apply the updated deployment using the command:

kubectl apply -f secret.yml -n config-secret

Verify that the Secret has been created by checking the status of the Secrets in your Namespace.

kubectl get secrets -n config-secret

Now let's create a deployment.yml file for our deployment in which we add both configmap and secret in the deployment file.

 apiVersion: apps/v1
 kind: Deployment
 metadata:
   name: mysql-configuration
   labels:
     app: my-app
   namespace: config-secret 
 spec:
   replicas: 2
   selector:
     matchLabels:
       app: my-app
   template:
     metadata:
       labels:
         app: my-app
     spec:
       containers:
       - name: mysql-container
         image: mysql:8
         ports:
         - containerPort: 3306
         env:
         - name: MYSQL_ROOT_PASSWORD
           valueFrom:
             secretKeyRef:
               name: my-secret
               key: password
         - name: MYSQL_DATABASE
           valueFrom:
             configMapKeyRef:
               name: mysql-config
               key: MYSQL_DB

In this yaml file, we have added both configmap and secret in the deployment file.

Apply the updated deployment using the command:

kubectl apply -f deployment.yml -n config-secret

kubectl get pods -n config-secret

Best Practices:

1. Avoid Hardcoding: Never hardcode configuration values or secrets in your application code. Use ConfigMaps and Secrets instead.

2. Environment-specific ConfigMaps: Consider creating separate ConfigMaps for different environments, e.g., dev, staging, production.

3. Secrets Management: While Kubernetes Secrets are a step up from plaintext configuration, they are not a full-fledged secrets management solution. Consider integrating with tools like HashiCorp Vault for more robust secrets management.

4. Limit Access: Use Role-Based Access Control (RBAC) to limit who can read and write to Secrets.

5. Immutable Configurations: Once created, treat ConfigMaps and Secrets as immutable. If you need to change them, create a new version.

6. Use References: Instead of embedding the actual values, reference ConfigMaps and Secrets in your Pods.

Conclusion:

ConfigMaps and Secrets are foundational components in Kubernetes for managing non-sensitive and sensitive configuration data, respectively. They enable Kubernetes applications to be more portable, scalable, and maintainable by separating configuration from the application code. When used wisely, along with best practices, they play a crucial role in making your Kubernetes deployments more efficient and secure.