Kubernetes (part-7)

Understanding ConfigMap: Simplify Your Kubernetes Configuration Management

It is used to store non-confidential configuration data in key-value pairs. It keep configuration separate from the application code, that makes it easier to manage and update without redeploying the entire application

Example 1: Passing Database User to MySQL Pod Using ConfigMap

Create the ConfigMap (cm1.yaml): The ConfigMap will contain the database user and password

# cm1.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: bootcamp-configmap
data:
  username: "saiyam"
  database_name: "exampledb"

```basic
kubectl apply -f cm1.yaml
```

Create the Pod (pod1.yaml): The Pod will run a MySQL container and use the environment variables from the ConfigMap

# pod1.yaml
apiVersion: v1
kind: Pod
metadata:
  name: mysql-pod
spec:
  containers:
  - name: mysql
    image: mysql:5.7
    env:
      - name: MYSQL_USER
        valueFrom:
          configMapKeyRef:
            name: bootcamp-configmap
            key: username
      - name: MYSQL_DATABASE
        valueFrom:
          configMapKeyRef:
            name: bootcamp-configmap
            key: database_name
      - name: MYSQL_PASSWORD
        value: demo123  # Specify a strong password.
      - name: MYSQL_ROOT_PASSWORD
        value: demo345 # You should change this value.
    ports:
      - containerPort: 3306
        name: mysql
    volumeMounts:
      - name: mysql-storage
        mountPath: /var/lib/mysql
  volumes:
    - name: mysql-storage
      emptyDir: {}

```basic
 kubectl apply -f pod1.yaml
```

Access the MySQL Pod: Once the Pod is running, connect to the MySQL container and verify the user setup
```
kubectl exec -it mysql-pod -- mysql -u root -p
```
If asks for password , Use that defined in the ConfigMap
Run MySQL Commands: Inside the MySQL prompt, run the following commands to verify the users and databases:
```
SELECT user FROM mysql.user;
SHOW DATABASES;
```

Example 2: Managing Dev/Prod Properties with ConfigMap

Create the ConfigMap (cm2.yaml)

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config-dev
data:
  settings.properties: |
    # Development Configuration
    debug=true
    database_url=http://dev-db.example.com
    featureX_enabled=false

---

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config-prod
data:
  settings.properties: |
    # Production Configuration
    debug=false
    database_url=http://prod-db.example.com
    featureX_enabled=true

```basic
kubectl apply -f cm2.yaml
```

Create the Pod (pod2.yaml)

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-web-app
spec:
  replicas: 1
  selector:
    matchLabels:
      app: my-web-app
  template:
    metadata:
      labels:
        app: my-web-app
    spec:
      containers:
      - name: web-app-container
        image: nginx  
        ports:
        - containerPort: 80
        env:
        - name: ENVIRONMENT
          value: "development"  
        volumeMounts:
        - name: config-volume
          mountPath: /etc/config
      volumes:
      - name: config-volume
        configMap:
          name: app-config-dev

```yaml
kubectl apply -f pod2.yaml
```

Verify the ConfigMap is Mounted: After the Pod is running, you can check if the settings.properties file has been correctly mounted and read its contents
```
kubectl exec -it app-pod -- cat /etc/config/settings.properties
```
This should display the content of the settings.properties file:
```
# Development Configuration
debug=true
database_url=http://dev-db.example.com
featureX_enabled=false
```
Switch to Production: To use the production configuration instead, update the Deployment to mount app-config-prod.

Change this part in pod2.yaml:
```
configMap:
  name: app-config-prod
```
Reapply the deployment
```
kubectl apply -f pod2.yaml
```
Now, if you check the configuration inside the pod, you’ll see the production settings:
```
# Production Configuration
debug=false
database_url=http://prod-db.example.com
featureX_enabled=true
```

Example 3: Accessing ConfigMap Programmatically with Python

read_config.py: This Python script reads and prints the contents of the app-config ConfigMap in the default namespace

from kubernetes import client, config

def main():
    # Load the Kubernetes configuration
    config.load_incluster_config()

    v1 = client.CoreV1Api()
    config_map_name = 'app-config'
    namespace = 'default'

    try:
        # Read the ConfigMap
        config_map = v1.read_namespaced_config_map(config_map_name, namespace)
        print("ConfigMap data:")
        for key, value in config_map.data.items():
            print(f"{key}: {value}")
    except client.exceptions.ApiException as e:
        print(f"Exception when calling CoreV1Api->read_namespaced_config_map: {e}")

if __name__ == '__main__':
    main()

Dockerfile: This Dockerfile builds the image that runs the Python script.

# Use a lightweight Python image
FROM python:3.8-slim

# Install the Kubernetes Python client
RUN pip install kubernetes

# Copy the Python script
COPY read_config.py /read_config.py

# Set the command to run the script
CMD ["python", "/read_config.py"]

Build the Docker Image: Build the Docker image using the provided Dockerfile and push it to a public image registry (in this case, ttl.sh)
```
docker build -t ttl.sh/hindi-boot:1h .
docker push ttl.sh/hindi-boot:1h
```

app.yaml: This YAML file defines all the Kubernetes resources: the ConfigMap, Deployment, Role, and RoleBinding.

# ConfigMap storing some example properties
apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
  namespace: default
data:
  example.property: "Hello, world!"
  another.property: "Just another example."
---
# Deployment to run the Python script in a pod
apiVersion: apps/v1
kind: Deployment
metadata:
  name: config-reader-deployment
  namespace: default
spec:
  replicas: 1
  selector:
    matchLabels:
      app: config-reader
  template:
    metadata:
      labels:
        app: config-reader
    spec:
      containers:
      - name: config-reader
        image: ttl.sh/hindi-boot:1h
        imagePullPolicy: Always
---
# Role granting read access to ConfigMaps in the default namespace
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: config-reader
rules:
- apiGroups: [""]
  resources: ["configmaps"]
  verbs: ["get", "list", "watch"]
---
# RoleBinding to attach the Role to the default ServiceAccount
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-configmaps
  namespace: default
subjects:
- kind: ServiceAccount
  name: default 
  namespace: default
roleRef:
  kind: Role
  name: config-reader
  apiGroup: rbac.authorization.k8s.io

Apply the Kubernetes Resources: Deploy the ConfigMap, Deployment, and RBAC resources to Kubernetes.
```
kubectl apply -f app.yaml
```
Check the Logs: After the pod is running, you can check the logs to see if the ConfigMap has been read successfully.
```
kubectl logs -l app=config-reader
```
The output should display the content of the ConfigMap
```
ConfigMap data:
example.property: Hello, world!
another.property: Just another example.
```

Secrets in Kubernetes: Securely Manage Sensitive Information

When deploying applications in Kubernetes, you often need to handle sensitive information such as passwords, API keys, or tokens. Storing these directly in your code or configuration files can be insecure. Kubernetes Secrets provide a way to securely store and manage sensitive information.

Unlike ConfigMaps (which store non-sensitive configuration data), Secrets are designed for security. They store data in an encoded format (Base64) and can be mounted into Pods or accessed as environment variables.

Types of Kubernetes Secrets: Opaque, TLS, and Docker Registry

Opaque Secret: General-purpose secret, commonly used for storing credentials.
TLS Secret: Specifically for storing SSL/TLS certificates.
Docker Registry Secret: For storing Docker registry credentials, used for pulling private images.

Example 1: Creating a Kubernetes Secret Using YAML

Encode your values in Base64

bash echo -n 'my-db-username' | base64 echo -n 'my-db-password' | base64
This will return
bash bXktZGItdXNlcm5hbWU= bXktZGItcGFzc3dvcmQ=

Create the Secret YAML file (secret.yaml)

yaml apiVersion: v1 kind: Secret metadata: name: db-secret type: opaque data: username: bXktZGItdXNlcm5hbWU= password: bXktZGItcGFzc3dvcmQ=
Apply the secret
bash kubectl apply -f secret.yaml

To view the secret

bash kubectl get secret

To decrypt the encrypted data

bash echo "put-encrypted-data" | base64 -d

Example 2: Creating a Kubernetes Secret from the Command Line

kubectl create secret generic db-secret \
  --from-literal=username=my-db-username \
  --from-literal=password=my-db-password

Using Secrets in a Pod: Environment Variables and Volume Mounts

Once the Secret is created, you can use it in a Pod as either environment variables or mounted as files

Example: Using a Secret as Environment Variables

apiVersion: v1
kind: Pod
metadata:
  name: db-app
spec:
  containers:
  - name: app-container
    image: my-app:latest
    env:
    - name: DB_USERNAME
      valueFrom:
        secretKeyRef:
          name: db-secret
          key: username
    - name: DB_PASSWORD
      valueFrom:
        secretKeyRef:
          name: db-secret
          key: password

Here, the username and password from the Secret are injected into the container as environment variables

Example: Mounting a Secret as a Volume

apiVersion: v1
kind: Pod
metadata:
  name: app-with-secret
spec:
  containers:
  - name: app-container
    image: my-app:latest
    volumeMounts:
    - name: secret-volume
      mountPath: /etc/secrets
      readOnly: true
  volumes:
  - name: secret-volume
    secret:
      secretName: db-secret

This will mount the Secret’s data into /etc/secrets/ inside the container

Storing SSH Private Keys in Kubernetes Secrets

kubectl create secret generic my-ssh-key-secret \
--from-file=ssh-privatekey=/path/to/.ssh/id_rsa \
--type=kubernetes.io/ssh-auth

--from-file=ssh-privatekey=/path/to/.ssh/id_rsa:

--from-file: Specifies that the content for the Secret should come from a file.

ssh-privatekey: The key under which the private key will be stored in the Secret.

/path/to/.ssh/id_rsa: Path to the actual SSH private key file (usually located in ~/.ssh/id_rsa).

--type=kubernetes.io/ssh-auth:

This specifies that the Secret is of type kubernetes.io/ssh-auth, which is used for SSH authentication.

Managing SSL/TLS Certificates with Kubernetes TLS Secrets

kubectl create secret tls my-tls-secret \
--cert=path/to/cert/file \
--key=path/to/key/file

--cert=path/to/cert/file:

This specifies the path to the TLS certificate file. Replace path/to/cert/file with the actual path to your .crt (certificate) file.

--key=path/to/key/file:

This specifies the path to the TLS private key file. Replace path/to/key/file with the actual path to your private key file (typically .key).

MySQL Example: Combining ConfigMap and Secrets in Kubernetes

create a configmap (myconfig.yaml)

apiVersion: v1
kind: configMap
metadata:
   name: bootcamp-configMap
data: 
   username: "praduman"
   database_name: "my-db"

```bash
kubectl apply -f myconfig.yaml
```

create secrets (mysecret.yaml)

echo -n 'rootPass' | base64
echo -n 'userPass' | base64

```yaml
apiVersion: v1
kind: Secret
metadata: 
   name: mysql-root-pass
type: Opaque
data: 
   password: <use-base64-encoded>
---
apiVersion: v1
kind: Secret
metadata: 
   name: mysql-user-pass
type: Opaque
data: 
   password: <use-base64-encoded>
```

```bash
kubectl apply -f mysecret.yaml
```

YAML file of deployment using both configMap and Secret(deploy.yaml)

apiVersion: apps/v1
kind: Deployment
metadata:
  name: mysql
spec:
  selector:
    matchLabels:
      app: mysql
  template:
    metadata:
      labels:
        app: mysql
    spec:
      containers:
      - name: mysql
        image: mysql:5.7
        env:
          - name: MYSQL_ROOT_PASSWORD
            valueFrom:
              secretKeyRef:
                name: mysql-root-pass
                key: password
          - name: MYSQL_USER
            valueFrom:
              configMapKeyRef:
                name: bootcamp-configmap
                key: username
          - name: MYSQL_PASSWORD
            valueFrom:
              secretKeyRef:
                name: mysql-user-pass
                key: password
          - name: MYSQL_DATABASE
            valueFrom:
              configMapKeyRef:
                name: bootcamp-configmap
                key: database_name
        ports:
          - containerPort: 3306
        volumeMounts:
          - name: mysql-storage
            mountPath: /var/lib/mysql
      volumes:
        - name: mysql-storage
          emptyDir: {}

```bash
kubectl apply -f deploy.yaml
```

Access the MYSQL pod

kubectl exec -it <pod-name> -- mysql -u root -p

Conclusion

In this article, we explored the essential concepts of Kubernetes ConfigMaps and Secrets, highlighting their importance in managing configuration data and sensitive information securely. ConfigMaps allow you to decouple configuration from application code, making updates seamless without redeploying the entire application. Secrets, on the other hand, provide a secure way to handle sensitive data like passwords and API keys, ensuring they are not exposed in your codebase.

We provided practical examples demonstrating how to use ConfigMaps and Secrets in various scenarios, such as passing database credentials to a MySQL Pod, managing environment-specific properties, and accessing configuration programmatically with Python. Additionally, we covered the different types of Secrets, including Opaque, TLS, and Docker Registry Secrets, and how to use them in Pods as environment variables or volume mounts.

By understanding and implementing these Kubernetes features, you can enhance the security and manageability of your applications, ensuring a more robust and flexible deployment process.