В изменении разрешения на PV с помощью init-контейнера отказано - PullRequest
Новая
       7

В изменении разрешения на PV с помощью init-контейнера отказано

0 голосов
/ 29 марта 2019

Я пытаюсь запустить конфигурацию развертывания в OpenShift.Часть моей конфигурации развертывания запускает контейнер инициализации, который устанавливает разрешения для постоянного тома с помощью chown.При запуске init-контейнера происходит сбой, и в журналах выводится «разрешение запрещено»

Вот мой init-контейнер: 

  - apiVersion: v1
    kind: DeploymentConfig
    metadata:
        name: ${NAME}-primary
        namespace: ${NAMESPACE}

    spec:
        replicas: 1
        strategy:
            type: Recreate
        template:
            metadata:
                labels:
                    name: ${NAME}-primary
                    test-app: ${NAME}
            spec:
                serviceAccountName: ${SERVICE_ACCOUNT}

                initContainers:
                  - name: set-volume-ownership
                    image: alpine:3.6
                    command: ["sh", "-c", "chown -R 1030:1030 /var/opt"]
                    volumeMounts:
                      - name: test-app-data
                        mountPath: /var/opt

У меня также установлен chmod 777 на nfsmount, который имеет мой постоянный том.

Итак, я знаю, что OpenShift по умолчанию запускает модуль как случайный UID.Я знаю, что могу добавить служебную учетную запись из моей конфигурации развертывания в scc anyuid, и это будет работать, но я не хочу этого делать, так как это является проблемой безопасности, и мой администратор кластера не допустит этого.Как я могу обойти это?Я читал о fsGroups, но они не имели смысла для меня.Есть мнения?

1 Ответ

1 голос
/ 29 марта 2019

В документации OpenShift об этом немного говорится в разделе Поддержка произвольных идентификаторов пользователей .

Проблема заключается в том, что пользователь, которого запускает ваш контейнер инициализации, не имеет разрешения на запись для этого.directory /var/opt.

Если ваш initContainer запустит команду id, вы увидите, что ваши uid и gid должны быть 1000000000+: 0

Типичная стратегия, ожидаемая в этой ситуации:предоставить права на запись для корневой группы везде, где вам нужно будет писать во время выполнения.Это позволит вашему пользователю во время выполнения получить доступ к файлам, потому что, несмотря на то, что uid генерируется случайным образом, группа всегда равна 0.

К сожалению, многие образы общедоступных контейнеров имеют эту настройку конфигурации из коробки.

Примеры этого можно увидеть на базовых изображениях Red Hat.В каждый образ базового контейнера встроен скрипт, называемый fix-permissions , который запускается везде, где ожидается, что приложение / пользователь должны будут написать позже.

В приведенном выше примере следующеекод используется для настройки разрешений, чтобы в них могли писать произвольные пользователи с идентификатором 1000000000+: 0. 

find $SYMLINK_OPT "$1" ${CHECK_OWNER} \! -gid 0 -exec chgrp 0 {} +
find $SYMLINK_OPT "$1" ${CHECK_OWNER} \! -perm -g+rw -exec chmod g+rw {} +
find $SYMLINK_OPT "$1" ${CHECK_OWNER} -perm /u+x -a \! -perm /g+x -exec chmod g+x {} +
find $SYMLINK_OPT "$1" ${CHECK_OWNER} -type d \! -perm /g+x -exec chmod g+x {} +

Если вы хотите настроить эти значения на уровне кластера, конфигурация для UIDAllocatorRange устанавливается вmaster-config.yml на главных хостах в разделе Project Config и в разделе Конфигурация распределителя безопасности .

Вы также можете изменить поведение сгенерированных uidsчерез аннотацию openshift.io/sa.scc.uid-range.Документация, обсуждающая это, может быть найдена в разделе Понимание предварительно распределенных значений и ограничений контекста безопасности .

...