Изменение владельца файла по умолчанию и владельца группы файлов секретов kubernetes, смонтированных на проектируемых томах

Question

Я новичок в K8S. У меня есть файл yaml, который генерирует секреты kubernetes, смонтированные на проецируемых томах. После выполнения я обнаружил, что секретные файлы (упакованные с секретами) показывают "root" как владельца файла и владельца группы. Я хочу изменить владельца файла и владельца группы на одного и того же конкретного пользователя (скажем, 450).

Я попытался использовать "chown" из контейнера init (пробовал, но не получилось), но я получил сообщение об ошибке "Файловая система только для чтения" и не смог изменить владельца файла и группы. Я не хочу использовать "fsGroup" под securitycontext. Я заметил, что опция "mode:" в "items" ведет себя непредсказуемым образом при использовании fsGroup.

Есть ли способ изменить владельца файла по умолчанию и владельца группы секретных файлов kubernetes, которые монтируются через проецируемые тома?

Я предоставляю пример кода ниже. Предположим, я хочу изменить владельца файла и группы файла "password" (в разделе "mysecret2") в следующем примере. как этого добиться?

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

Answer 1

Насколько я знаю, нет способа изменить UID владельца для секретов.

Обходной путь - скопировать секрет в обычный файл, а затем изменить его владельца и режим, например:

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/

....

Answer 2

Как сказал Алексей, в настоящее время это невозможно, пока не будет завершена работа с github.com/kubernetes/kubernetes/issues/81089.

Его решение работает отлично, если у вас нет securityContraint.runAsNonRoot set, и в этом случае контейнер не будет иметь прав на секрет.

В моем случае мне пришлось сделать следующее:

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

В основном, зная, что невозможно изменить владельца секретного файла, initContainer скопирует его в другую временную папку и изменит владельца этого нового файла.

Грубо, но, по крайней мере, работает.