Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Kubernetes - setting custom permissions/file ownership per volume (and not per pod)

Tags:

kubernetes

Is there any way to set per-volume permissions/ownership in Kubernetes declaratively?

Usecase:

  • a pod is composed of two containers, running as two distinct users/groups, both of them non-root, and are unable to sudo
  • the containers mount a volume each, and need to create files in these volumes (e.g. both of them want to write logs)

We know that we can use fsGroup, however that is a pod-level declaration. So even if we pick fsGroup equal to user in first container, then we are going to have permission issues in the other one. (ref: Kubernetes: how to set VolumeMount user group and file permissions)

like image 280
Adam Kotwasinski Avatar asked Oct 27 '17 11:10

Adam Kotwasinski


People also ask

What is the difference between volume and persistent volume in Kubernetes?

Kubernetes supports many types of volumes. A Pod can use any number of volume types simultaneously. Ephemeral volume types have a lifetime of a pod, but persistent volumes exist beyond the lifetime of a pod.

How can you know a pod using the sidecar pattern or not?

A pod that contains one container refers to a single container pod and it is the most common kubernetes use case. A pod that contains Multiple co-related containers refers to a multi-container pod. There are few patterns for multi-container pods one of them is the sidecar container pattern.

Can Kubernetes pods share volume?

Kubernetes volumes In Kubernetes, a pod is a group of containers with shared storage and network resources. This means that containers with a shared storage will be able to communicate with each other. Kubernetes uses volumes as an abstraction layer to provide shared storage for containers.


2 Answers

One solution is to use init-container to change permissions of mounted directories.

The init-container would need to mount both volumes (from both containers), and do the needed chown/chmod operations.

Drawbacks:

  • extra container that needs to be aware of other containers' specific (ie. uid/gid)
  • init container needs to run as root to perform chown
like image 97
Adam Kotwasinski Avatar answered Nov 15 '22 14:11

Adam Kotwasinski


It can be done with adding one init container with root access.

    initContainers:
    - name: changeowner
      image: busybox
      command: ["sh", "-c", "chown -R 200:200 /<volume>"]   
      volumeMounts:
      - name: <your volume>
        mountPath: /<volume>
like image 28
rajdeepbs29 Avatar answered Nov 15 '22 16:11

rajdeepbs29