Simplifying Container Configuration in Kubernetes with Secrets and ConfigMaps

Introduction:

Kubernetes has revolutionized container orchestration, providing a robust platform for managing and scaling containerized applications. One of the key challenges in container deployment is managing the configuration of individual container instances without modifying the container image itself. Kubernetes addresses this challenge with two powerful features: Secrets and ConfigMaps. In this blog post, we will explore how Secrets and ConfigMaps can simplify container configuration in Kubernetes, using the example of running a MariaDB database container.

Understanding Secrets:

Secrets in Kubernetes are designed for storing small amounts of sensitive data, such as passwords, API keys, or certificates. While Secrets are base64-encoded within Kubernetes, they are not considered highly secure. For extremely sensitive data, it is recommended to use external tools like HashiCorp Vault. However, Secrets are suitable for storing credentials like database passwords.

Creating a Secret:

To create a Secret for the MariaDB root password, we need to base64-encode the password and store it in a YAML file. For example, if the root password is "KubernetesRocks!", the base64-encoded value would be "S3ViZXJuZXRlc1JvY2tzIQ==".

We create a YAML file called mysql-secret.yaml with the following content:

apiVersion: v1
kind: Secret
metadata:
  name: mariadb-root-password
type: Opaque
data:
  password: S3ViZXJuZXRlc1JvY2tzIQ==

Applying the Secret:

We can apply the Secret to Kubernetes using the kubectl apply command:

kubectl apply -f mysql-secret.yaml

Once applied, we can verify the creation of the Secret using kubectl describe secret mariadb-root-password.

Decoding the Secret:

To view the Secret value in plain text, we can decode it using the following command:

kubectl get secret mariadb-root-password -o jsonpath='{.data.password}' | base64 --decode -

This command retrieves the base64-encoded Secret value and decodes it, displaying the actual password.

Working with ConfigMaps:

ConfigMaps are Kubernetes objects used for storing non-sensitive configuration data, such as environment variables or configuration files. They can be created manually or using the kubectl create configmap command.

Creating a ConfigMap:

To create a ConfigMap for the MariaDB container, we can use an existing configuration file, such as max_allowed_packet.cnf, which overrides a default configuration value.

First, we create the configuration file with the desired content:

[mysqld]
max_allowed_packet = 64M

Next, we create the ConfigMap using the kubectl create configmap command:

kubectl create configmap mariadb-config --from-file=max_allowed_packet.cnf

Verifying the ConfigMap:

We can verify the creation of the ConfigMap using kubectl describe configmap mariadb-config or kubectl get configmap mariadb-config.

Using Secrets and ConfigMaps in a Deployment:

Now that we have our Secrets and ConfigMaps, we can integrate them into a Kubernetes Deployment for the MariaDB container.

In the Deployment YAML file, we specify the Secrets as environment variables and mount the ConfigMap as a file within the container.

For example, we can add the following to the container spec in the Deployment:

env:
  - name: MYSQL_ROOT_PASSWORD
    valueFrom:
      secretKeyRef:
        name: mariadb-root-password
        key: password
envFrom:
  - secretRef:
      name: mariadb-user-creds

This configuration sets the MYSQL_ROOT_PASSWORD environment variable from the mariadb-root-password Secret and sets all key-value pairs from the mariadb-user-creds Secret as environment variables.

Additionally, we can mount the mariadb-config ConfigMap as a file within the container:

volumeMounts:
  - mountPath: /etc/mysql/conf.d
    name: mariadb-config-volume
volumes:
  - configMap:
      name: mariadb-config
      items:
        - key: max_allowed_packet.cnf
          path: max_allowed_packet.cnf
    name: mariadb-config-volume

Conclusion:

By leveraging Kubernetes Secrets and ConfigMaps, we can separate the configuration of individual container instances from the container image itself. This approach offers numerous advantages, such as reducing image maintenance overhead, enabling flexible configuration options, and enhancing security by keeping sensitive data separate. In this blog post, we explored how to create and use Secrets and ConfigMaps for a MariaDB container, demonstrating their power and versatility in simplifying container configuration in Kubernetes.

With Secrets and ConfigMaps, Kubernetes empowers developers and operators to effectively manage containerized applications, making it easier to scale, maintain, and secure deployments. By adopting these best practices, you can enhance your Kubernetes workflows and streamline the configuration of your containerized applications.

To connect with me - https://www.linkedin.com/in/subhodey/