What are the differences between Kubernetes ConfigMap and Secret? How do you use them to manage application configuration?

Kubernetes ConfigMap and Secret are two important resources for managing configuration data. They allow configuration to be separated from container images, improving application portability and security.

ConfigMap

ConfigMap is used to store non-sensitive configuration data, such as application configuration files, command-line arguments, environment variables, etc.

Ways to Create ConfigMap

1. Create from literal values:

bash
kubectl create configmap my-config --from-literal=key1=value1 --from-literal=key2=value2

1. Create from file:

bash
kubectl create configmap my-config --from-file=config.properties

1. Create from directory:

bash
kubectl create configmap my-config --from-file=./config-dir/

1. Create from YAML file:

yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: my-config
data:
  key1: value1
  key2: value2
  app.properties: |
    server.port=8080
    database.url=jdbc:mysql://localhost:3306/mydb

Ways to Use ConfigMap

1. As environment variables:

yaml
apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  - name: my-container
    image: nginx
    env:
    - name: KEY1
      valueFrom:
        configMapKeyRef:
          name: my-config
          key: key1

1. As command-line arguments:

yaml
apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  - name: my-container
    image: nginx
    command: ["/bin/sh", "-c"]
    args: ["echo $(KEY1)"]
    env:
    - name: KEY1
      valueFrom:
        configMapKeyRef:
          name: my-config
          key: key1

1. Mount as files:

yaml
apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  - name: my-container
    image: nginx
    volumeMounts:
    - name: config-volume
      mountPath: /etc/config
  volumes:
  - name: config-volume
    configMap:
      name: my-config

Secret

Secret is used to store sensitive information, such as passwords, OAuth tokens, SSH keys, certificates, etc.

Secret Types

1. Opaque: Default type for storing arbitrary user data

2. kubernetes.io/service-account-token: Used to store Service Account tokens

3. kubernetes.io/dockercfg: Used to store Docker registry credentials

4. kubernetes.io/dockerconfigjson: Used to store Docker registry JSON configuration

5. kubernetes.io/basic-auth: Used to store basic authentication credentials

6. kubernetes.io/ssh-auth: Used to store SSH authentication credentials

7. kubernetes.io/tls: Used to store TLS certificates

Ways to Create Secret

1. Create from literal values:

bash
kubectl create secret generic my-secret --from-literal=username=admin --from-literal=password=secret123

1. Create from file:

bash
kubectl create secret generic my-secret --from-file=./username.txt --from-file=./password.txt

1. Create from YAML file:

yaml
apiVersion: v1
kind: Secret
metadata:
  name: my-secret
type: Opaque
data:
  username: YWRtaW4=
  password: c2VjcmV0MTIz

Note: Values in the data field of Secret must be Base64 encoded.

1. Using stringData:

yaml
apiVersion: v1
kind: Secret
metadata:
  name: my-secret
type: Opaque
stringData:
  username: admin
  password: secret123

stringData will automatically perform Base64 encoding.

Ways to Use Secret

Secret can be used in the same ways as ConfigMap:

1. As environment variables:

yaml
apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  - name: my-container
    image: nginx
    env:
    - name: USERNAME
      valueFrom:
        secretKeyRef:
          name: my-secret
          key: username

1. Mount as files:

yaml
apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  - name: my-container
    image: nginx
    volumeMounts:
    - name: secret-volume
      mountPath: /etc/secrets
  volumes:
  - name: secret-volume
    secret:
      secretName: my-secret

1. Pull images:

yaml
apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  - name: my-container
    image: my-private-registry/my-image
  imagePullSecrets:
  - name: registry-secret

Differences Between ConfigMap and Secret

Feature	ConfigMap	Secret
Data Type	Non-sensitive data	Sensitive data
Storage	Plain text	Base64 encoded (not encrypted)
Access Control	Normal RBAC	Stricter RBAC
Size Limit	1 MiB	1 MiB
Mount Methods	Files, environment variables	Files, environment variables

Security Best Practices

1. Use Secret for sensitive data: Never store passwords, keys, or other sensitive information in ConfigMap.

2. Enable Secret encryption: Use KMS (Key Management Service) to encrypt Secrets in etcd.

3. Limit Secret access: Use RBAC to restrict access to Secrets.

4. Use temporary files: Mount Secrets as temporary files (tmpfs) to avoid persistence to disk.

5. Regularly rotate keys: Regularly update sensitive information in Secrets.

6. Use external key management: For high security requirements, consider using external key management systems (such as HashiCorp Vault).

7. Audit Secret access: Enable audit logging to record access to Secrets.

Important Notes

1. Base64 is not encryption: Data in Secret is only Base64 encoded, not encrypted, and requires additional security measures.

2. Size limit: Both ConfigMap and Secret have a 1 MiB size limit. Exceeding this limit requires splitting.

3. Version management: Updates to ConfigMap and Secret do not automatically trigger Pod restarts. You need to use Deployment's rolling updates or manual restarts.

4. Immutability: ConfigMap and Secret can be set to immutable to improve performance and security.