Поддержка Kubernetes для переназначения пространства имен пользователей Docker

Docker поддерживает переназначение пространства имен пользователя, так что пространство имен пользователя полностью отделено от гостья.

Текущее поведение по умолчанию гарантирует, что контейнеры получат собственное управление пользователями и группами, то есть их собственную версию /etc/passwd и /etc/group, но процессы контейнера выполняются с одинаковыми идентификаторами UID в хост-системе. Это означает, что если ваш контейнер работает с UID 1 (root), он также будет работать на хосте с правами root. Точно так же, если в вашем контейнере есть пользователь john с установленным UID 1001 и он запускает свой основной процесс с этим пользователем, на хосте он также будет работать с UID 1001, который может принадлежать пользователю Will и также может иметь права администратора.

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

Есть ли в Kubernetes поддержка для включения этой функции в базовой среде выполнения контейнера? Будет ли работать из коробки без проблем?


kubernetes docker namespaces kubernetes-security
person Ijaz Ahmad Khan    schedule 27.10.2018    source источник
comment
В каком случае это может вам понадобиться? (В кластерах Kubernetes, которые я использовал, у меня никогда не было доступа к файловой системе хоста и не было доступа к uid хоста в любой форме.)   -  person David Maze    schedule 27.10.2018
comment
если нет пользовательских пространств имен, пользователь может запускать поды / контейнер как uid 0, root, который совпадает с root на хосте, и может открывать все возможности выполнения демага, без включения uer ns на движке докера, root в контейнере является root на хосте   -  person Ijaz Ahmad Khan    schedule 27.10.2018
comment
github.com/kubernetes/enhancements/issues/127   -  person johnharris85    schedule 27.10.2018
comment
похоже, работа в процессе github.com/kubernetes/enhancements/issues/127   -  person Shashank Pai    schedule 27.10.2018
comment
@ johnharris85, похоже, будет доступен в версиях 1.14 или 1.15 :)   -  person Ijaz Ahmad Khan    schedule 27.10.2018
comment
@ johnharris85 кстати, мы используем docker EE kubernetes, они что-то с этим делают   -  person Ijaz Ahmad Khan    schedule 27.10.2018

Ответы (1)


arrow_upward
7
arrow_downward

Таким образом, он еще не поддерживается, как Docker согласно this (как указано в комментариях) и это.

Однако, если вы хотите изолировать свои рабочие нагрузки, есть и другие альтернативы (это не то же самое, но варианты довольно хороши):

Вы можете использовать политики безопасности Pod и, в частности, можете использовать RunAsUser вместе с AllowPrivilegeEscalation = false. Политики безопасности модулей можно привязать к RBAC, чтобы вы могли ограничить использование пользователями своих модулей.

Другими словами, вы можете заставить своих пользователей запускать модули только как «youruser» и отключить флаг privileged в модуле _ 2_. Вы также можете отключить sudo и в образах контейнеров.

Кроме того, вы можете отказаться от возможностей Linux, особенно CAP_SETUID. А еще более продвинутые - используйте профиль seccomp, используйте SElinux или Профиль Apparmor.

Другие альтернативы запуску ненадежных рабочих нагрузок (на момент написания этой статьи в альфа-версии):

person Rico    schedule 28.10.2018
comment
Как администратор кластера, я хочу защитить узел от мошеннических контейнерных процессов, работающих внутри контейнеров pod с привилегиями root. Если такой процесс может проникнуть в узел, это может быть проблемой безопасности. Как администратор кластера, я хочу поддерживать все изображения независимо от того, какого пользователя / группы использует это изображение. Как администратор кластера, я хочу разрешить некоторым модулям отключать пространства имен пользователей, если им требуются повышенные привилегии. - person Ijaz Ahmad Khan; 28.10.2018
comment
Хорошо созданный профиль seccomp с другими (caps, selinux, apparmor) подойдет, но это сложно (очень сложно). Опубликованы другие альтернативы в альфа-версии, но они еще не готовы к продвижению. Docker EE сделает это с помощью docker swarm (не k8s). Если вы не хотите иметь с этим дело, подождите, пока созреют пространства имен пользователей в k8s или других альфа-проектах. Взносы приветствуются :-) - person Rico; 28.10.2018