K
Q

Changing default file owner and group owner of kubernetes secrets files mounted on projected volumes

4/20/2018

I am new to K8S. I have a yaml file which generates kubernetes secrets mounted on projected volumes. Upon execution, I found that the secret files (packaged with secrets) are showing "root" as file owner and group owner. I want to change the file owner and group owner to the same specific user (say 450).

I have tried using "chown" from init container (tried it but failed), but I got error saying "read-only file system" and could not modify file & group owner. I do not want to use "fsGroup" under securitycontext. I observed that the "mode:" option under "items" behaves in unpredictable manner when fsGroup is used.

Is there any way to modify default file and group owner of the kubernetes secret files that are mounted via projected volumes ?

I am providing the sample code below. Suppose I want to change the file & group owner of "password" file (under 'mysecret2') in the below sample. how to achieve it?

apiVersion: v1
kind: Pod
metadata:
  name: volume-test
spec:
  containers:
  - name: container-test
    image: busybox
    volumeMounts:
    - name: all-in-one
      mountPath: "/projected-volume"
      readOnly: true
  volumes:
  - name: all-in-one
    projected:
      sources:
      - secret:
          name: mysecret
          items:
            - key: username
              path: username
      - secret:
          name: mysecret2
          items:
            - key: password
              path: password
              mode: 511
-- user_2011
kubernetes
kubernetes-secrets
mounted-volumes

Similar Questions

Can I safely delete minikube.rawdisk?
Kompose creates many files from one compose file?
Latest MySQL not coming up in Kubernetes
minikube start - multiple times

2 Answers

5/19/2018

As far as I know, there's no way to change owner UID for secrets.

A workaround is to copy a secret to a normal file, then change its ownership and mode, like this:

apiVersion: v1
kind: Pod
metadata:
  name: volume-test
spec:
  containers:
  - name: container-test
    image: busybox
    command: |
      - "/bin/bash"
      - "-exc"
        cp /etc/secrets-mount/*_pgpass /etc/secrets
        chown my-user /etc/*_pgpass
        chmod 600 /etc/*_pgpass
        exec su-exec my-user /entrypoint.sh
    volumeMounts:
    - name: secrets
      mountPath: /etc/secrets-mount/

....
-- Alexey Novgorodov
Source: StackOverflow
9/12/2019

As Alexey said, it is not possible at this time, until github.com/kubernetes/kubernetes/issues/81089 is done.

His solution is working perfectly, unless you have securityContraint.runAsNonRoot set, in which case the container wont have rights on the secret.

In my case, I had to do the following :

apiVersion: apps/v1
kind: Deployment
spec:
  template:
    spec:
      ##########################################
      #         Volumes definitions
      volumes:
      - name: key-volume
        emptyDir:
          sizeLimit: "8k"
      - name: root-owned-key-volume
        secret:
          secretName: my-secret
          items:
            - key: a_key_file
              path: a_key_file
              mode: 0600
      ##########################################
      #         initContainers definitions
      initContainers:
        - name: set-key-ownership
          image: alpine:3.6
          command: ["sh", "-c", "cp /root-key/* /key && chown -R 33:33 /key"]
          volumeMounts:
          - mountPath: /key
            name: key-volume
          - mountPath: /root-key
            name: root-owned-key-volume
      ##########################################
      #         Containers definitions
      containers:
      - name: my-main-container
        (...)
        securityContext:
          runAsNonRoot: true
          runAsUser: 33
        (...)
        volumeMounts:
        - mountPath: /key
          name: key-volume

Basically, knowing that it is impossible to change the ownership of the secret file, an initContainer will copy it to another temporary folder and change ownership of this new file.

Gross, but at least, it's working.

-- Orabîg
Source: StackOverflow