Kubernetes Env File Equivalents: Secrets & ConfigMaps

• Introduction
• Step-by-Step Guide
• Code Example
• Additional Notes
• Summary
• Conclusion
• References

Managing environment variables in Kubernetes differs from Docker. Kubernetes leverages ConfigMaps and Secrets instead of directly using env-file. This approach enhances security and reusability in managing application configurations.

In Kubernetes, you don't directly use env-file like in Docker. Instead, you use ConfigMaps and Secrets.

1. ConfigMaps for Non-Sensitive Data

• Create a file (e.g., config.env) with your environment variables:

  API_KEY=your_api_key
  DATABASE_URL=your_database_url
  

• Create a ConfigMap from the file:

  kubectl create configmap my-config --from-env-file=config.env

• Mount the ConfigMap as environment variables in your Pod definition:

  apiVersion: v1
  kind: Pod
  ...
  spec:
    containers:
    - name: my-container
      image: my-image
      envFrom:
      - configMapRef:
          name: my-config

2. Secrets for Sensitive Data

• For sensitive data like passwords, use Secrets. Create a file (e.g., secrets.env):

  DB_PASSWORD=your_db_password
  

• Create a Secret from the file:

  kubectl create secret generic my-secrets --from-env-file=secrets.env

• Mount the Secret similarly to ConfigMaps:

  apiVersion: v1
  kind: Pod
  ...
  spec:
    containers:
    - name: my-container
      image: my-image
      envFrom:
      - secretRef:
          name: my-secrets

Key Points:

• Choose ConfigMaps for non-sensitive configuration and Secrets for sensitive data.
• You can also define environment variables directly in your Pod definition, but using ConfigMaps and Secrets promotes reusability and security.
• Tools like Kustomize can help manage environment variables from files in more complex deployments.

This code demonstrates managing environment variables in Kubernetes using ConfigMaps and Secrets. It shows creating a ConfigMap for non-sensitive data from a file and a Secret for sensitive data from another file. Both are then used in a Pod definition to inject environment variables into a container. The example uses nginx as a placeholder image and highlights separating sensitive and non-sensitive configurations.

This example demonstrates how to use ConfigMaps and Secrets to manage environment variables in Kubernetes.

1. ConfigMaps for Non-Sensitive Data

config.env:

API_KEY=your_api_key
DATABASE_URL=your_database_url

Create ConfigMap:

kubectl create configmap my-config --from-env-file=config.env

Pod Definition (my-pod.yaml):

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  - name: my-container
    image: nginx:latest
    envFrom:
    - configMapRef:
        name: my-config

Apply Pod Definition:

kubectl apply -f my-pod.yaml

2. Secrets for Sensitive Data

secrets.env:

DB_PASSWORD=your_db_password

Create Secret:

kubectl create secret generic my-secrets --from-env-file=secrets.env

Update Pod Definition (my-pod.yaml):

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  - name: my-container
    image: nginx:latest
    envFrom:
    - configMapRef:
        name: my-config
    - secretRef:
        name: my-secrets

Apply Updated Pod Definition:

kubectl apply -f my-pod.yaml

Key Points:

• This example uses nginx:latest as a placeholder image. Replace it with your application image.
• The envFrom field in the Pod definition allows you to inject environment variables from multiple sources.
• Remember to keep your sensitive data in Secrets and non-sensitive data in ConfigMaps.
• This is a basic example. For more complex scenarios, consider using tools like Kustomize or Helm.

Security:

• Secrets are NOT encrypted, just encoded: While Secrets offer a more secure way to handle sensitive data than directly embedding it in Pod definitions, they are base64 encoded by default, not encrypted. This means anyone with access to the Secret object can decode the data.
• Consider Encryption: For stronger security, use a dedicated secret management solution like HashiCorp Vault, which integrates with Kubernetes and provides encryption at rest and in transit.
• Limit Secret Access: Use Role-Based Access Control (RBAC) in Kubernetes to restrict which users or service accounts can access specific Secrets.

Best Practices:

• Separate ConfigMaps and Secrets: Maintain a clear separation between configuration data (ConfigMaps) and sensitive information (Secrets).
• Version Control: Store your ConfigMap and Secret definitions in version control (e.g., Git) alongside your application code for better tracking and rollback capabilities.
• Use Templating Tools: For more complex deployments, leverage templating tools like Helm or Kustomize to manage and inject environment variables from ConfigMaps and Secrets efficiently.
• Avoid Storing Large Files: ConfigMaps and Secrets are not designed for storing large files. For large configuration files or data volumes, consider using PersistentVolumes.

Alternatives to envFrom:

• env Field: You can directly specify individual environment variables within the env field of your container definition. However, this approach is less maintainable for a large number of variables.
• Init Containers: Use init containers to fetch secrets or generate configuration files before your main application container starts.

Debugging:

• kubectl describe: Use kubectl describe pod <pod-name> to inspect the environment variables injected into your Pod.
• kubectl logs: View container logs with kubectl logs <pod-name> -c <container-name> to check if environment variables are being accessed correctly within your application.

This article explains how to manage environment variables in Kubernetes using ConfigMaps and Secrets, instead of Docker's env-file.

Steps:

1. Create an environment file: Define your variables in a .env file.
2. Create a ConfigMap or Secret: Use kubectl create configmap or kubectl create secret generic with the --from-env-file flag.
3. Mount in Pod definition: Use envFrom with configMapRef or secretRef to inject variables into your containers.

Benefits:

• Reusability: Easily share configurations across deployments.
• Security: Secrets encrypt sensitive data at rest.
• Flexibility: Manage environment variables separately from container images.

Advanced Tools:

• Kustomize: Simplifies environment variable management in complex deployments.

In conclusion, managing environment variables in Kubernetes diverges from Docker by utilizing ConfigMaps for non-sensitive data and Secrets for sensitive information. This approach, while differing from Docker's env-file, provides enhanced security and reusability. By separating configuration and sensitive data, Kubernetes enables streamlined application deployments and promotes secure handling of sensitive information. Remember to employ best practices such as RBAC, version control, and appropriate tooling like Kustomize for robust and secure environment variable management in your Kubernetes deployments.

• Upgrade Kubernetes on Docker Mac? - Docker Desktop - Docker ... | Is it possible for me to upgrade the Kubernetes that comes with Docker Mac? I just downloaded it from Docker Hub today, and the bundled version of Kubernetes is 1.10.11.
• Kubernetes Equivalent of env-file in Docker | Baeldung on Ops | Learn about the use of the Docker env-file and its equivalent ConfigMaps and Secrets in Kubernetes.
• Variables resolved from env_file but not taking effect in docker ... | My attempt is similar to this example in documentation. I have an image.env file as shown below. IMAGE_REPO=repo IMAGE_NAME=name IMAGE_TAG=latest My docker-compose.yaml is as follows. version: "3.9" services: demo: env_file: - image.env image: "${IMAGE_REPO}/${IMAGE_NAME}:${IMAGE_TAG}" A docker-compose config results in the following. WARNING: The IMAGE_REPO variable is not set. Defaulting to a blank string. WARNING: The IMAGE_NAME variable is not set. Defaulting to a...
• Tips on Moving your Dev Env from Docker Compose to Kubernetes ... | When I first started learning how to write Kubernetes configs, I would sometimes complain to people about it. “They’re so complicated!” they would complain back.
• Kubernetes Documentation Tasks Configure Pods and Containers ... | Many applications rely on configuration which is used during either application initialization or runtime. Most times, there is a requirement to adjust values assigned to configuration parameters. ConfigMaps are a Kubernetes mechanism that let you inject configuration data into application pods. The ConfigMap concept allow you to decouple configuration artifacts from image content to keep containerized applications portable. For example, you can download and run the same container image to spin up containers for the purposes of local development, system test, or running a live end-user workload.
• Kompose not replacing environment variables from .env file · Issue ... | I'm using Kompose version 1.18.0 on Windows 10. When I run kompose convert on my docker compose file, it replaces it with nothing. This is despite docker compose detecting and using the .env file c...
• Define Environment Variables for a Container | Kubernetes | This page shows how to define environment variables for a container in a Kubernetes Pod. Before you begin You need to have a Kubernetes cluster, and the kubectl command-line tool must be configured to communicate with your cluster. It is recommended to run this tutorial on a cluster with at least two nodes that are not acting as control plane hosts. If you do not already have a cluster, you can create one by using minikube or you can use one of these Kubernetes playgrounds:
• Create environment variables from env file with Kustomize · Issue ... | Hi all I try to add/generate a configmap from a file with kuztomize. Previously, I have used the following command to create the configMap: kubectl create configmap service1-env-vars --from-env-fil...
• Secrets | Kubernetes | A Secret is an object that contains a small amount of sensitive data such as a password, a token, or a key. Such information might otherwise be put in a Pod specification or in a container image. Using a Secret means that you don't need to include confidential data in your application code. Because Secrets can be created independently of the Pods that use them, there is less risk of the Secret (and its data) being exposed during the workflow of creating, viewing, and editing Pods.