СГТМ. @kubernetes/kubectl есть мысли по этому поводу?

Это небезосновательно, но нам понадобится политика безопасности модуля для контроля пользовательского ввода, и нам, вероятно, придется запретить пользователя по имени (поскольку мы не разрешаем это для контейнеров — вы должны указать UID).

@sttts и @ncdc re exec

Законный вариант использования

Есть новости по этому поводу?

Мой образ контейнера приложения создается с использованием пакетов сборки. Я хотел бы открыть оболочку. Когда я это делаю, я являюсь пользователем root, и все переменные окружения установлены. Но среды, сгенерированной buildpack, там нет. Если я открою оболочку входа в систему для пользователя приложения ( su -l u22055 ), у меня будет среда моего приложения, но теперь переменные env kubernetes отсутствуют.

Я думал, что su -l не копирует env vars? Вы должны явно сделать копию
самостоятельно или используйте другую команду.

Во вторник, 11 октября 2016 г., в 17:26, Майкл Эльсдорфер < [email protected]

написал:

Мой образ контейнера приложения создается с использованием пакетов сборки. я хотел бы открыть
оболочка. Когда я это делаю, я являюсь пользователем root, и все переменные окружения установлены. Но
среды, созданной buildpack, там нет. Если я открою оболочку входа для
пользователь приложения (su -l u22055) У меня есть среда приложения, но теперь
kubernetes env vars отсутствуют.

—
Вы получаете это, потому что вы находитесь в команде, которая была упомянута.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/kubernetes/kubernetes/issues/30656#issuecomment -253085398,
или заглушить тему
https://github.com/notifications/unsubscribe-auth/ABG_p7sIu20xnja2HsbPUUgD1m4gXqVAks5qzCksgaJpZM4Jk3n0
.

@miracle2k - Вы пробовали su -m -l u22055 ? Предполагается, что -m сохраняет переменные среды.

@adarshaj @smarterclayton Спасибо за советы. У su -m есть свои проблемы (неправильный домашний каталог), но тем временем я заставил его работать. Однако дело в том, что я разместил это здесь, потому что я хотел бы, чтобы "kubectl exec" делал правильные вещи. Возможно, даже использовать пользователя, которого определяет файл докера.

Вот пример того, как мне нужна эта функциональность.

Официальный образ Дженкинса запускается от имени пользователя Jenkins. У меня подключен постоянный диск, размер которого нужно изменить. Если бы у kubectl был параметр --user, я мог бы войти в систему как root и изменить размер2fs. К сожалению, без него это невыносимая боль.

Дополнительный вариант использования — вы заботитесь о безопасности, поэтому все процессы, работающие внутри контейнера, не являются привилегированными. Но теперь что-то неожиданно не работает, и вы хотите войти в систему как пользователь root, чтобы, например, установить утилиты отладки и выяснить, что не так в работающей системе.

Установка вещей для целей отладки также является моим вариантом использования. В настоящее время я ssh подключаюсь к узлам, на которых работает kubernetes, и напрямую использую docker exec .

Каков статус по этому поводу? Этот функционал был бы очень полезен

Я не проверял, но помогают ли здесь глобальные флаги --as и --as-group ? Они вообще работают с exec ? копия @liggitt

Я не проверял, но помогают ли здесь глобальные флаги --as и --as-group? Они вообще работают с exec? копия @liggitt

Нет, это связано с идентификацией себя в API kubernetes, а не с передачей информации о выбранном uid для вызова exec.

Отсутствие пользовательского флага вызывает затруднения. Пример использования: у меня есть контейнер, который работает как непривилегированный пользователь, я монтирую на нем том, но папка тома не принадлежит пользователю. Нет возможности смонтировать том с указанными разрешениями. Я не могу использовать сценарий точки входа для изменения разрешений, потому что он работает как непривилегированный пользователь. Я не могу использовать хук lifecycle.preStart, потому что он тоже работает как непривилегированный пользователь. kubectl exec -u root мог бы сделать это, если бы существовала опция '-u'.

Я предполагаю, что это должно быть дополнительное разрешение RBAC, чтобы разрешить/заблокировать «exec» от лица, отличного от пользователя контейнера.

В идеале хуки жизненного цикла должны иметь возможность запускаться в контейнере от имени пользователя root, даже если контейнер этого не делает. На данный момент лучшей альтернативой, вероятно, является запуск контейнера инициализации для того же монтирования; своего рода накладные расходы для запуска отдельного контейнера и монтирования томов, когда на самом деле мне просто нужна однострочная команда от имени пользователя root при запуске контейнера.

/ сиг кли

+1 за эту функцию. Отсутствие этого делает отладку намного более болезненной.

+1 за эту функцию. Мне нужно перестроить контейнер Docker и убедиться, что в файле Docker в качестве последней строки указан корень USER, затем выполнить отладку, а затем отключить это.

Командная строка docker, похоже, имеет флаг --user

johnjjung, если у вас есть ssh-доступ к узлу, вы можете подключиться к контейнеру с помощью докера с пользовательским флагом, что может сэкономить вам немного времени.

Хм, круто, позвольте мне попробовать это

10 июля 2017 г., 11:34 -04:00, [email protected] написал:

johnjjung, если у вас есть ssh-доступ к узлу, вы можете подключиться к контейнеру с помощью докера с пользовательским флагом, что может сэкономить вам немного времени.
—
Вы получаете это, потому что вы прокомментировали.
Ответьте на это письмо напрямую, просмотрите его на GitHub или отключите ветку.

+1 действительно проблема, мне нужно ssh, а затем запустить docker exec, это так раздражает

/cc @frobware

+1 пожалуйста. Больше не хочу использовать docker exec -u в качестве обходного пути.

+1 - kubectl exec настолько значительно экономит время по сравнению с docker exec, что заставляет меня плакать каждый раз, когда мне приходится возвращаться к docker exec, чтобы указать пользователя.

соображения:

• uid должен быть частью интерфейса exec для CRI, и все среды выполнения должны поддерживать его.
• нужно будет выяснить, что будет проверка авторизации в соответствии с ограничениями политики безопасности pod для uid

+1, так как это предотвратит небезопасные обходные пути, к которым мы, к сожалению, привыкли (например, установка runAsUser на root ... и забывание вернуть значение при развертывании public 😮).

+1

+1 для меня действительно нужен флаг --user для входа в модуль и внесения изменений без повторного развертывания контейнера с root-пользователем

Эта проблема, кажется, имеет довольно сильную поддержку, можно ли что-нибудь сделать, чтобы сделать ее приоритетной? (да-да, патчи принимаются :) )

+1 было бы удобно иметь эту возможность выполнять с определенным пользователем

Я думаю, что реализация этого может быть сложной из-за проблем с безопасностью? Например, если Dockerfile изначально был настроен как пользователь без полномочий root, следует ли теперь разрешить ему выполнять команды от имени пользователя root? -- Как с этим справился пользовательский флаг докера? Если они справились с этим должным образом, я думаю, нам просто нужно исправить команду kubectl exec, чтобы передать это дальше.

Может ли кто-нибудь сказать мне, является ли это подходящей стратегией? Тогда я смогу приступить к пиару

@johnjjung Да, я считаю, что стратегия здесь заключается в исправлении kubectl exec для передачи флага docker --user.

Кроме того, проблемы с безопасностью кажутся незначительными, поскольку у нас есть неявная аутентификация от GCP для подключения из kubectl.

Кроме того, проблемы с безопасностью кажутся незначительными, поскольку у нас есть неявная аутентификация от GCP для подключения из kubectl.

Как же так? В спецификации модуля есть элементы управления тем, какой пользователь разрешен. Я бы ожидал эквивалентного контроля над любым идентификатором пользователя, указанным в вызове exec. У меня есть похожие вопросы о том, можно ли запустить exec от имени пользователя root, если исходный контейнер не был запущен. Если это так, то мы не можем раскрыть это, не подумав о том, как контекст безопасности модуля и элементы управления политикой безопасности модуля будут применяться к этой новой опции.

@liggitt Это ничем не отличается от настройки пользователя в самом файле Docker, но при этом все еще может выполняться от имени пользователя root с флагом пользователя Docker.

Основная задача Docker, по-видимому, заключается в предотвращении корневого доступа из _внутри_ работающего_ контейнера, если он будет скомпрометирован. В какой-то момент должно быть предоставлено доверие, чтобы пользователи действительно могли разрабатывать инструмент и работать с ним.

Например, если Dockerfile изначально был настроен как пользователь без полномочий root, следует ли теперь разрешить ему выполнять команды от имени пользователя root? -- Как с этим справился пользовательский флаг докера?

@johnjjung , как говорит @jordanwilson230 , аргумент среды выполнения докера переопределяет директиву Dockerfile. На мой взгляд, именно так работает большинство аргументов времени выполнения (например, номера портов).

У меня есть похожие вопросы о том, можно ли запустить exec от имени пользователя root, если исходный контейнер не был

@liggitt Просто чтобы уточнить, роль идентификатора пользователя, определенная в спецификации модуля, не изменится и будет продолжать иметь предполагаемый эффект. Контейнер (и его процессы) будет запущен от имени этого пользователя. Проблема, поднятая здесь, заключалась в том, чтобы разрешить (уже) аутентифицированным пользователям возможность запуска вручную с правами root или любого пользователя, в основном для целей отладки.

Проблема, поднятая здесь, заключалась в том, чтобы разрешить (уже) аутентифицированным пользователям возможность запуска вручную с правами root или любого пользователя, в основном для целей отладки.

И я хочу сказать, что элементы управления, которые у нас есть сегодня, чтобы предотвратить запуск пользователем контейнера с правами root, должны применяться и здесь, чтобы предотвратить их выполнение с правами root.

@liggitt Извините, я не совсем знаю, как объяснить более понятно. Что касается вашего комментария выше, попробуйте следующее:

• ssh на узел, на котором запущен ваш модуль (на моем модуле работает Kafka, а пользователь kafka также указан в pod.spec)
  jordan@gke-my-default-pool-dsioiaag-i9f3 ~ $ docker exec -it -u root myKafkaContainer bash root@kafka-0:/# echo "I've exec'd into my container as $(whoami) despite defining the kafka user in pod.spec...." I've exec'd into my container as root despite defining the kafka user in pod.spec.... root@kafka-0:/#
  Установив, что это уже возможно с точки зрения GKE (хотя и очень раздражающим образом), о каких новых проблемах безопасности вы думаете? Этот вопрос не в том, чтобы изобретать велосипед, а в том, чтобы обеспечить удобство.

Установив, что это уже возможно с точки зрения GKE (хотя и очень раздражающим образом), о каких новых проблемах безопасности вы думаете?

Проблема заключается в раскрытии мощности через API kubernetes, которого сегодня нет. Это нормально, когда пользователю разрешено запускать рабочие нагрузки через API, но ему не разрешен доступ к узлу по ssh.

Замечательно иметь функцию через API, если:

1. администраторы кластера имеют возможность контролировать с помощью политики, разрешено ли это
2. способ выражения политики согласуется с существующей политикой (в этом случае в идеале это должно быть сделано на основе того же механизма PodSecurityPolicy)
3. новая функция не открывает дыру в ранее защищенной системе (по умолчанию отключена или закрыта на основе существующей политики)

@liggitt Абсолютно верно. Итак, сузив область последствий для безопасности до доступа к _node_, мы ( @johnjjung и другие) можем, наконец, начать использовать это обсуждение для действенного содержания. Я запустил плагин kubectl для запуска от имени пользователя root на платформе GKE. Мне потребуется некоторое время, чтобы добраться до AWS и других. @johnjjung , ты все еще готов ответить на свой вопрос?

@liggitt Только что увидел сделанное вами редактирование, оно будет полезно в дальнейшем. Спасибо.

Связанное обсуждение см. в предложении разрешить запуск произвольных контейнеров, включая отдельно указанные идентификаторы пользователей, в существующем модуле — https://github.com/kubernetes/community/pull/1269 .

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

@ jordanwilson230 Просматривая кодовую базу, я нашел точки интеграции для команд kubectl exec, что является хорошей отправной точкой, я не уверен, где мне придется вносить изменения в другую кодовую базу kubernetes, где мы можем разрешить докеру - ты флаги. При этом я думаю, что могу начать с чего-то там и вернуться к этой проблеме с администраторами кластера / политиками безопасности pod и т. д. ... Шаг за шагом.

Если кто-нибудь знает, где внести изменения в то, где kubernetes запускает флаги docker --user , это было бы полезно.

Привет @johnjjung. Когда-то (<1.6) Kubernetes kubelets использовал Docker напрямую и мог просто передавать такие параметры. Теперь есть стандартный интерфейс для поддержки нескольких сред выполнения CRI. Именно возможности CRI определяют, какие инструкции могут быть переданы средам выполнения, таким как Docker.

Kubernetes сообщает различным средам выполнения контейнеров ( dockershim +Docker+ containerd , cri-containerd + containerd , rkt, cri-o, lxd, Frakti и т. д.), что нужно сделать с помощью интерфейса CRI . Либо напрямую для реализаций среды выполнения cri-o , либо через прокладку, например dockershim или cri-containerd . Итак, чтобы иметь возможность делать то, что мы хотим здесь (добавлять процессы в существующие контейнеры, работающие от имени пользователя, отличного от того, от имени которого был запущен контейнер), вам сначала нужно расширить спецификацию CRI для поддержки этой опции (например, возможно, ExecSync нужен параметр uid, а LinuxContainerSecurityContext не должен его запрещать. Я думаю, что @liggitt сказал об этом выше ).

Затем каждая из сред выполнения контейнера или оболочки среды выполнения может реализовать свою поддержку. Для Docker это означает расширение реализации dockershim для поддержки добавления к спецификации/интерфейсу CRI. Однако я ожидаю, что dockershim +Docker будет устаревшим в пользу cri-containerd + containerd в течение еще нескольких выпусков, поэтому нам, вероятно, лучше сосредоточиться на cri-containerd .

http://blog.kubernetes.io/2017/11/containerd-container-runtime-options-kubernetes.html

https://github.com/kubernetes/community/blob/master/contributors/devel/container-runtime-interface.md

Также имеет отношение к этому обсуждению как предложение контейнеров отладки . Предполагается, что вы сможете запустить второй образ контейнера в том же пространстве пода , используя новую команду kubectl debug . Возможно, дополнительный контейнер можно запустить от имени другого пользователя?

@whereisaaron ваш пост очень помогает. Спасибо, что все подробно расписали.

@whereisaaron спасибо за подробности. Если я вас понимаю, кажется, что предложение по отладке (если оно будет принято) может быть лучшим местом, чтобы поместить это в конце дня. Не уверен, что он был одобрен для работы, но в основном он позволяет вам прикрепить контейнер по вашему выбору к этому модулю для отладки этого модуля (что звучит потрясающе), но позволяет ли это вам изменить своего пользователя в исходном контейнере? Кроме того, означает ли это, что мне следует подождать или установить патч с помощью cri-containerd?

Похоже, что одна из причин, по которой это еще не было реализовано, заключалась в том, что существует несколько репозиториев с несколькими группами, работающими над разными областями.

@johnjjung Я полагаю, что контейнер отладки был одобрен для реализации в качестве «альфа-функции» в Kubernetes 1.9 (отключен, если вы явно не включите эту функцию). Я не думаю, что они сделали это в 1.9, хотя. Так что, вероятно, не раньше 1.10 или позже.

Насколько я понимаю, отладочные контейнеры запускаются как процесс внутри «отлаживаемого» целевого пода, поэтому они находятся в том же контексте безопасности ядра, что и под, у них просто есть собственный образ/файловая система контейнера. Таким образом, вы можете отлаживать любые процессы и монтировать любые тома, которые есть в поде. Но поскольку вы находитесь в том же контексте безопасности, интересно, застряли ли вы с одним и тем же наложенным ядром ограничением на uid, который вы можете использовать в поде, или нет? Я не уверен, вам нужно спросить людей #sig-node, работающих над этим.

Что касается расширения CRI, я думаю, вам потребуется большая поддержка со стороны #sig-node для этого, а также отсутствие возражений со стороны различных проектов среды выполнения, таких как cri-containerd и cri-o , которые могут затем должны реализовать поддержку.

Сегодня у меня было мало времени, но для тех, кто работает на GKE, я сделал специальный плагин kubectl для выполнения с пользовательским флагом [-u]:

https://github.com/jordanwilson230/kubectl-плагины

Не стесняйтесь изменять/копировать этот плагин или все сразу, запустив скрипт установки. Просто специальное решение, пока @johnjjung и другие не смогут взять на себя больше.

Иметь альтернативное решение, не относящееся к GCP. Это вообще не использует SSH и требует только работы kubectl.

https://github.com/mikelorant/kubectl-exec-пользователь

Проверяет ли модуль kubectl-exec-user, что человек, использующий его, имеет доступ к контейнеру, в который запрашивается оболочка?

Он возвращается к тому, какой доступ разрешает API kubernetes. Это будет работать только в том случае, если RBAC позволяет контейнеру монтировать док-сокет узлов.

Считайте мое решение творческим способом выхода из контейнера на узел без использования SSH. Необходимо учитывать все те же условия безопасности, но, по крайней мере, они соблюдают ограничения сервера API kubernetes.

Проблемы устаревают после 90 дней бездействия.
Отметьте проблему как свежую с помощью /remove-lifecycle stale .
Устаревшие проблемы гниют после дополнительных 30 дней бездействия и в конечном итоге закрываются.

Если эту проблему можно безопасно закрыть сейчас, сделайте это с помощью /close .

Отправьте отзыв в sig-testing, kubernetes/test-infra и/или fejta .
/жизненный цикл устарел

/remove-жизненный цикл устарел

Это было бы очень кстати. Нехорошо быть наказанным за то, что заботишься о безопасности и запускаешь все процессы без полномочий root. (Перефразируя https://github.com/kubernetes/kubernetes/issues/30656#issuecomment-272055993)

/ знаковый узел

Кажется, для этой функции существует незаконченный PR, требующий перебазирования: https://github.com/kubernetes/kubernetes/pull/59092. Есть кто смог поднять и доработать? CC @louyihua

+1
(Я столкнулся с той же проблемой, что и @SimenB - я хотел бы установить материал для целей отладки. Кстати, спасибо за подсказку «использовать докер напрямую»)

Пока мы ожидаем, что это будет должным образом поддерживаться, промежуточным решением может быть запуск вашего docker CMD с su-exec (либо в Dockerfile, либо в манифесте K8s). su-exec весит всего 20 КБ (на alpine), и таким образом ваше приложение будет работать непривилегированным, но при этом иметь root-права в kubectl exec.

+1

Я также был бы признателен за такой флаг -u. +1.

Просто идея:

Например, что-то вроде --conainer-type было бы большим плюсом, чтобы разрешить передачу любых поддерживаемых аргументов непосредственно в реализацию контейнера нижнего уровня:

kubectl exec --container-type=docker -it -u 0 NAME

Это позволит избежать наличия в kubectl только подмножества базовой функциональности среды выполнения контейнера. Кроме того, это экономит усилия, поскольку нет необходимости сопоставлять и абстрагировать поддерживаемые аргументы от слоя kubelet вплоть до контейнера для каждого поддерживаемого типа контейнера.

Таким образом, без флага --container-type можно использовать только абстрактные аргументы из kubectl, а базовый тип контейнера полностью прозрачен. С помощью флага можно передавать конкретные аргументы контейнера. Пользователь kubectl решает, хочет ли он привязываться к типу контейнера или нет.

Кстати: спасибо @SimenB за подсказку подключиться к узлу по ssh и напрямую использовать Docker. Это временно решило мою проблему. Используя Minikube, я смог сделать следующее, чтобы войти в систему как root:
minikube ssh "docker exec -it -u 0 <container-id> bash"
Может быть, это может помочь кому-то.

Обходной сценарий, который автоматизирует неприятное. Требуется SSH-доступ к узлу.

Применение:

```./shell-into-pod-as-root.sh[оболочка]
./shell-into-pod-as-root.sh подимя
./shell-into-pod-as-root.sh подимя sh

Enjoy!

!/usr/bin/env bash

установить -xe

POD=$(kubectl описывает pod "$1")
NODE=$(echo "$POD" | grep -m1 Node | awk -F'/' '{print $2}')
CONTAINER=$(echo "$POD" | grep -m1 'ID контейнера' | awk -F 'docker://' '{print $2}')

CONTAINER_SHELL=${2:-баш}

установить +е

ssh -t "$NODE" sudo docker exec --user 0 -it "$CONTAINER" "$CONTAINER_SHELL"

если [ "$?" -gt 0]; тогда
установить +х
echo 'SSH в pod не удалось. Если вы видите сообщение об ошибке, похожее на «исполняемый файл не найден в $PATH», попробуйте:
эхо "$0 $1 ш"
фи
```

@Nowaker , как вы справляетесь с пространствами имен?

Проблемы устаревают после 90 дней бездействия.
Отметьте проблему как свежую с помощью /remove-lifecycle stale .
Устаревшие проблемы гниют после дополнительных 30 дней бездействия и в конечном итоге закрываются.

Если эту проблему можно безопасно закрыть сейчас, сделайте это с помощью /close .

Отправьте отзыв в sig-testing, kubernetes/test-infra и/или fejta .
/жизненный цикл устарел

/remove-жизненный цикл устарел

Я также был бы признателен за такой флаг -u. +1.

Просто идея:

Например, что-то вроде --conainer-type было бы большим плюсом, чтобы разрешить передачу любых поддерживаемых аргументов непосредственно в реализацию контейнера нижнего уровня:

kubectl exec --container-type=docker -it -u 0 NAME

Это позволит избежать наличия в kubectl только подмножества базовой функциональности среды выполнения контейнера. Кроме того, это экономит усилия, поскольку нет необходимости сопоставлять и абстрагировать поддерживаемые аргументы от слоя kubelet вплоть до контейнера для каждого поддерживаемого типа контейнера.

Таким образом, без флага --container-type можно использовать только абстрактные аргументы из kubectl, а базовый тип контейнера полностью прозрачен. С помощью флага можно передавать конкретные аргументы контейнера. Пользователь kubectl решает, хочет ли он привязываться к типу контейнера или нет.

Кстати: спасибо @SimenB за подсказку подключиться к узлу по ssh и напрямую использовать Docker. Это временно решило мою проблему. Используя Minikube, я смог сделать следующее, чтобы войти в систему как root:
minikube ssh "docker exec -it -u 0 <container-id> bash"
Может быть, это может помочь кому-то.

Да, просто использовать docker exec для этого тривиально - в основном это касается согласованности - многопользовательские контейнеры докеров на самом деле немного шутка - наследие преобразования виртуальной машины в контейнер.

Я сейчас занимаюсь этим с графаной - думаю, со временем это пройдет.

@bryanhuntesl Выше обсуждались обходные пути, которые не требуют ручного подключения по ssh к узлу. Вы также можете попробовать этот плагин — https://github.com/jordanwilson230/kubectl-plugins.

Что делать, если вы не хотите разрешать пользователям подключаться к узлу по ssh? Предоставление пользователям ssh-доступа к узлу, а также предоставление им доступа к докеру может быть угрозой безопасности. Docker ничего не знает о пространствах имен или разрешениях k8s. Если пользователь может запустить docker exec , он может выполняться в модулях _любого_ пространства имен.

SSH не является правильным решением, ИМХО.

Что делать, если вы не хотите разрешать пользователям подключаться к узлу по ssh? Предоставление пользователям ssh-доступа к узлу, а также предоставление им доступа к докеру может быть угрозой безопасности. Docker ничего не знает о пространствах имен или разрешениях k8s. Если пользователь может запустить docker exec , он может выполняться в модулях _любого_ пространства имен.

SSH не является правильным решением, ИМХО.

Я согласен с этим мнением - использование внешнего механизма для получения прямого доступа увеличивает потенциальную область атаки.

Что делать, если вы не хотите разрешать пользователям подключаться к узлу по ssh? Предоставление пользователям ssh-доступа к узлу, а также предоставление им доступа к докеру может быть угрозой безопасности. Docker ничего не знает о пространствах имен или разрешениях k8s. Если пользователь может запустить docker exec , он может выполняться в модулях _любого_ пространства имен.

SSH не является правильным решением, ИМХО.

Есть решения, которые не требуют SSH @gjcarneiro. Кроме того, пользователь должен сначала добавить свой открытый SSH-ключ в вычислительные метаданные, прежде чем ему будет разрешен SSH-доступ к узлу (если на GCP) @bryanhuntesl.

@liggitt Прошло три года с тех пор, как эта тема началась, какие-то выводы?

Я не уверен, упоминалось ли это решение ранее, но в качестве обходного пути мы сделали, чтобы все наши контейнеры включали скрипт, который будет регистрировать вас как правильного пользователя. Плюс мод:

Докерфайл:

USER root
RUN echo "su -s /bin/bash www-data" >> /root/.bashrc
# this exit statement here is needed in order to exit from the new shell directly or else you need to type exit twice
RUN echo "exit" >> /root/.bashrc
# /var/www is www-data's home directory
COPY motd.sh /var/www/.bashrc

мотд.ш:

RED='\033[0;31m'
YELLOW='\033[0;33m'

echo -e "${RED}"
echo "##################################################################"
echo "#        You've been automatically logged in as www-data.        #"
echo "##################################################################"
echo -e "${YELLOW} "
echo "If you want to login as root instead:"
echo -e "$(if [ "$KUBERNETES_PORT" ]; then echo 'kubectl'; else echo 'docker'; fi) exec -ti $(hostname) -- bash --noprofile -norc"

TEXT_RESET='\033[0m'

echo -e "${TEXT_RESET} "

Проблемы устаревают после 90 дней бездействия.
Отметьте проблему как свежую с помощью /remove-lifecycle stale .
Устаревшие проблемы гниют после дополнительных 30 дней бездействия и в конечном итоге закрываются.

Если эту проблему можно безопасно закрыть сейчас, сделайте это с помощью /close .

Отправьте отзыв в sig-testing, kubernetes/test-infra и/или fejta .
/жизненный цикл устарел

/remove-жизненный цикл устарел

используйте плагин [exec-as] kubectl:

kubectl krew install exec-as

Как упоминалось выше, для этого действительно нужен KEP и обсуждение последствий для безопасности. Это не обязательно плохая идея, просто она оказывает значительное влияние на систему и нуждается в дизайне, прежде чем мы сможем начать кодирование.

Я был бы рад помочь просмотреть и подготовить KEP для этого, но у него определенно есть некоторые проблемы, и это может занять некоторое время.

@miracle2k - Вы пробовали su -m -l u22055 ? Предполагается, что -m сохраняет переменные среды.

@miracle2k Я попробовал это (trying to exec as root user) , но получил No passwd entry for user '0'

$ su -m -l 0
No passwd entry for user '0'

Привет. Чтобы решить эту проблему, я разработал интерфейс командной строки kpexec.
Пожалуйста, дайте свои отзывы.

• https://github.com/ssup2/kpexec

На узле, на котором запущен модуль:

docker exec -u 0 -it \
    `kubectl -n NAMESPACE get pod \
          -l label=value \
          -o jsonpath='{range .items[*].status.containerStatuses[*]}{.containerID}{"\n"}{end}' | cut -d/ -f3` \
sh

@cristichiru Для большинства кластеров, в которых я работал, нет прямого доступа оболочки к базовому узлу. Я подозреваю, что это часто имеет место и для других.

В этих случаях кажется, что другие представленные здесь варианты, такие как плагины kubectl, могут быть единственным способом — при условии, что нет доступа к демону докера.

+1

Ну, шаблон KEP здесь https://github.com/kubernetes/enhancements/tree/master/keps/NNNN-kep-template .

Я подумал, что посмотрю, сколько работы нужно написать, и ... да, я не тот человек, который может это написать, шаблон потерял меня в пункте один контрольного списка **Pick a hosting SIG.** кто-нибудь, кто больше знаком с процессом, начать черновик? Мне просто нужно место, где я могу поставить свой 👍 в поддержку предложения как активный пользователь Kubernetes.

Это может звучать легкомысленно, но я вижу около полудюжины хорошо закодированных / скриптовых / написанных обходных путей для этой проблемы, поэтому очевидно, что есть люди, которые лучше меня могут разработать предлагаемые технические решения.

Я чувствую, что Kubernetes стал новым OpenStack, где ничего нельзя достичь в разумные сроки из-за ПРОЦЕССА .

Первоначальный вариант использования @VikParuchuri здесь заключается в том, чтобы иметь возможность отлаживать / устранять неполадки контейнеров от имени пользователя root, даже если сам контейнер работает как ненадежный пользователь. Хороший вариант использования, потому что, если он будет решен, он побуждает всех нас запускать контейнеры как пользователи без полномочий root. 🎉

Перед подготовкой KEP для docker exec быстро проверьте, не подходят ли для вас временные отладочные контейнеры k8s .

docker exec --user — это только один из способов решения этого варианта использования, и он зависит от используемой среды выполнения Docker. Поскольку k8s переходит на containerd , dockerd и друзья являются необязательными или даже больше не устанавливаются, так что, возможно, это не перспективный вариант?

Еще один родной для k8s способ решения этого варианта использования — эфемерные контейнеры отладки. Скажем, у вас есть контейнер, работающий от имени ненадежного пользователя. Контейнеры отладки позволяют вам запускать временный контейнер в том же пространстве процессов , что и целевой контейнер, но работающий от имени пользователя root (или кого-либо другого). Этот подход имеет некоторые существенные преимущества по сравнению с подходами exec, в частности, вы можете использовать любые инструменты и утилиты отладки, которые вам нужны, в образе контейнера отладки. Таким образом, вместо того, чтобы раздувать образ целевого контейнера с помощью утилит, редакторов и т. д., на всякий случай, если вам нужно выполнить (🐑 .., виноват!), вы можете вместо этого иметь хороший большой образ контейнера отладки швейцарского армейского ножа и содержать образы приложений в чистоте. . Вы можете использовать bash в своем контейнере отладки, когда ваша цель имеет только sh . Вы даже можете отлаживать контейнеры, которые вообще не имеют оболочки для выполнения, например, одиночные двоичные контейнеры или контейнеры без дистрибутива .

Например, используйте busybox для отладки контейнера с правами root.

kubectl alpha debug -it ephemeral-demo --image=busybox --target=ephemeral-demo

Я думаю, что это, возможно, лучшая модель, поскольку она рассматривает контейнеры как изолированные процессы, к которым вы «присоединяетесь» для отладки, а не как мини-VM, в которые вы встраиваете. Недостатком является то, что я не думаю, что вы можете проверить файловую систему цели, если только вы не можете поделиться внешним монтированием или «пустым» монтированием. Вы разделяете пространство имен процесса с вашей целью, поэтому вы также можете получить доступ к файловой системе целевого контейнера через /proc/$pid/root .

Эфемерные отладочные контейнеры уже прошли ПРОЦЕСС :-) и были реализованы. Эти контейнеры являются альфа-версиями, поскольку версии ~1.16 и 1.18 kubectl включают команду alpha debug . Подробнее здесь:

Ссылки:

• https://medium.com/01001101/ephemeral-containers-the-future-of-kubernetes-workload-debugging-c5b7ded3019f
• https://kubernetes.io/docs/tasks/debug-application-cluster/debug-running-pod/#ephemeral-контейнер
• https://kubernetes.io/docs/concepts/workloads/pods/ephemeral-containers/
• https://www.shogan.co.uk/kubernetes/enbling-and-using-ephemeral-containers-on-kubernetes-1-16/

Спасибо за вдумчивый ответ @whereisaaron :) Я думаю, что это хорошо отражает ситуацию.

Я подумал, что посмотрю, сколько работы потребуется, чтобы написать его, и... да, я не тот человек, который будет писать это. Шаблон потерял меня в пункте один контрольного списка . Выберите SIG хостинга. Кто-нибудь более знаком с процессом, хочет начать черновик? Мне просто нужно место, где я могу поставить свой 👍 в поддержку предложения как активный пользователь Kubernetes.

KEP могут быть довольно пугающими, но я хочу предоставить небольшой контекст вокруг них. Сам Kubernetes очень большой; потенциальные изменения имеют очень большой радиус поражения, как для базы авторов, так и для пользователей. Новая функция может показаться простой в реализации, но она может оказать широкое влияние на обе группы.

Мы делегируем управление частями кодовой базы группам SIG; и именно через KEP одна или несколько SIG могут прийти к консенсусу по функции. В зависимости от того, что делает функция, она может пройти проверку API, оценку масштабируемости и т. д.

Все это делается для того, чтобы то, что производится, имело наибольшие шансы на успех и развивалось таким образом, чтобы SIG были готовы его поддерживать. Если первоначальный автор(ы) уходят, ответственность за его поддержку ложится на SIG. Если, скажем, функция была переведена в стабильную версию, а затем помечена как устаревшая, пройдет как минимум год, прежде чем ее можно будет удалить в соответствии с политикой устаревания .

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

В любом случае, я надеюсь, что это проливает хоть немного света на то, почему существует процесс, связанный с объединением функций. :+1: Если у вас есть какие-либо вопросы, обращайтесь напрямую.

Недостатком является то, что я не думаю, что вы можете проверить файловую систему цели, если только вы не можете поделиться внешним монтированием или «пустым» монтированием.

Для меня проверка файловой системы с правами root и запуск утилит, которые могут взаимодействовать с файловой системой с правами root, является причиной номер один для получения поддержки запрошенной функции. Короче говоря, это предложение не решает моей проблемы вообще.

Недостаток в том, что я не думаю, что вы можете проверить файловую систему цели.

Я ошибался в этом, поскольку ваш внедренный контейнер отладки разделяет пространство имен процесса с вашим целевым контейнером, вы можете получить доступ к файловой системе любого процесса в целевом контейнере из вашего контейнера отладки. И это будет включать как файловые системы контейнеров, так и любые файловые системы, смонтированные в этих контейнерах.

Файловые системы контейнеров видны другим контейнерам в поде по ссылке /proc/$pid/root.

https://kubernetes.io/docs/tasks/configure-pod-container/share-process-namespace/#understanding -process-namespace-sharing

Проблемы устаревают после 90 дней бездействия.
Отметьте проблему как свежую с помощью /remove-lifecycle stale .
Устаревшие проблемы гниют после дополнительных 30 дней бездействия и в конечном итоге закрываются.

Если эту проблему можно безопасно закрыть сейчас, сделайте это с помощью /close .

Отправьте отзыв в sig-testing, kubernetes/test-infra и/или fejta .
/жизненный цикл устарел

/remove-жизненный цикл устарел

kubectl alpha debug -it ephemeral-demo --image=busybox --target=ephemeral-demo

error: ephemeral containers are disabled for this cluster

@whereisaaron Похоже, что большинство облачных провайдеров не поддерживают это, и для прем мы можем просто перейти к узлу и docker exec в контейнер. Итак, опять же, полезность кажется довольно ограниченной.

Также доступ через /proc/$pid/root не то, что хотелось бы, хотелось бы прямой доступ не через "боковое окно". Например, запускать такие утилиты, как apt/apk _в контейнере_, непросто, когда корневая файловая система находится не там, где они ожидают.

У меня была аналогичная проблема: мне нужно было создать несколько каталогов, ссылок и добавить разрешение для пользователя без полномочий root на официальном образе, развернутом официальной диаграммой helm (jenkins).

Я смог решить эту проблему с помощью плагина exec-as.

С запланированным устареванием Docker и последующим удалением, когда это будет решено? Эфемерные контейнеры все еще находятся в стадии альфа-тестирования. Какова стабильная альтернатива без использования Docker в качестве CRI?

Помимо того, что это альфа-версия, эфемерные контейнеры намного сложнее в использовании, чем просто kubectl exec --user .

Другой вариант использования для этого — ручное выполнение скриптов в контейнерах. Например, сценарий обслуживания NextCloud occ должен запускаться как www-data. В образе нет sudo или подобного, и документ рекомендует использовать docker exec -u 33 в среде Docker.

Вы можете решить проблему с nextcloud, запустив

su -s /bin/bash www-data

Но это не идеально.