# Day 30 - Kubernetes ConfigMaps & Secrets

# **1\. What is a ConfigMap in Kubernetes?**

A **ConfigMap** is used to store **non-sensitive configuration data** that your application needs — such as:

* Database port
    
* Connection type
    
* Any general configuration values
    

In normal applications (non-Kubernetes), developers normally store such info using:

* Environment variables
    
* Configuration files
    
* OS environment values
    

**Why?** Because you should *never hardcode* values inside an application, especially because they might change in future.

### ⭐ In Kubernetes, a ConfigMap helps you store such non-sensitive values and inject them into Pods:

You can inject ConfigMap data into a Pod as:

1. **Environment Variables**, or
    
2. **Files using Volume Mounts**
    

---

# **2\. Why do Secrets exist if ConfigMaps already store data?**

Because ConfigMaps store data **in plain text**.

In Kubernetes:

* All resources (Pods, Deployments, ConfigMaps, etc.) are stored in **etcd**.
    
* ConfigMap values are **NOT encrypted** in etcd.
    

If a hacker gains access to etcd, they can read ConfigMap data easily.

But for sensitive data like:

* DB Password
    
* API Keys
    
* Token
    
* Certificates
    

**Kubernetes provides Secrets.**

---

# **3\. What is a Secret? Why is it different?**

A **Secret** is used to store **sensitive** information.

Kubernetes Secrets provide security in two major ways:

### **1\. Secrets are encrypted at rest (in etcd)**

Before storing Secrets in etcd, Kubernetes encrypts the values.  
Even if someone gets etcd access, they cannot read the contents without the decryption key.

### **2\. You can enforce strong RBAC on Secrets**

You can configure RBAC so that:

* Developers can access Pods, Deployments, ConfigMaps
    
* But *cannot* access Secrets
    

This protects sensitive data even more.

---

# **4\. ConfigMap vs Secret — Interview Style Answer**

| Feature | ConfigMap | Secret |
| --- | --- | --- |
| Purpose | Store non-sensitive config | Store sensitive data |
| Encryption at rest | ❌ No | ✅ Yes |
| RBAC use | Normal | Strongly recommended |
| Storage in etcd | Plain text | Base64 + Encryption |
| Use case | Ports, URLs, Settings | Passwords, keys, tokens |

**Both** are used to pass data into Pods, but:

* **ConfigMap = non-sensitive**
    
* **Secret = sensitive**
    

---

# **5\. How Kubernetes handles ConfigMap & Secret creation**

When you create:

* ConfigMap or
    
* Secret
    

using `kubectl apply -f file.yaml`:

✔ The API server takes the YAML  
✔ Stores it inside etcd  
✔ Makes it available for Pods

---

# **6\. Problem with environment variable updates**

If you use **ConfigMap as environment variables**, there is a limitation:

❗ **If ConfigMap value changes → existing Pods will NOT update automatically.**

Why?

Because container environment variables **cannot be changed** without restarting the container.

This is a well-known container limitation.

### Solution

Use **volume mounts** instead of environment variables.

---

# **7\. Using ConfigMap as a Volume Mount**

When you mount a ConfigMap as a volume:

* Kubernetes maps each key-value pair as a separate file.
    
* When the ConfigMap updates:
    
    * Kubernetes updates the file contents inside the container automatically
        
    * **Without restarting the Pod**
        

This is extremely useful for dynamic configuration.

Example:

```plaintext
/opt/DBPort
```

contains:

```plaintext
3306
```

If ConfigMap changes to `3307`, the file updates automatically in 2–10 seconds.

---

# **8\. Why volume mount method is more dynamic**

✔ Pod does NOT restart  
✔ Container does NOT restart  
✔ File content updates automatically  
✔ Application can read updated values

If your app watches the file, it can adjust configuration dynamically.

---

# **9\. Secrets work the exact same way**

Just like ConfigMaps:

✔ Secrets can be injected

* As environment variables, or
    
* As volume mounts
    

✔ Updating the Secret updates the mounted file automatically.

✔ But environment variables still require Pod restart.

---

# **10\. Bonus: Types of Secrets**

Kubernetes supports:

* `generic` (normal key-value)
    
* `docker-registry`
    
* `tls` (for certificates)
    
* `opaque` (default)
    
* `service account token secrets`
    

---

# **Conclusion**

Your full explanation boils down to this:

### ⭐ ConfigMap

Used to store **non-sensitive** configuration.  
Can be used as environment variables or mounted as files.

### ⭐ Secret

Used to store **sensitive** configuration.  
Encrypted in etcd and protected by RBAC.

### ⭐ Environment variable method

Dynamic updates **do not** reflect without Pod restart.

### ⭐ Volume mount method

Dynamic updates reflect **automatically** inside the container.