Are Kubernete's ConfigMaps Writable?

Question

Is it possible to directly modify the file mounted by configMap? We have an application that reads a configuration file that was configMap type and the application should able to edit the file and the changes should be persisted if the configMap is shared with other pods and when the pod restarts.

If configMap is not meant for this, then what should we relay on consul to save the configuration?

Answer 1

AFAIK the changes to a ConfigMap will only exist locally in-memory.
That is, changes aren't visible to other pods and on a pod restart the changes will be lost.

One solution is to use the kubectl binary or the kubernetes API from within the configuring application to recreate the ConfigMap after the configuration changes.

e.g. kubectl apply -f /path/to/updated/config.yaml

Answer 2

@RyanDawson might be correct from the perspective of what configmaps are intended for, but from a technical standpoint, they are very writable. And you won't be in bad company if you do. Consider for example Flink, which manages its HA state by writing it to configmaps.

And while @stacksonstacks is correct that configmaps can be written to by using kubectl, this is only half the way: If you want to update the configmap from your application, that means you need write access to configmaps from inside an application on k8s. And it's unlikely that you want to store your personal k8s API access token in a secret.

The best solution to this access problem is to give the pod that is supposed to write to the configmap a service account. This service account needs to be bound to a role that allows the actual access. With the service account, the pod will gain access to a secret token at /var/run/secrets/kubernetes.io/serviceaccount/ which can be used to access the kubernetes API. This token will also be automatically be picked up by kubectl.

I can't find a full example setup on the kubernetes documentation (you probably need to gather the details from the rbac and serviceaccount pages), so I'll add an example setup that continuously updates a configmap with the current time:

---
# Equivalent to whatever would be your application
apiVersion: apps/v1
kind: Deployment
metadata:
  name: configmap-updater
  labels:
    app: configmap-updater
spec:
  selector:
    matchLabels:
      name: configmap-updater
  template:
    metadata:
      labels:
        name: configmap-updater
    spec:
      serviceAccountName: configmap-update-sa # secrets automounted at /var/run/secrets/kubernetes.io/serviceaccount/
      containers:
      - name: configmap-updater-container
        image: archlinux
        # You could also use kubectl patch configmap hello -p '{"data": {"now":"'$(date +%s)'"}}'
        # But I couldn't find an image that has kubectl preinstalled on the spot,
        # so here you go: curl api client
        command: 
          - bash
          - -euc
          - |
            sec=/var/run/secrets/kubernetes.io/serviceaccount
            while true; do
              sleep 10;
              curl -sS \
                   -H "Authorization: Bearer $(cat $sec/token)" \
                   -H "Content-Type: application/json-patch+json" \
                   --cacert $sec/ca.crt \
                   --request PATCH \
                   --data '[{"op": "replace", "path": "/data", "value": {"now":"'$(date +%s)'","updater":"'$(cat /etc/hostname)'"}}]' \
                   https://$KUBERNETES_SERVICE_HOST/api/v1/namespaces/default/configmaps/hello
            done
---
# The configmap to be updated
apiVersion: v1
kind: ConfigMap
metadata:
  name: hello
---
# And the access setup
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: configmap-update-sa
---
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: configmap-update-binding
subjects:
- kind: ServiceAccount
  name: configmap-update-sa
  namespace: default
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: configmap-update-role
---
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: configmap-update-role
# Benefit of using RBAC over giving your personal access token as a secret to your application: You can pinpoint which access you want to allow
rules:
- apiGroups: [""] # Empty string for kubernetes system
  resources: [configmaps]
  resourceNames: [hello]
  verbs: [patch]

(I've tested this in minikube and know that it works in EKS. If this approach doesn't work somewhere, I'd be happy to know about it.)

If updating configmaps to hold state feels too dirty, one possibility may be to create a custom resource definition and give it some state attributes. That might express your intent better. But you won't be able to mount a CRD as a file, and from kubernetes' point of view, it will be very much the same, just some data changing.