Блог

Я пытаюсь запустить конфигурацию развертывания на OpenShift. Часть моей конфигурации развертывания запускает контейнер init, который устанавливает разрешения на постоянный том с помощью 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 для монтирования nfs, в котором находится мой постоянный том.

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

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

Проблема в том, что пользователь, от имени которого запущен ваш init-контейнер, не имеет разрешений на запись в этот каталог /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 в мастер-файле config.YML на мастер-узлов в конфигурации проекта раздел и безопасности распределителя конфигурации сечения.

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