Kubernetes: Тома создаются в контейнере с правами суперпользователя и строгими разрешениями.

hostDir должен получить те же разрешения, что и существующая запись хоста, хотя я не уверен, что мы гарантируем, что хост напрямую существует, прежде чем использовать hostDir

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

Я подал https://github.com/docker/docker/issues/9360

Было бы разумно добавить параметр user и / или permissions к volumeMounts или emptyDir чтобы явно принудительно использовать его?

Я не думаю, что мы хотим этого в API в долгосрочной перспективе, поэтому я бы предпочел применить
скрытая эвристика, такая как "chown для ПОЛЬЗОВАТЕЛЯ первого контейнера, который монтирует
том "или даже" убедитесь, что все VolumeMounts для тома emptyDir
есть тот же пользователь USER, иначе ошибка ". Как вы думаете, справится ли такая эвристика?

В среду, 26 ноября 2014 г., в 9:07, Карлос Санчес [email protected]
написал:

Было бы разумно добавить параметр пользователя и / или разрешений в
volumeMounts или emptyDir, чтобы явно заставить его?

Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/2630#issuecomment -64678153
.

Мне приятно это слышать

Это хороший стартовый проект

Фон
Внутри контейнера докеров основной процесс по умолчанию запускается от имени пользователя root. И в настоящее время контейнеры докеров не могут запускаться без прав суперпользователя (как только докер поддерживает пространство имен пользователя, процесс внутри контейнера может запускаться от имени суперпользователя, а корневой пользователь контейнера фактически может быть сопоставлен с обычным, непривилегированным пользователем вне контейнер). Однако даже сегодня внутри контейнера докеров процесс может запускаться от имени непривилегированного пользователя: образ Docker может создавать новых пользователей, а затем заставлять докер запускать процесс точки входа от имени этого пользователя, а не root (если этот пользователь существует в образе контейнера).

Когда внешний том смонтирован, его разрешения устанавливаются на ROOT (UID 0), поэтому, если процесс внутри контейнера не запущен как root, у него не будет разрешения на доступ к смонтированному каталогу.

Предлагаемые обходные пути на стороне Куберента

1. При создании модуля, если для этого требуется том EmptyDir, перед запуском контейнеров извлеките USER из каждого образа контейнера (анализируйте JSON для каждого образа контейнера), если какой-либо из контейнеров запускает свой основной процесс как некорневой, создание модуля завершится ошибкой.
2. При создании модуля, если для него требуется том EmptyDir, перед созданием общего тома укажите его для ПОЛЬЗОВАТЕЛЯ первого контейнера, который монтирует том.
3. Проблемы с этим подходом:
   
   
   
   1. С Kubernetes модуль может содержать несколько контейнеров, совместно использующих том, но каждый контейнер потенциально может запускать свои процессы с разными пользователями внутри, то есть даже если владелец тома был изменен, если только владелец не был изменен на группу, о которой все контейнеры были осведомлены. (и все соответствующие пользователи были частью), проблема все равно существует.
      
      
      
      
      
      • Не такая уж большая проблема, потому что мы могли бы справиться с этим с помощью docker / docker # 9360
      
      
      
   
   
   2. Еще одним интересным аспектом проблемы является то, что запуск CHOWN на общем томе извне контейнеров может завершиться ошибкой, если на хост-машине нет того же пользователя, что и внутри контейнера (образы контейнеров могут создавать нового пользователя, о котором хост не знает, и запустить процесс входа от имени этого пользователя, но поскольку этот пользователь не существует на хосте, CHOWN для этого пользователя с хоста не удастся).
      
      Одним из способов решения этой проблемы является совместное использование файла etc / passwd между хостом и контейнером, но это очень ограничивает.
      
      Другой потенциальный обходной путь для хоста - это каким-то образом проникнуть внутрь контейнера во время инициализации (до монтирования общего тома), прочитать ПОЛЬЗОВАТЕЛЯ, с которого будет запускаться основной процесс, и использовать файл образа «/ etc / passwd» для сопоставления USER на UID и CHOWN общий том на хосте с этим UID (CHOWN на хосте будет терпеть неудачу только в том случае, если он не найдет пользователя _string_, потому что он использует / etc / passwd для поиска сопоставления, но всегда успешно с UID потому что он просто устанавливает значение uint напрямую без поиска).
   
   

Мне кажется, что оба подхода разрушают слой абстракции, заставляя Kubernetes проникать в контейнер, чтобы выяснить, от имени какого пользователя будет запускаться основной процесс, и что-то делает с этой информацией вне контейнера. Я считаю, что правильным подходом было бы, если бы сами контейнеры ИЗБЕГАЛИ любые «смонтированные тома» во время установки (после создания и настройки пользователя).

Мысли?

@thockin , поговорив с некоторыми людьми, я думаю, что подход @carlossg явного указания пользователя в API был бы самым чистым /etc/passwd контейнера, чтобы выяснить связанный UID ).

Предложение по доработке API:

• Расширьте API для томов EmptyDir , GitRepo и GCEPersistentDisk чтобы при необходимости указать целочисленный UID без знака.
  
  
  
  • Если указан UID, хост сменит владельца каталога на этот UID и установит разрешения на 750 (Пользователь: rwx , Группа: r-x , Мир: --- ) при создании каталога тома.
  
  
  • Если UID не указан, хост не изменит владельца, но установит разрешения на 757 (Пользователь: rwx , Группа: r-x , Мир: rxw ), т.е. доступен для записи всем, когда создается каталог тома.
  
  
  • Тома HostDir останутся нетронутыми, поскольку эти каталоги не создаются Kubernetes.
  
  
  • Требовать UID вместо строки имени пользователя, чтобы не было проблем, если пользователь действительно существует на хост-машине (проблема 2.ii выше).
  
  

Мысли?

CC: @ bgrant0607 , @ dchen1107 , @lavalamp

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

https://github.com/docker/docker/issues/9360

18 декабря 2014 г. в 15:13 Саад Али [email protected] написал:

@thockin https://github.com/thockin , поговорив с некоторыми людьми, я
подумайте о подходе @carlossg https://github.com/carlossg явно
указание пользователя в API было бы самым простым решением. Я не
то, что мы можем применить «скрытую эвристику», не нарушая
абстракции (например, обращение к контейнеру, чтобы выяснить, какое имя пользователя
использовать, а затем смонтировать файл контейнера / etc / passwd, чтобы выяснить
связанный UID).

Предложение по доработке API:

• Расширение API для томов EmptyDir, GitRepo и GCEPersistentDisk
  для необязательного указания целочисленного UID без знака.
  
  
  
  • Если указан UID, хост сменит владельца
    
    каталог для этого UID и установите разрешения на 750 (Пользователь: rwx,
    
    Group: rx, World: ---) при создании каталога тома.
  
  
  • Если UID не указан, хост не изменит владельца,
    
    но установите разрешения на 757 (Пользователь: rwx, Группа: rx, Мир: rxw),
    
    т.е. доступен для записи во всем мире, когда создается каталог тома.
  
  
  • Тома HostDir останутся нетронутыми, поскольку эти каталоги
    
    не созданы Kubernetes.
  
  
  • Требовать UID вместо строки имени пользователя, чтобы не было проблем
    
    если пользователь существует на хост-машине (проблема 2.ii выше).
  
  

Мысли?

CC: @ bgrant0607 https://github.com/bgrant0607 , @ dchen1107
https://github.com/dchen1107 , @lavalamp https://github.com/lavalamp

Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/2630#issuecomment -67573932
.

@ saad-ali Я думаю, что HostDir нельзя оставить нетронутым. Давайте рассмотрим это: Hadoop при перезапуске восстанавливает блоки из каталога, в котором хранятся данные. Если мы используем emptyDir, перезапущенный контейнер получит другой каталог, а предыдущие данные будут потеряны. А Hadoop требует, чтобы права и права собственности на каталог были установлены для пользователя, запускающего Hadoop (hdfs). Если HostDir не разрешено изменять разрешения для каждого пользователя, то подобные варианты использования не могут быть достигнуты. Пожалуйста, прокомментируйте.

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

В пн, 12 января 2015 г., в 23:56, Luqman [email protected] написал:

@ saad-ali https://github.com/saad-ali Я думаю, HostDir не должен быть
осталось нетронутым. Давайте рассмотрим это: Hadoop при перезапуске восстанавливает блоки
из каталога, в котором хранятся данные. Если мы используем emptyDir, контейнер
который перезапущен, получит другой каталог, а предыдущие данные будут
потерянный. А Hadoop требует, чтобы разрешения и владение каталогом были
устанавливается для пользователя, запускающего Hadoop (hdfs). Если HostDir не разрешено изменять
разрешений на пользователя, то подобные варианты использования не могут быть достигнуты.
Пожалуйста, прокомментируйте.

Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/2630#issuecomment -69707793
.

@thockin Restart может быть чем угодно. Это могло произойти после отказа контейнера или контейнера. Или контейнер может быть перезапущен после изменения некоторых конфигураций (Hadoop необходимо перезапустить после изменений в конфигурациях). Это ответ?

В этом документе упоминается, что когда модуль не привязан, emptyDir удаляется. В случае использования Hadoop данные могут быть важны и могут потребоваться, когда возвращается другой модуль Hadoop (или перезапускается контейнер). Таким образом, HostDir необходимо использовать для сохранения данных, даже если модуль не привязан. Но Hadoop требует, чтобы для пользователя были установлены разрешения для каталога данных. Надеюсь, это объясняет.

С docker / libcontainer / pull / 322 контейнеры докеров теперь позволяют указывать AdditionalGroups (GID дополнительных групп). Итак, обновленное предложение по обработке общих томов между разными контейнерами в модуле:

• При создании томов EmptyDir , GitRepo или GCEPersistentDisk для нового модуля Kubelet:
  
  
  
  1. Создайте новую группу linux для модуля на хост-машине
     
     
     
     
     
     • Группа создается со следующим доступным идентификатором группы (GID)
     
     
     
  
  
  2. Измените группу нового каталога (на главном компьютере) на вновь созданную группу.
  
  
  3. Установите разрешения для нового каталога (на хост-машине) на 770 (Пользователь: rwx , Группа: rwx , Мир: --- ).
  
  
  4. Для каждого контейнера докеров передайте GID новой группы как AdditionalGroups через конфигурации контейнера докеров.
     
     
     
     
     
     • По-прежнему требуется, чтобы докер поддерживал передачу AdditionalGroups в libcontainer (https://github.com/docker/docker/issues/9360).
     
     
     
     • Может потребоваться обновление fsouza/go-dockerclient для поддержки AdditionalGroups
     
     
     
  
  
• При создании томов HostDir для нового модуля Kubelet:
  
  
  
  • Не трогайте том, поскольку эти каталоги не создаются Kubernetes.
  
  
  • @LuqmanSahaf : это предмет обсуждения, но я считаю, что, поскольку Kubernetes не создает HostDir и поскольку он может содержать существующие данные, Kubernetes не должен заниматься его изменением. Мы должны оставить это на усмотрение создателя и сопровождающего HostDir, чтобы изменить его владельца или разрешения, чтобы позволить контейнерам получить к нему доступ.
  
  

Есть важное различие между перезапуском контейнера и подом.
удаляется. Когда контейнер перезагружается, данные в обычном emptyDir
объем безопасен. когда стручок удален, он должен УДАЛИТЬСЯ. Уход
Hostdata и ожидать, что он появится в какой-то более поздний момент времени, - это
в лучшем случае неловко.

Все это усложняется, как только появляются пользовательские пространства имен.

В среду, 14 января 2015 г., в 0:04, Luqman [email protected] написал:

Этот документ
https://github.com/GoogleCloudPlatform/kubernetes/blob/master/docs/volumes.md#emptydir ,
упоминает, что когда модуль не связан, emptyDir удаляется. В случае использования
Hadoop, данные могут быть важны и могут потребоваться, когда другой модуль
Hadoop возвращается (или контейнер перезагружается). Итак, HostDir необходимо использовать
для сохранения данных, даже если модуль не привязан. Но Hadoop требует разрешений для
быть установленным для пользователя для каталога данных. Надеюсь, это объясняет.

Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/2630#issuecomment -69881834
.

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

Многие старые приложения, которые связываются с низкими (привилегированными) портами, сначала запускаются как root, а затем сразу же передают права другому пользователю. В таком сценарии контейнер должен быть настроен для запуска приложения от имени пользователя root, чтобы исходный пользователь (root) имел доступ к тому. Как только приложение вызовет setuid(2) / seteuid(2) , оно больше не получит доступа. Теперь единственный способ получить доступ к этому каталогу - изменить контейнер на chown том перед запуском самого приложения. Это та ситуация, в которой я сейчас нахожусь.

В связи с этим я хотел бы высказать другое мнение в пользу расширения API, чтобы разрешить явное указание UID и GID поскольку я не думаю, что текущее предложение охватывает все возможные (разумные) случаи применения.

Как минимум, emptydir должен использовать UID / GID / метки контекста безопасности (если они указаны).

Я думаю, что добавление UID к томам - это хитрость и избыточность. Я бы предпочел, чтобы мы поступили правильно и заставили Docker поддерживать дополнительные идентификаторы групп.

+1, но также:

Как минимум, emptydir должен использовать UID / GID / метки контекста безопасности (если они указаны).

Теперь, когда у нас есть API контекста безопасности, я думаю, мы должны заставить emptyDir работать с контекстом безопасности контейнеров в модуле. Одна небольшая проблема, которую нужно сгладить по этому поводу, заключается в том, что тома ограничены областью контейнера, а контексты безопасности - областью контейнера. Я думаю, вам нужно будет посмотреть, в каких контейнерах смонтирован том и каковы их контексты безопасности. Если есть один контейнер, который монтирует emptyDir, это просто - используйте контекст безопасности этого контейнера. Если их несколько, это становится рискованно:

1. Все ли контейнеры, устанавливающие emptyDir, должны иметь одинаковый UID?
2. Должны ли контейнеры иметь одинаковые параметры SELinux?
3. Можем ли мы иметь варианты использования, в которых есть два разных контекста SELinux, которые оба должны использовать том? Можем ли мы синтезировать уровни для тома из меток разных контекстов SELinux разных контейнеров, которые имеют одного и того же пользователя, роль и тип, но разные уровни?

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

@smarterclayton @thockin @erictune @ pweil-

Мне здесь не нравится эвристика. Я подтверждаю, что предложил
эвристично, но это было полгода назад :)

Кроме поддержки Docker еще не сделано, почему мы не можем что-то сделать
нравиться:

1. Всем томам назначается уникальный GID (возможно, уникальный для компьютера или
   выделено хозяином?)
2. Все тома смонтированы g + srwx
3. Все контейнеры в модуле получают все тома в GID этого модуля в своих
   дополнительные группы

В результате все контейнеры в модуле могут получить доступ ко всем томам.
в модуле без ограничений, независимо от того, какой UID у каждого контейнера
с использованием.

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

Далее мы должны определить «все объемы». emptyDir довольно очевиден. Какие
происходит с монтировками hostPath, которые не существовали и были созданы для этого
использовать? Кажется разумным. А как насчет ранее существовавших монтировок hostPath?
это использование - мы никак не можем их изменить. А как насчет таких вещей, как PD? Мы
запустите рекурсивный chown / chgrp / chmod Blech.

@mrunalp для статуса поддержки

Ожидание объединения https://github.com/docker/libcontainer/pull/603 .

Я утверждаю, что все тома в пакете должны быть доступны для всех контейнеров.

Прошлой ночью я много думал об этом, и в этом я согласен с вами.

Я не знаю, означает ли это, что нам нужен контекст безопасности на уровне пода или
хоть что-то :)

4 июня 2015 г. в 8:40 Пол Мори [email protected] написал:

Я утверждаю, что все тома в пакете должны быть доступны для всех контейнеров.

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

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/2630#issuecomment -108939442
.

Хотя - я могу разместить два контейнера и не хочу, чтобы они разделяли содержимое (журналы базы данных и веб-журналы), но делюсь работой для.

4 июня 2015 г. в 12:22 Тим Хокин написал на [email protected] :

Я не знаю, означает ли это, что нам нужен контекст безопасности на уровне пода или
хоть что-то :)

4 июня 2015 г. в 8:40 Пол Мори [email protected] написал:

Я утверждаю, что все тома в пакете должны быть доступны для всех контейнеров.

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

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/2630#issuecomment -108939442
.

-
Ответьте на это письмо напрямую или просмотрите его на GitHub.

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

Четверг, 4 июня 2015 г., в 9:30, Клейтон Коулман [email protected]
написал:

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

4 июня 2015 г., в 12:22 Тим Хокин [email protected]
написал:

Я не знаю, означает ли это, что нам нужен контекст безопасности на уровне пода или
хоть что-то :)

Четверг, 4 июня 2015 г., 8:40, Пол Мори [email protected]
написал:

Я утверждаю, что все тома в пакете должны быть доступны всем
контейнеры

Вчера вечером много думал об этом, и я согласен с
ты
по этому поводу.

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
<
https://github.com/GoogleCloudPlatform/kubernetes/issues/2630#issuecomment-108939442>

.

-
Ответьте на это письмо напрямую или просмотрите его на GitHub.

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/2630#issuecomment -108957878
.

Аргумент здесь, кажется, состоит в том, что вам не нужна более сложная внутренняя безопасность модуля, чем «не монтировать один и тот же том в разных контекстах». Я согласен с единым контекстом безопасности для модуля - просто отмечу, что если вы хотите иметь сложные, безопасные модули, вы можете использовать изоляцию пользователей между контейнерами для защиты содержимого диска.

----- Исходное сообщение -----

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

Четверг, 4 июня 2015 г., в 9:30, Клейтон Коулман [email protected]
написал:

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

4 июня 2015 г., в 12:22 Тим Хокин [email protected]
написал:

Я не знаю, означает ли это, что нам нужен контекст безопасности на уровне пода или
хоть что-то :)

Четверг, 4 июня 2015 г., 8:40, Пол Мори [email protected]
написал:

Я утверждаю, что все тома в пакете должны быть доступны всем
контейнеры

Вчера вечером много думал об этом, и я согласен с
ты
по этому поводу.

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
<
https://github.com/GoogleCloudPlatform/kubernetes/issues/2630#issuecomment-108939442>

.

-
Ответьте на это письмо напрямую или просмотрите его на GitHub.

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/2630#issuecomment -108957878
.

---

Ответьте на это письмо напрямую или просмотрите его на GitHub:
https://github.com/GoogleCloudPlatform/kubernetes/issues/2630#issuecomment -108959938

Грм.

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

----- Исходное сообщение -----

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

----- Исходное сообщение -----

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

Четверг, 4 июня 2015 г., в 9:30, Клейтон Коулман [email protected]
написал:

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

4 июня 2015 г., в 12:22 Тим Хокин [email protected]
написал:

Я не знаю, означает ли это, что нам нужен контекст безопасности на уровне пода или
хоть что-то :)

Четверг, 4 июня 2015 г., 8:40, Пол Мори [email protected]
написал:

Я утверждаю, что все тома в пакете должны быть доступны всем
контейнеры

Вчера вечером много думал об этом, и я согласен с
ты
по этому поводу.

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
<
https://github.com/GoogleCloudPlatform/kubernetes/issues/2630#issuecomment-108939442>

.

-
Ответьте на это письмо напрямую или просмотрите его на GitHub.

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/2630#issuecomment -108957878
.

---

Ответьте на это письмо напрямую или просмотрите его на GitHub:
https://github.com/GoogleCloudPlatform/kubernetes/issues/2630#issuecomment -108959938

Мы должны совместно использовать пространство имен пользователей в модуле.

Четверг, 4 июня 2015 г., в 10:32, Клейтон Коулман [email protected]
написал:

Хотя контекст безопасности пода вряд ли будет работать на самом деле
контейнеров после приземления пользовательских пространств имен - UID, под которым запускается контейнер (в пользовательском
namespaces) действительно привязан к контейнеру, а не к модулю. Так что либо это
должен быть контекстом безопасности по умолчанию на уровне модуля (переопределяемый), или
вместо контекста безопасности тома.

----- Исходное сообщение -----

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

----- Исходное сообщение -----

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

В четверг, 4 июня 2015 г., в 9:30, Клейтон Коулман <
[email protected]>
написал:

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

4 июня 2015 г., в 12:22 Тим Хокин [email protected]
написал:

Я не знаю, означает ли это, что нам нужен контекст безопасности на уровне пода или
хоть что-то :)

Четверг, 4 июня 2015 г., 8:40, Пол Мори <
[email protected]>
написал:

Я утверждаю, что все тома в пакете должны быть доступны всем
контейнеры

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

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
<

https://github.com/GoogleCloudPlatform/kubernetes/issues/2630#issuecomment -108939442

.

-
Ответьте на это письмо напрямую или просмотрите его на GitHub.

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
<
https://github.com/GoogleCloudPlatform/kubernetes/issues/2630#issuecomment -108957878

.

---

Ответьте на это письмо напрямую или просмотрите его на GitHub:

https://github.com/GoogleCloudPlatform/kubernetes/issues/2630#issuecomment -108959938

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/2630#issuecomment -108983917
.

Пространство имен пользователей двух контейнеров, вероятно, должно быть в одном диапазоне. Но UID контейнера A и B не обязательно должны быть ==, и во многих случаях вы не хотите, чтобы они были банально ==, потому что вы можете захотеть «прочитать» том, но не записать его.

----- Исходное сообщение -----

Мы должны совместно использовать пространство имен пользователей в модуле.

Четверг, 4 июня 2015 г., в 10:32, Клейтон Коулман [email protected]
написал:

Хотя контекст безопасности пода вряд ли будет работать на самом деле
контейнеров после приземления пользовательских пространств имен - UID, под которым запускается контейнер (в пользовательском
namespaces) действительно привязан к контейнеру, а не к модулю. Так что либо это
должен быть контекстом безопасности по умолчанию на уровне модуля (переопределяемый), или
вместо контекста безопасности тома.

----- Исходное сообщение -----

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

----- Исходное сообщение -----

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

В четверг, 4 июня 2015 г., в 9:30, Клейтон Коулман <
[email protected]>
написал:

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

4 июня 2015 г., в 12:22 Тим Хокин [email protected]
написал:

Я не знаю, означает ли это, что нам нужен контекст безопасности на уровне пода или
хоть что-то :)

Четверг, 4 июня 2015 г., 8:40, Пол Мори <
[email protected]>
написал:

Я утверждаю, что все тома в пакете должны быть доступны всем
контейнеры

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

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
<

https://github.com/GoogleCloudPlatform/kubernetes/issues/2630#issuecomment -108939442

.

-
Ответьте на это письмо напрямую или просмотрите его на GitHub.

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
<
https://github.com/GoogleCloudPlatform/kubernetes/issues/2630#issuecomment -108957878

.

---

Ответьте на это письмо напрямую или просмотрите его на GitHub:

https://github.com/GoogleCloudPlatform/kubernetes/issues/2630#issuecomment -108959938

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/2630#issuecomment -108983917
.

---

Ответьте на это письмо напрямую или просмотрите его на GitHub:
https://github.com/GoogleCloudPlatform/kubernetes/issues/2630#issuecomment -108987165

@smarterclayton

Пространство имен пользователей двух контейнеров, вероятно, должно быть в одном диапазоне. Но UID контейнера A и B не обязательно должны быть ==, и во многих случаях вы не хотите, чтобы они были банально ==, потому что вы можете захотеть «прочитать» том, но не записать его.

Как вы думаете, можно ли сделать вывод об этом по тому, установлен ли флаг readOnly на VolumeMount?

Некоторые мысли ...

1. При монтировании тома для контейнера он может унаследовать SC контейнера, если для него ничего не установлено.
2. В сложном случае мы могли бы указать SC для тома для поддержки диапазонов меток SELinux, как упоминалось ранее, и в этом случае он не будет наследовать SC тома.
3. Для предопределенных SC тома SC контейнера должен быть выделен способом, совместимым с желаемой безопасностью (т. Е. Объем имеет диапазон s0:c1.c10 а контейнер имеет s0:c1,c2 , GID, который только читает, и т. Д. ) для облегчения индивидуальных, сложных подходов с мелкозернистым доступом

----- Исходное сообщение -----

Некоторые мысли ...

1. При монтировании тома для контейнера он может унаследовать SC
   контейнер, если в нем ничего не установлено.

Хм - это означает, что модуль с одним контейнером будет вести себя иначе, чем модуль с двумя контейнерами?

1. В сложном случае мы можем указать SC для поддерживаемого тома.
   диапазоны меток SELinux, как упоминалось ранее, и в этом случае это не будет
   наследуют SC объема
2. Для предопределенных SC тома необходимо выделить SC контейнера.
   способом, совместимым с желаемой безопасностью (т. е. объем имеет диапазон
   s0:c1.c10 и в контейнере есть s0:c1,c2 , GID, который только читал и т. Д.)
   облегчить индивидуальные, сложные подходы с мелкозернистым доступом

---

Ответьте на это письмо напрямую или просмотрите его на GitHub:
https://github.com/GoogleCloudPlatform/kubernetes/issues/2630#issuecomment -108991796

Хм - это означает, что модуль с одним контейнером будет вести себя иначе, чем модуль с двумя контейнерами?

И здесь некоторая сложность возникает из-за гибкости. Допустимый вариант использования одного модуля - иметь разные контексты безопасности для каждого контейнера в модуле. Точно так же в OpenShift, если континенты отправляют запросы SC, каждый контейнер может проверяться на соответствие различным SCC. В этом случае кажется, что предопределенный SC на томе должен использоваться с соответствующими SC контейнера. Наследование - это просто функция простоты использования.

Еще одна идея, которую можно бросить против стены - возможность перейти от заранее определенного SC на томе (унаследованном или нет) к политике RunInRange и проверка того, что все SC контейнера, запрашивающие том, будут иметь какой-то доступ.

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

@thockin @smarterclayton

Не знаю, что значит «расслабляет режим» - можно конкретнее?

В пятницу, 5 июня 2015 г., в 14:41 Пол Мори [email protected] написал:

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

@thockin https://github.com/thockin @smarterclayton
https://github.com/smarterclayton

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/2630#issuecomment -109447608
.

Виноват. Я имел ввиду сделать emptyDir 0777 вместо 0700.

Как минимум для нас (Пол) мы могли бы использовать sc первого контейнера, который монтирует том, пока не получим более широкое решение. После этого пользователи смогут контролировать порядок, и мы, по крайней мере, будем непоколебимы.

5 июня 2015 г. в 18:01 Пол Мори [email protected] написал:

Виноват. Я имел ввиду сделать emptyDir 0777 вместо 0700.

-
Ответьте на это письмо напрямую или просмотрите его на GitHub.

@smarterclayton , вот что я собирался сделать дальше. Нам все еще нужно исправить
случай UID без полномочий root, когда SELinux не задействован - который, я думаю, нам нужен
0777, пока в докере не появятся дополнительные группы.

В пятницу, 5 июня 2015 г., в 18:13, Клейтон Коулман [email protected]
написал:

Как минимум для нас (Пола) мы могли бы использовать sc первого контейнера, который
монтирует том, пока мы не получим более широкое решение. После этого пользователи могут управлять
заказ, и мы, по крайней мере, будем непоколебимы.

5 июня 2015 г., в 18:01, Пол Мори [email protected]
написал:

Виноват. Я имел ввиду сделать emptyDir 0777 вместо 0700.

-
Ответьте на это письмо напрямую или просмотрите его на GitHub.

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/2630#issuecomment -109457218
.

Я согласен с тем, что, вероятно, необходим отдельный контекст безопасности для томов подов (индивидуальных или групповых).

5 июня 2015 г. в 18:39 Пол Мори [email protected] написал:

@smarterclayton , вот что я собирался сделать дальше. Нам все еще нужно исправить
случай UID без полномочий root, когда SELinux не задействован - который, я думаю, нам нужен
0777, пока в докере не появятся дополнительные группы.

В пятницу, 5 июня 2015 г., в 18:13, Клейтон Коулман [email protected]
написал:

Как минимум для нас (Пола) мы могли бы использовать sc первого контейнера, который
монтирует том, пока мы не получим более широкое решение. После этого пользователи могут управлять
заказ, и мы, по крайней мере, будем непоколебимы.

5 июня 2015 г., в 18:01, Пол Мори [email protected]
написал:

Виноват. Я имел ввиду сделать emptyDir 0777 вместо 0700.

-
Ответьте на это письмо напрямую или просмотрите его на GitHub.

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/2630#issuecomment -109457218
.

-
Ответьте на это письмо напрямую или просмотрите его на GitHub.

Я согласен с тем, что, вероятно, необходим отдельный контекст безопасности для томов подов (индивидуальных или групповых).

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

Для сравнения: мы намеренно НЕ так гибки для таких вещей, как
RestartPolicy - определение разумной семантики для такого пограничного случая просто
не стоит усилий. Стоит ли прилагать усилия для обеспечения безопасности?
4 июня 2015 г., 11:27, «Пол Вейл» [email protected] написал:

Hrm - это означает, что модуль с одним контейнером будет вести себя иначе, чем модуль
стручок с двумя контейнерами?

И здесь некоторая сложность возникает из-за гибкости. Это
является допустимым вариантом использования одного модуля, чтобы иметь разные контексты безопасности для
каждый контейнер в капсуле. И точно так же в OpenShift, если континенты
Запросы make SC, каждый контейнер может проверять по разным SCC. В
В этом случае кажется, что предопределенный SC на томе следует использовать с
контейнерные SC, соответствующие требованиям. Наследование - это просто функция простоты использования.

Еще одна идея, которую можно бросить об стену - возможность уйти из
предварительно определенный SC на томе (унаследованный или нет) в политику RunInRange и
проверка того, что все SC контейнера, запрашивающие том, будут иметь некоторые
своего рода доступ.

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/2630#issuecomment -108999035
.

Разве мы не можем сделать это 0770 и установить идентификатор группы для него и каждого контейнера в
стручок? Это грубо, но лучше, чем 0777 и ближе к тому месту, куда нам следует идти
(Дополнительные GID ИМО). Насколько я понимаю, Security Context еще не
разрешить контейнеру установить GID ...
5 июня 2015 г. в 15:01 "Пол Мори" [email protected] написал:

Виноват. Я имел ввиду сделать emptyDir 0777 вместо 0700.

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/2630#issuecomment -109452834
.

Я мог бы жить с этим, если бы он сопровождался гигантским TODO и документами справа.
места.
5 июня 2015 г. в 15:13 «Клейтон Коулман» [email protected] написал:

Как минимум для нас (Пола) мы могли бы использовать sc первого контейнера, который
монтирует том, пока мы не получим более широкое решение. После этого пользователи могут управлять
заказ, и мы, по крайней мере, будем непоколебимы.

5 июня 2015 г., в 18:01, Пол Мори [email protected]
написал:

Виноват. Я имел ввиду сделать emptyDir 0777 вместо 0700.

-
Ответьте на это письмо напрямую или просмотрите его на GitHub.

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/2630#issuecomment -109457218
.

Я действительно очень хочу опираться на простые предположения внутри модуля. Добавление SC на
объемы не проще.
5 июня 2015 г., 15:44, «Пол Мори» [email protected] написал:

Я согласен с тем, что отдельный контекст безопасности для томов модуля
(индивидуальный или групповой), вероятно, необходимо.

Я тоже так думаю, после того, как мой мозг тщательно крендели во время размышлений
через все перестановки того, с чем вам пришлось бы справиться без него. [изображение:
: curly_loop:] [изображение:: curly_loop:] [изображение:: curly_loop:]

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/2630#issuecomment -109468896
.

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

Итак, два варианта кажутся такими:

1. Правила, основанные на первом контейнере, использующем том (первый в списке контейнеров pod)
2. Явная настройка уровня модуля

SC по умолчанию на уровне модуля имеет смысл, в то время как первый вариант также имеет смысл, но зависит от порядка и в некоторой степени неявно.

7 июня 2015 г. в 13:55 Тим Хокин [email protected] написал:

Я действительно очень хочу опираться на простые предположения внутри модуля. Добавление SC на
объемы не проще.
5 июня 2015 г., 15:44, «Пол Мори» [email protected] написал:

Я согласен с тем, что отдельный контекст безопасности для томов модуля
(индивидуальный или групповой), вероятно, необходимо.

Я тоже так думаю, после того, как мой мозг тщательно крендели во время размышлений
через все перестановки того, с чем вам пришлось бы справиться без него. [изображение:
: curly_loop:] [изображение:: curly_loop:] [изображение:: curly_loop:]

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/2630#issuecomment -109468896
.

-
Ответьте на это письмо напрямую или просмотрите его на GitHub.

Я согласен, что группа в целом полезна. Но для лейблов это не сработает.

7 июня 2015 г. в 13:50 Тим Хокин [email protected] написал:

Разве мы не можем сделать это 0770 и установить идентификатор группы для него и каждого контейнера в
стручок? Это грубо, но лучше, чем 0777 и ближе к тому месту, куда нам следует идти
(Дополнительные GID ИМО). Насколько я понимаю, Security Context еще не
разрешить контейнеру установить GID ...
5 июня 2015 г. в 15:01 "Пол Мори" [email protected] написал:

Виноват. Я имел ввиду сделать emptyDir 0777 вместо 0700.

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/2630#issuecomment -109452834
.

-
Ответьте на это письмо напрямую или просмотрите его на GitHub.

Да, я вообще не знаю selinux (он когда-либо доставлял мне проблемы,
Не знаю, как решить - так же, как здесь).
7 июня 2015 г. в 11:05 «Клейтон Коулман» [email protected] написал:

Я согласен, что группа в целом полезна. Но для лейблов это не сработает.

7 июня 2015 г., в 13:50 Тим Хокин [email protected]
написал:

Разве мы не можем сделать это 0770 и установить идентификатор группы для него и каждого контейнера в
стручок? Он грубый, но лучше, чем 0777 и ближе к тому месту, где надо
идти
(Дополнительные GID ИМО). Насколько я понимаю, Security Context еще не
разрешить контейнеру установить GID ...
5 июня 2015 г. в 15:01 "Пол Мори" [email protected] написал:

Виноват. Я имел ввиду сделать emptyDir 0777 вместо 0700.

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
<
https://github.com/GoogleCloudPlatform/kubernetes/issues/2630#issuecomment-109452834>

.

-
Ответьте на это письмо напрямую или просмотрите его на GitHub.

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/2630#issuecomment -109784566
.

Относитесь к нему как к 700 - если ярлыки разные, вы их не видите, если они есть, вы можете.

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

7 июня 2015 г. в 14:21 thockin-cc [email protected] написал:

Да, я вообще не знаю selinux (он когда-либо доставлял мне проблемы,
Не знаю, как решить - так же, как здесь).
7 июня 2015 г. в 11:05 «Клейтон Коулман» [email protected] написал:

Я согласен, что группа в целом полезна. Но для лейблов это не сработает.

7 июня 2015 г., в 13:50 Тим Хокин [email protected]
написал:

Разве мы не можем сделать это 0770 и установить идентификатор группы для него и каждого контейнера в
стручок? Он грубый, но лучше, чем 0777 и ближе к тому месту, где надо
идти
(Дополнительные GID ИМО). Насколько я понимаю, Security Context еще не
разрешить контейнеру установить GID ...
5 июня 2015 г. в 15:01 "Пол Мори" [email protected] написал:

Виноват. Я имел ввиду сделать emptyDir 0777 вместо 0700.

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
<
https://github.com/GoogleCloudPlatform/kubernetes/issues/2630#issuecomment-109452834>

.

-
Ответьте на это письмо напрямую или просмотрите его на GitHub.

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/2630#issuecomment -109784566
.

-
Ответьте на это письмо напрямую или просмотрите его на GitHub.

Хрм
В воскресенье, 7 июня 2015 г., в 14:25 Клейтон Коулман [email protected]
написал:

Относитесь к нему как к 700 - если ярлыки разные, вы его не увидите, если они
вы можете.

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

7 июня 2015 г., в 14:21, thockin-cc [email protected]
написал:

Да, я вообще не знаю selinux (он когда-либо доставлял мне проблемы
что
Не знаю, как решить - так же, как здесь).
7 июня 2015 г., 11:05, "Клейтон Коулман" [email protected]
написал:

Я согласен, что группа в целом полезна. Но для лейблов это не сработает.

7 июня 2015 г., в 13:50 Тим Хокин [email protected]
написал:

Разве мы не можем сделать это 0770 и установить для него идентификатор группы и каждый
контейнер в
стручок? Он грубый, но лучше, чем 0777 и ближе к тому месту, где мы
должен
идти
(Дополнительные GID ИМО). Насколько я понимаю, контекст безопасности не
пока что
разрешить контейнеру установить GID ...
5 июня 2015 г., 15:01, "Пол Мори" [email protected]
написал:

Виноват. Я имел ввиду сделать emptyDir 0777 вместо 0700.

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
<

https://github.com/GoogleCloudPlatform/kubernetes/issues/2630#issuecomment-109452834>

.

-
Ответьте на это письмо напрямую или просмотрите его на GitHub.

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
<
https://github.com/GoogleCloudPlatform/kubernetes/issues/2630#issuecomment-109784566>

.

-
Ответьте на это письмо напрямую или просмотрите его на GitHub.

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/2630#issuecomment -109785941
.

Пока не похоже, что докер выставил контроль над группой. Я
что-то упустил, @thockin? Должен ли кубелет устанавливаться на
контейнерный процесс? Для меня это звучит пикантно.
В воскресенье , 7 июня 2015 г., в 15:22 Пол Мори

Хрм
В воскресенье, 7 июня 2015 г., в 14:25 Клейтон Коулман [email protected]
написал:

Относитесь к нему как к 700 - если ярлыки разные, вы его не увидите, если они
вы можете.

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

7 июня 2015 г., в 14:21, thockin-cc [email protected]
написал:

Да, я вообще не знаю selinux (он когда-либо доставлял мне проблемы
что
Не знаю, как решить - так же, как здесь).
7 июня 2015 г., 11:05, "Клейтон Коулман" [email protected]
написал:

Я согласен, что группа в целом полезна. Это не сработает для лейблов
хотя.

7 июня 2015 г., в 13:50 Тим Хокин [email protected]
написал:

Разве мы не можем сделать это 0770 и установить для него идентификатор группы и каждый
контейнер в
стручок? Он грубый, но лучше, чем 0777 и ближе к тому месту, где мы
должен
идти
(Дополнительные GID ИМО). Насколько я понимаю, контекст безопасности не
пока что
разрешить контейнеру установить GID ...
5 июня 2015 г., 15:01, "Пол Мори" [email protected]
написал:

Виноват. Я имел ввиду сделать emptyDir 0777 вместо 0700.

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
<

https://github.com/GoogleCloudPlatform/kubernetes/issues/2630#issuecomment-109452834>

.

-
Ответьте на это письмо напрямую или просмотрите его на GitHub.

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
<
https://github.com/GoogleCloudPlatform/kubernetes/issues/2630#issuecomment-109784566>

.

-
Ответьте на это письмо напрямую или просмотрите его на GitHub.

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/2630#issuecomment -109785941
.

Множественный сбой GH, мой плохой!

Хм, я думал, докер позволяет устанавливать GID. Проклятие.
7 июня 2015 г., 13:23, "Пол Мори" [email protected] написал:

Пока не похоже, что докер выставил контроль над группой. Я
что-то упустил, @thockin? Должен ли кубелет устанавливаться на
контейнерный процесс? Для меня это звучит пикантно.
В воскресенье , 7 июня 2015 г., в 15:22 Пол Мори

Хрм
В воскресенье, 7 июня 2015 г., в 14:25 Клейтон Коулман < [email protected]

написал:

Относитесь к нему как к 700 - если ярлыки разные, вы его не увидите, если они
находятся
вы можете.

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

7 июня 2015 г., в 14:21, thockin-cc [email protected]
написал:

Да, я вообще не знаю selinux (он когда-либо доставлял мне проблемы
что
Не знаю, как решить - так же, как здесь).
7 июня 2015 г., 11:05, "Клейтон Коулман" [email protected]
написал:

Я согласен, что группа в целом полезна. Это не сработает для лейблов
хотя.

7 июня 2015 г., в 13:50 Тим Хокин [email protected]
написал:

Разве мы не можем сделать это 0770 и установить для него идентификатор группы и каждый
контейнер в
стручок? Он грубый, но лучше, чем 0777 и ближе к тому месту, где мы
должен
идти
(Дополнительные GID ИМО). Насколько я понимаю, контекст безопасности
нет
пока что
разрешить контейнеру установить GID ...
5 июня 2015 г., 15:01, "Пол Мори" [email protected]
написал:

Виноват. Я имел ввиду сделать emptyDir 0777 вместо 0700.

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
<

https://github.com/GoogleCloudPlatform/kubernetes/issues/2630#issuecomment -109452834

.

-
Ответьте на это письмо напрямую или просмотрите его на GitHub.

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
<

https://github.com/GoogleCloudPlatform/kubernetes/issues/2630#issuecomment -109784566

.

-
Ответьте на это письмо напрямую или просмотрите его на GitHub.

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
<
https://github.com/GoogleCloudPlatform/kubernetes/issues/2630#issuecomment -109785941

.

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/2630#issuecomment -109797284
.

@thockin : '- /

В воскресенье, 7 июня 2015 г., в 20:54 Тим Хокин [email protected] написал:

Хм, я думал, докер позволяет устанавливать GID. Проклятие.

7 июня 2015 г., 13:23, "Пол Мори" [email protected] написал:

Пока не похоже, что докер выставил контроль над группой. Я
что-то упустил, @thockin? Должен ли кубелет устанавливаться на
контейнерный процесс? Для меня это звучит пикантно.
В воскресенье , 7 июня 2015 г., в 15:22 Пол Мори

Хрм
В вс, 7 июня 2015 г., 14:25 Clayton Coleman <
[email protected]

написал:

Относитесь к нему как к 700 - если ярлыки разные, вы его не увидите, если они
находятся
вы можете.

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

7 июня 2015 г., в 14:21, thockin-cc [email protected]
написал:

Да, я вообще не знаю selinux (он дал мне только
проблемы
что
Не знаю, как решить - так же, как здесь).
7 июня 2015 г., 11:05, «Клейтон Коулман» <
[email protected]>
написал:

Я согласен, что группа в целом полезна. Это не сработает для лейблов
хотя.

7 июня 2015 г., в 13:50 Тим Хокин <
[email protected]>
написал:

Разве мы не можем сделать это 0770 и установить для него идентификатор группы и каждый
контейнер в
стручок? Он грубый, но лучше, чем 0777 и ближе к тому месту, где мы
должен
идти
(Дополнительные GID ИМО). Насколько я понимаю, контекст безопасности
нет
пока что
разрешить контейнеру установить GID ...
5 июня 2015 г., 15:01, "Пол Мори" [email protected]
написал:

Виноват. Я имел ввиду сделать emptyDir 0777 вместо 0700.

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
<

https://github.com/GoogleCloudPlatform/kubernetes/issues/2630#issuecomment -109452834

.

-
Ответьте на это письмо напрямую или просмотрите его на GitHub.

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
<

https://github.com/GoogleCloudPlatform/kubernetes/issues/2630#issuecomment -109784566

.

-
Ответьте на это письмо напрямую или просмотрите его на GitHub.

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
<

https://github.com/GoogleCloudPlatform/kubernetes/issues/2630#issuecomment -109785941

.

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
<
https://github.com/GoogleCloudPlatform/kubernetes/issues/2630#issuecomment -109797284

.

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/2630#issuecomment -109819177
.

@thockin @pmorie Синтаксис для установки gid: --user " uid: gid ". Например,

docker run -it --rm --user "1:777" busybox sh

@thockin @pmorie Синтаксис для установки gid: --user " uid: gid ". Например,

@pmorie @smarterclayton - тогда мы, вероятно, захотим исправить это в SC и SCC.

Да.

----- Исходное сообщение -----

@thockin @pmorie Синтаксис для установки gid: --user " uid: gid ". Например,

@pmorie @smarterclayton - мы, вероятно, хотим исправить это в SC и SCC
тогда.

---

Ответьте на это письмо напрямую или просмотрите его на GitHub:
https://github.com/GoogleCloudPlatform/kubernetes/issues/2630#issuecomment -110031779

@ pweil-

В понедельник, 8 июня 2015 г., в 11:25, Клейтон Коулман [email protected]
написал:

Да.

----- Исходное сообщение -----

@thockin @pmorie Синтаксис для установки gid: --user " uid: gid ". Для
например

@pmorie @smarterclayton - мы, вероятно, захотим исправить это в SC и
SCC
тогда.

---

Ответьте на это письмо напрямую или просмотрите его на GitHub:

https://github.com/GoogleCloudPlatform/kubernetes/issues/2630#issuecomment -110031779

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/2630#issuecomment -110039834
.

Синтаксис Docker ужасен, пожалуйста, не копируйте его.
8 июня 2015 г. в 8:45 "Пол Мори" [email protected] написал:

@ pweil-

В понедельник, 8 июня 2015 г., в 11:25, Клейтон Коулман < [email protected]

написал:

Да.

----- Исходное сообщение -----

@thockin @pmorie Синтаксис для установки gid: --user " uid: gid ". Для
например

@pmorie @smarterclayton - мы, вероятно, захотим исправить это в SC и
SCC
тогда.

---

Ответьте на это письмо напрямую или просмотрите его на GitHub:

https://github.com/GoogleCloudPlatform/kubernetes/issues/2630#issuecomment -110031779

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
<
https://github.com/GoogleCloudPlatform/kubernetes/issues/2630#issuecomment -110039834

.

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/2630#issuecomment -110049481
.

@thockin согласен, нам нужно отдельное поле gid в контексте безопасности

В понедельник, 8 июня 2015 г., в 12:29, thockin-cc [email protected]
написал:

Синтаксис Docker ужасен, пожалуйста, не копируйте его.

8 июня 2015 г. в 8:45 "Пол Мори" [email protected] написал:

@ pweil-

В понедельник, 8 июня 2015 г., в 11:25, Клейтон Коулман <
[email protected]

написал:

Да.

----- Исходное сообщение -----

@thockin @pmorie Синтаксис для установки gid: --user " uid: gid ".
Для
например

@pmorie @smarterclayton - мы, вероятно, хотим исправить это в SC
а также
SCC
тогда.

---

Ответьте на это письмо напрямую или просмотрите его на GitHub:

https://github.com/GoogleCloudPlatform/kubernetes/issues/2630#issuecomment -110031779

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
<

https://github.com/GoogleCloudPlatform/kubernetes/issues/2630#issuecomment -110039834

.

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
<
https://github.com/GoogleCloudPlatform/kubernetes/issues/2630#issuecomment -110049481

.

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/2630#issuecomment -110065270
.

Синтаксис Docker ужасен, пожалуйста, не копируйте его.

Определенно нет, мы бы добавили поле RunAsGroup int64 .

В зависимости от требований вы можете захотеть сохранить пользователя и группу в виде строк. По умолчанию они ищутся в файлах passwd и group. Если они не найдены и являются числовыми, они преобразуются в uid / gid.

Итак, я знаю, что это дикая и неразумная идея, но с технической точки зрения правильности и многоуровневости PoV мне кажется, что правильным решением было бы просто запретить / игнорировать строку USER в любом файле докеров и заставить людей устанавливать uid контейнера где-нибудь в декларации контейнера / контейнера куба. (хотя это по-прежнему явно страдает безумием, связанным с необходимостью смотреть на / etc / passwd внутри контейнера, чтобы интерпретировать uid чего-то вне контейнера, если мы сделаем это строкой)

Если серьезно, то, похоже, не будет НИКАКОГО хорошего решения, пока мы не дойдем до пользовательских пространств имен. Затем мы можем сгенерировать случайный uid / gid снаружи, привязать каталог emptyDir к выбранному uid / gid и просто позволить контейнеру внутри работать под любым uid / gid, который он хочет. Пока мы не дойдем до этой точки, ничего, кроме уродливого взлома.

Связанный с этим момент, просто к сведению, сегодня (простой) докер выбирает случайный контекст selinux для каждого контейнера. Докер недавно принял новую опцию -v /source:/dest:rw,z . Часть z новая. Это означает выполнение эквивалента chown -R за исключением того, что он устанавливает метку selinux для всех файлов в томе на случайно сгенерированную метку. У них нет возможности фактически chown -R и установить uid / gid, но я знаю, что некоторые люди тоже этого хотят ...

Лично я считаю, что создание контекста безопасности на томе и навязывание сложности пользователю - это единственный «чистый» вариант, если мы просто не проигнорируем его полностью до тех пор, пока пользовательские пространства имен не станут реальностью. Одна большая причина, по которой я думаю, это вместо того, чтобы прыгать на дополнительное решение gid @thockin, заключается в том, что нет аналога selinux. selinux используется аналогично uids. Вы получите один. И либо точно совпадает, либо нет. Это не похоже на группы. У вас не может быть более 1 метки. Даже с пространствами имен пользователей эта часть все равно будет PITA ...

8 июня 2015 г. в 18:45 Эрик Пэрис [email protected] написал:

Итак, я знаю, что это дикая и неразумная идея, но с технической точки зрения правильности и многоуровневости PoV мне кажется, что правильным решением было бы просто запретить / игнорировать строку USER в любом файле докеров и заставить людей устанавливать uid контейнера где-нибудь в декларации контейнера / контейнера куба. (хотя это по-прежнему явно страдает безумием, связанным с необходимостью смотреть на / etc / passwd внутри контейнера, чтобы интерпретировать uid чего-то вне контейнера, если мы сделаем это строкой)

Согласен - в некоторых режимах мы планируем отклонять изображения с нечисловыми именами пользователей. В любом случае вы даже не можете доверять / etc / passwd, так что вы просто компенсируете ленивых авторов изображений.
Если серьезно, то, похоже, не будет НИКАКОГО хорошего решения, пока мы не дойдем до пользовательских пространств имен. Затем мы можем сгенерировать случайный uid / gid снаружи, привязать каталог emptyDir к выбранному uid / gid и просто позволить контейнеру внутри работать под любым uid / gid, который он хочет. Пока мы не дойдем до этой точки, ничего, кроме уродливого взлома.

Людям необходимо записывать образы в известный uid или работать с любым uid. Но вся подготовительная работа, чтобы добраться до пользовательских пространств имен, теперь может быть выполнена. И пользовательские пространства имен не решают проблему владения, потому что у контейнеров может быть несколько пользователей, поэтому вы все равно не знаете, какой uid сопоставить, если изображение не сообщает вам числовой uid.
Связанный с этим момент, просто к сведению, сегодня (простой) докер выбирает случайный контекст selinux для каждого контейнера. Docker недавно принял новую опцию -v / source: / dest: rw , z. Часть z новая. Это означает выполнение эквивалента chown -R, за исключением того, что он устанавливает метку selinux для всех файлов в томе на случайно сгенерированную метку. У них нет возможности фактически chown -R и установить uid / gid, но я знаю, что некоторые люди тоже этого хотят ...

Лично я считаю, что создание контекста безопасности на томе и навязывание сложности пользователю - это единственный «чистый» вариант, если мы просто не проигнорируем его полностью до тех пор, пока пользовательские пространства имен не станут реальностью. Одна большая причина, по которой я думаю, это вместо того, чтобы прыгать на дополнительное решение gid @thockin, заключается в том, что нет аналога selinux. selinux используется аналогично uids. Вы получите один. И либо точно совпадает, либо нет. Это не похоже на группы. У вас не может быть более 1 метки. Даже с пространствами имен пользователей эта часть все равно будет PITA ...

-
Ответьте на это письмо напрямую или просмотрите его на GitHub.

Эта тема имеет отношение к интересам @ jmccormick2001

@thockin @eparis Есть ли смысл выделить отдельный вопрос для обсуждения этой проблемы для NFS и других томов! emptyDir?

да

9 июля 2015 г. в 20:34 Пол Мори [email protected] написал:

@thockin https://github.com/thockin @eparis https://github.com/eparis
Есть ли заслуга в том, чтобы снять отдельный вопрос, чтобы обсудить эту проблему для
NFS и другие тома! EmptyDir?

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/2630#issuecomment -120213150
.

Какой обходной путь рекомендует команда Kubernetes на данный момент? Я вижу следующие варианты:

• Запускать как root
• Первоначально запускать как root и иметь оболочку точки входа, которая отбрасывает указанные каталоги перед удалением разрешений (?? это вообще сработает?)

Ни один из них не кажется особенно приятным.

Я вижу, что исправление было внесено в chmod emptyDirs на 777, но этого нет в 1.0.x (это то, что использует Google Container Engine, моя предпочтительная цель развертывания). Так что, похоже, мне нужно покопаться и использовать один из вышеперечисленных решений на данный момент.

kubernetes v1.1 скоро выйдет с лучшей поддержкой для этого случая!

@pmorie

В понедельник, 2 ноября 2015 г., в 9:03, Джошуа Кван [email protected]
написал:

Какое временное решение порекомендовала команда Kubernetes для этого?
существование? Я вижу следующие варианты:

• Запускать как root
• Первоначально запускать от имени пользователя root и иметь оболочку точки входа, которая
  указанные каталоги перед сбросом разрешений (?? это вообще сработает?)

Ни один из них не кажется особенно приятным.

Я вижу, что исправлено chmod emptyDirs на 777, но этого нет в
1.0.x (это то, что Google Container Engine, мое предпочтительное развертывание
target, использует.) Похоже, мне нужно вникнуть в
выше решения на данный момент.

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/kubernetes/kubernetes/issues/2630#issuecomment -153083650
.

@ joshk0 мы выполняем chown из точки входа контейнеров (сценарий bash) и отключаемся к запуску нашего основного процесса с использованием обычного пользователя с использованием runuser или gosu.

Не идеально, но это единственный способ сделать это в версии 1.0.

@ joshk0 @antoineco Мы только что ввели изменения API, которые позволят вам указать дополнительную группу, которая владеет emptyDir и его производными, а также некоторыми томами блочных устройств: # 15352

Павел,

Есть ли у нас план развития этого? Мы говорили о
FSGid автоматически назначается при поступлении, а затем может быть связан с PV
в итоге. Было бы неплохо увидеть весь этот план.

Во вторник, 3 ноября 2015 г., в 7:01, Пол Мори [email protected] написал:

@ joshk0 https://github.com/joshk0 @antoineco
https://github.com/antoineco Мы только что ввели изменения API, которые
позволит вам указать дополнительную группу, которая владеет emptyDir и его
деривативы и некоторые тома блочных устройств: # 15352
https://github.com/kubernetes/kubernetes/pull/15352

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/kubernetes/kubernetes/issues/2630#issuecomment -153381097
.

@thockin Я бы с удовольствием написал одну, когда освободился от доработки для 3.1 ... Я сделаю для нее проблему.

@pmorie выглядит неплохо с точки зрения юзабилити! Большое спасибо за работу над этим.
Можно ли будет также установить более мелкозернистый режим на точке монтирования? Тома RW правого ряда монтируются с помощью 0777 (1.1-beta.1). У меня есть случай использования, когда это вызывает незначительные проблемы:

❯ kubectl exec mypod -c logrotate -- ls -ld /var/log/containers/rails/
drwxrwxrwx    2 9999     root          4096 Nov  6 14:35 /var/log/containers/rails/

❯ kubectl exec mypod -c logrotate -- logrotate /etc/logrotate.conf  
error: skipping "/var/log/containers/rails/production.log" because parent directory has insecure permissions (It's world writable or writable by group which is not "root") Set "su" directive in config file to tell logrotate which user/group should be used for rotation.

@antoineco Используете ли вы emptyDir для этого тома? Я думаю, что создам проблему, чтобы изменить поведение так, чтобы emptyDirs были chmod a-rwx если указано FSGroup .

Да, это том пустого каталога.

@antoineco Ладно, сегодня я собираюсь в поездку на следующей неделе, но я сделаю для этого проблему и помечу вас в ней. Работает ли для вас семантика, о которой я говорил?

(Я слышал «КубеКон»? 😄)
То, что вы предложили, сработает, но вы, вероятно, имели в виду o -rwx, который установил бы режим и владельца следующим образом: 0770 root : FSGroup . Или я все неправильно понял?

@antoineco Вы сделали :)

Я думаю, что он сформулировал неправильно - я имел в виду, что emptyDir должен быть 0770 root:fsgroup g+s .

@antoineco В качестве обходного пути для

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

@marcolenzo Ничего особенного, я использую крошечный скрипт bash в качестве точки входа: ENTRYPOINT ["/run.sh"]
Этот сценарий устанавливает правильные разрешения для общих томов, а затем запускает мою службу. Пример:

#!/bin/sh

# reset permissions on log volumes
vol=/var/log/nginx
if [ -d "$vol" -a "$(stat -c '%U' "$vol" 2>/dev/null)" = "root" ]; then
    chown app "$vol"
    chmod o-rwx "$vol"
fi

# startup
echo "+-- starting nginx..."
exec nginx "$@"

Заметил, что PR для docker / docker # 9360 слился: docker / docker # 10717

Означает ли это, что теперь можно реализовать решение этой проблемы с помощью идентификатора группы? У меня было несколько случаев, когда мне приходилось делать то же, что и @antoineco , то есть создавать небольшие скрипты запуска, которые мешают мне использовать многие сторонние образы Docker как есть.

@ charles-crain Теперь вы можете работать с дополнительными группами через API двумя способами:

1. Есть список pod.spec.securityContext.supplementalGroups, который позволяет напрямую указывать дополнительные группы.
2. Есть поле pod.spec.securityContext.fsGroup, которое является специальной дополнительной группой - если вы укажете это, блочные устройства и системные тома будут принадлежать этой группе, и каждый контейнер будет работать с этой группой в своем списке дополнительных групп.

Это помогает? Дайте мне знать, если вам понадобится дополнительная информация.

@pmorie Из какой версии поддерживаются pod.spec.securityContext.supplementalGroups и pod.spec.securityContext.fsGroup? Применимо ли это также к несуществующим hostPath, которые создаются при первом запуске POD?

@pmorie Просматривая журналы фиксации, похоже, что fsGroup не поддерживается до 1.2.0-alpha3 да?

Мне кажется, эта проблема вызвана только кубернетами, полагающимися на bind mount. При использовании томов докеров (т.е. созданных с помощью драйвера тома, команды docker volume или неявного VOLUME из Dockerfile) том инициализируется содержимым из образа докера и может быть chwon ed в соответствии с требованиями к изображению. Разве кубернеты не могут использовать Volume API для того же?

@thockin , какое окончательное решение этого вопроса? Я встречаю то же самое при использовании jenkins & glusterfs: jenkins использует UID: 1000, а glusterfs монтируется с помощью UID: 0; Дженкинсы не могут получить доступ к FS :(.

[root<strong i="9">@cdemo01</strong> jenkins]# kc logs jenkins-3tozq
touch: cannot touch ‘/var/jenkins_home/copy_reference_file.log’: Permission denied
Can not write to /var/jenkins_home/copy_reference_file.log. Wrong volume permissions?

@andrejvanderzee @ charles-crain Мои искренние извинения, я почему-то пропустил теги в этой ветке в потоке предупреждений github. FSGroup поддерживается начиная с 1.2.0.

Применимо ли это также к несуществующим hostPath, которые создаются при первом запуске POD?

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

@ k82 Плагин glusterfs в настоящее время не поддерживает FSGroup.

Я уверен, что у нас есть проблема с контролем UID тома, но мне нужно ее найти.

IIUC Empty Dir Volume создаются для Pod, но также уничтожаются при удалении Pod, поэтому их нельзя использовать для постоянных данных (обычно jenkins_home, учитывая сценарий @ k82 ).

В настоящее время я использую 0777 как обходной путь для демонстрационной среды; но для продакшена необходимо решение получше :).

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

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

Вот пример использования директивы fsgroup:

Для контейнера Docker, определенного в https://github.com/robustirc/robustirc/blob/master/Dockerfile (который указывает RUN echo 'nobody:x:99:99:nobody:/:/bin/sh' >> /etc/passwd и USER nobody ), следующая модификация моей конфигурации контроллера репликации kubernetes была необходимо:

--- a/robustirc-node-1.rc.yaml  2016-07-11 22:04:31.795710444 +0200
+++ b/robustirc-node-1.rc.yaml  2016-07-11 22:04:37.815678489 +0200
@@ -14,6 +14,10 @@
     spec:
       restartPolicy: Always
       dnsPolicy: ClusterFirst
+      securityContext:
+        # Specify fsGroup so that the persistent volume is writable for the
+        # non-privileged uid/gid 99, which is used in robustirc’s Dockerfile.
+        fsGroup: 99
       containers:
       - name: robustirc
         image: robustirc/robustirc

Какой на данный момент лучший обходной путь для 1.4?

@stapelberg Я пробовал точно так же, как вы объяснили, с k8s 1.4.6 на томе hostPath, но я все еще вижу, что root владеет смонтированным каталогом с разрешениями 755. Какие-нибудь дополнительные указатели на то, как это отлаживать?

Кроме того, зависит ли это от существования данного пользователя / группы на фактическом узле / хосте, на котором запланирован контейнер?

Ааа ... Не уверен, что смотрю на правильный код, но похоже, что метод setUp ничего не делает для драйвера тома hostPath. См. Https://github.com/kubernetes/kubernetes/blob/master/pkg/volume/host_path/host_path.go#L198

@thockin @ saad-ali Не могли бы вы подтвердить? Похоже, вы, ребята, поддерживаете драйвер тома hostPath.

Поскольку fsGroup пока недоступен для Gluster, есть ли другой рекомендуемый обходной путь, кроме запуска контейнера от имени пользователя root?

FsGroup не поддерживается путём к хосту, вы не хотите, чтобы kubelet делал такие изменения разрешений на хосте.

@pmorie Почему бы не дать разрешение кубелету? В противном случае вынужденная рука должна предоставить контейнеру полный доступ как root для выполнения каких-либо действий на хосте? В конце концов, это должно быть указано в манифесте с помощью fsGroup .

Я согласен с @haf относительно его

Например, инструмент kube-aws позволяет пользователям настраивать автоматически подключаемый диск NFS для всех рабочих процессов во время подготовки кластера. Таким образом, по умолчанию каждый работник имеет диск AWS EFS, подключенный к / efs, когда он подключается к сети (для этого используется cloud-init под капотом). Затем администраторы могут создать PV общего хранилища, указав параметр hostPath для этого монтирования NFS.

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

@ joan38 @rushtehrani Я использую init-containers to chown объем:

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  labels:
    app: jenkins
  name: jenkins
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: jenkins
      annotations:
        pod.alpha.kubernetes.io/init-containers: '[
        {
            "name": "jenkins-init",
            "image": "busybox",
            "imagePullPolicy": "IfNotPresent",
            "command": ["sh", "-c", "chown -R 1234:1234 /jenkins"],
            "volumeMounts": [
                {
                  "name": "jenkins-home",
                  "mountPath": "/jenkins"
                }
            ]
        }
    ]'
    spec:
      containers:
      - name: jenkins
        image: 'amarruedo/jenkins:v2.32.1'
             ..........
     volumes:
      - name: jenkins-home
        vsphereVolume:
          volumePath: "[FAS03_IDVMS] volumes/jenkins"
          fsType: ext4

Я определяю в своих контейнерах UID и GID для известных, поэтому я могу chown в init-container . Я использовал этот подход и с томами hostPath без проблем. Когда FSGroup станет доступным в томах vsphere, я воспользуюсь этим.

Надеюсь это поможет.

Как и в случае с https://github.com/kubernetes/kubernetes/pull/39438#issuecomment -275459427, может быть, мы можем установить FSGroup только в том случае, если создается путь к хосту?

Прочитав эту полную ветку, я не уверен, какое было разрешение. У меня аналогичная проблема, когда я нахожусь на Mac с использованием виртуального бокса и пытаюсь запустить модуль mysql с подключением тома в / data (я также пробовал / Users, но он имеет такое же поведение). Когда minikube создает каталоги, они создаются с правами root и ограниченными разрешениями на запись. Mysql не может писать им, поэтому мои поды падают. Если я minikube ssh и chmod -R 777 / data, тогда поды запускаются и работают правильно. Что мне делать по-другому, чтобы я мог запустить этот модуль, не изменяя разрешения каталога данных?

@justechn , возможно, вы захотите проверить https://kubernetes.io/docs/concepts/policy/security-context/ и https://kubernetes.io/docs/api-reference/v1.6/#podsecuritycontext -v1-core и установите значение fsGroup для любого gid, с которым работает ваш mysql deamon.

fsGroup
Тома, которые поддерживают управление владением, изменяются, чтобы они принадлежали и были доступны для записи GID, указанному в fsGroup .

@antoineco, спасибо за подсказку. Я, должно быть, делаю что-то не так, потому что у меня это не работает. Я вошел в модуль, запустил id mysql и получил обратно uid=999(mysql) gid=999(mysql) groups=999(mysql) . Поэтому я добавил fsGroup с 999 в свою спецификацию и перезапустил, но ничего не изменилось. каталоги по-прежнему принадлежат пользователю root.

spec: {
          containers: [
            {
              name: 'percona',
              image: 'percona:5.6',
              imagePullPolicy: 'Always',
              env: [
                {
                  name: 'MYSQL_ROOT_PASSWORD',
                  value: secrets['system-mysql-root-password'],
                },
                {
                  name: 'MYSQL_OPS_USER',
                  value: variables['system-mysql-ops-user'],
                },
                {
                  name: 'MYSQL_OPS_PASSWORD',
                  value: secrets['system-mysql-ops-password'],
                },
                {
                  name: 'MYSQL_APP_USER',
                  value: variables['system-mysql-app-user'],
                },
                {
                  name: 'MYSQL_APP_PASSWORD',
                  value: secrets['system-mysql-app-password'],
                },
              ],
              ports: [
                {
                  containerPort: 3306,
                  protocol: 'TCP',
                },
              ],
              volumeMounts: [
                { name: 'data', mountPath: '/var/lib/mysql' },
                { name: 'conf', mountPath: '/etc/mysql/conf.d' },
              ],
            },
          ],
          securityContext: {
            fsGroup: 999,
          },
          volumes: [
            { name: 'data', hostPath: { path: '/data/db/db' } },
            { name: 'conf', hostPath: { path: '/data/db/db-conf' } },
          ],
        },

drwxr-xr-x 2 root root 4096 May  9 18:14 db
drwxr-xr-x 2 root root 4096 May  9 18:14 db-conf
drwxr-xr-x 2 root root 4096 May  9 18:14 shared
drwxr-xr-x 2 root root 4096 May  9 18:14 shared-conf
drwxr-xr-x 2 root root 4096 May  9 18:14 shard-1
drwxr-xr-x 2 root root 4096 May  9 18:14 shard-1-conf

Возможно, вам также придется изменить Политику безопасности Pod:
https://kubernetes.io/docs/concepts/policy/pod-security-policy/

Какой прогресс в этом?
Как мы можем получить доступ к PV при использовании пользователей без полномочий root?

ZK не запускается на minikube из-за этого: https://github.com/kubernetes/charts/issues/976

К вашему сведению - для тех, кто приходит к этому и использует обходной путь @amarruedo, его необходимо обновить до нового синтаксиса v1.6 + для initContainers . и выглядит так:

      initContainers:
      - name: volume-mount-hack
        image: busybox
        command: ["sh", "-c", "chown -R 1000:100 /usr/share/elasticsearch/data"]
        volumeMounts:
        - name: data
          mountPath: /usr/share/elasticsearch/data

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

Спасибо @antoineco за предложения, Использование постоянных томов».

Мне удалось простое добавление к Pod.spec с использованием v1.7 и динамически подготовленного постоянного тома AWS для StatefulSet. Мне не требовалась политика безопасности Pod :

      # Allow non-root user to access PersistentVolume
      securityContext:
        fsGroup: 1000

Не могли бы мы иметь больше документации, чем краткое упоминание в Справочнике по API ? Неоднозначно знать, что некоторые типы томов будут работать, не зная, какие именно.

fsGroup: специальная дополнительная группа, которая применяется ко всем контейнерам в модуле. Некоторые типы томов позволяют Kubelet изменять право собственности на этот том, чтобы он принадлежал поду: 1. Владельцем GID будет FSGroup 2. Бит setgid установлен (новые файлы, созданные в томе, будут принадлежать FSGroup) 3 Биты разрешений объединяются оператором ИЛИ с rw-rw ---- Если не задано, Kubelet не будет изменять права собственности и разрешения любого тома.

• @antoineco, документ с концепцией контекста безопасности, который вы упомянули, дает 404, кстати.
• Кажется, что контроль доступа к PV достигнет той же цели, что и

Я попытался смонтировать постоянный том azurefile для Jenkins, и у меня возникла проблема с отказом в разрешении, потому что каталог jenkins_home был только rwx для root, когда Jenkins работает с пользователем jenkins.
Я мог бы обойти проблему, используя securityContext / runAsUser: 0, но было бы лучше унаследовать существующие права dir или предоставить свойство chmod.

cc @ kubernetes / sig-storage-feature-requests @ kubernetes / sig-node-feature-requests

@ Guillaume-Mayer - не сработает ли ловушка жизненного цикла postStart для изменения файлов (в качестве альтернативы - контейнер инициализации, если выполнение необходимо завершить до точки входа)?

@ so0k Это не сработает, если runAsUser и allowPrivilegeEscalation предотвращают использование пользователя root .

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

У меня есть mongodb-cluster в k8s, который использует специальный файл cluster.key для авторизации кластера. Этот файл хранится в секрете; у нас есть клиент, в котором запрещено запускать образы от имени root. У нашего модуля securityContext установлен директивой runAsUser: 1000 . Сам Mongodb запрещает доступ к файлу никому, кроме самого владельца. Он отклонит запуск, если файл доступен для чтения group или other .

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

В настоящее время я работаю над этим, вводя в качестве переменной среды в контейнер инициализации busybox, который, в свою очередь, монтирует emptyDir и записывает туда. После этого секрет больше не монтируется как файл. Это довольно некрасиво, и, если есть шанс избавиться от него, я бы в деле.

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

@ saad-ali

В среду, 21 февраля 2018 г., в 9:34, Джордан Уилсон [email protected]
написал:

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

-
Вы получили это, потому что прокомментировали.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/kubernetes/kubernetes/issues/2630#issuecomment-367406210 ,
или отключить поток
https://github.com/notifications/unsubscribe-auth/ALNCDzdco3jAGv5kwRfMg497RuZeiWWbks5tXFOJgaJpZM4DBDWs
.

Привет!
В итоге я получил приведенную ниже конфигурацию initContainers для предоставления контейнеру node-red-docker, который запускается как непривилегированный пользователь, доступа к внешнему диску. После множества попыток выяснилось, что "runAsUser" 0 (root) сработал.

Ваше здоровье
-Джо

  initContainers:
    - name: volume-mount-hack
      image: nodered/node-red-docker:slim
      command:
        - sh
        - -c
        - 'chmod -R a+rwx /data'
      volumeMounts:
        - name: picturl-persistent-storage
          mountPath: /data
      securityContext:
        runAsUser: 0

Многие старые приложения, которые связываются с низкими (привилегированными) портами, сначала запускаются как root, а затем сразу же передают права другому пользователю. В таком сценарии контейнер должен быть настроен для запуска приложения от имени пользователя root, чтобы исходный пользователь (root) имел доступ к тому. Однако, как только приложение вызовет setuid (2) / seteuid (2), у него больше не будет доступа.

@ eatnumber1 Не могли бы вы подробнее рассказать, почему у нас будет эта проблема с дополнительным групповым решением, упомянутым в этой ветке? IIUC, setuid(2) / seteuid(2) не изменит дополнительную группу вызывающего процесса, поэтому, пока приложение находится в группе, имеющей доступ к тому, у него не должно быть проблем с доступ к объему, верно?

Похоже, я ошибся и вызов setgid(2) не меняет дополнительные группы (как я думал, это так).

Глядя вокруг, похоже , по крайней мере , Nginx капли дополнительных групп в явном виде здесь (и в противном случае было бы уязвимость несовершеннолетнего). Я был бы удивлен, если любое хорошо написанное приложение для сброса привилегий не удаляет дополнительные группы.

Спасибо, @ eatnumber1! Таким образом, Nginx изначально запускается с правами root, а затем сбрасывает uid, gid и дополнительные группы с тем, что настроено в nginx.conf . Затем я думаю, что с помощью контекста безопасности пода мы можем установить fsGroup для группы, настроенной в nginx.conf , таким образом, даже после того, как Nginx сбросит свои дополнительные группы, он все равно сможет получить доступ к тому. Верно?

Из беглого чтения о контекстах безопасности pod кажется, что да.
Однако я их не использовал (обратите внимание, что мой первоначальный комментарий к этой ошибке
несколько лет).
Пт, 6 апреля 2018 г., в 20:28 Цянь Чжан [email protected] написал:

Спасибо @ eatnumber1 https://github.com/eatnumber1 ! Итак, изначально Nginx
запускается с root, а затем сбрасывает uid, gid и дополнительные группы с тем, что
настраиваются в nginx.conf. Тогда я думаю, что с контекстом безопасности модуля
https://kubernetes.io/docs/tasks/configure-pod-container/security-context/ ,
мы можем установить fsGroup для группы, настроенной в nginx.conf, таким образом,
даже после того, как Nginx сбросит свои дополнительные группы, он все равно сможет получить доступ к
объем. Верно?

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/kubernetes/kubernetes/issues/2630#issuecomment-379422625 ,
или отключить поток
https://github.com/notifications/unsubscribe-auth/AABEj5KFwz4VWsvSpT2UwzY_1KIW0DB4ks5tmBZRgaJpZM4DBDWs
.

Помимо дополнительной группы, я думаю, что POSIX ACL может быть еще одним решением для решения этой проблемы, я имею в виду, что мы можем добавить запись ACL для предоставления разрешения rwx пользователю модуля / контейнера на томе. Но я не вижу, чтобы POSIX ACL не упоминался в этой теме, есть ли у него недостатки?

Копия @thockin @ saad-ali

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

Что касается ACL или других механизмов, я не возражаю против них, просто у меня меньше
контекст на них.

В воскресенье, 8 апреля 2018 г., в 18:26 Цянь Чжан [email protected] написал:

Помимо дополнительной группы, я думаю, что POSIX ACL
http://man7.org/linux/man-pages/man5/acl.5.html может быть другим решением
чтобы исправить эту проблему, я имею в виду, что мы можем добавить запись ACL для предоставления разрешения rwx
пользователю модуля / контейнера на томе. Но я не вижу, что POSIX ACL не
упоминается в этой ветке, есть ли у него недостатки?

Копия @thockin https://github.com/thockin @ saad-ali
https://github.com/saad-ali

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/kubernetes/kubernetes/issues/2630#issuecomment-379601556 ,
или отключить поток
https://github.com/notifications/unsubscribe-auth/AFVgVHTRb0-By20y2QzU4idsBoZVDNpLks5tmrjZgaJpZM4DBDWs
.

В частности, он наносит поражение хорошо понятному механизму.

@thockin Не могли бы вы

Мы явно создали дополнительные группы, чтобы мы могли делать такие вещи, как тома
и объемный учет. Это 100% преднамеренное, а затем nginx падает
дополнительные группы во имя безопасности. Нарушение допустимых вариантов использования.

В понедельник, 9 апреля 2018 г., в 17:59 Цянь Чжан [email protected] написал:

В частности, он наносит поражение хорошо понятному механизму.
@thockin https://github.com/thockin Не могли бы вы рассказать немного о
это? А зачем нам исправлять Nginx?

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/kubernetes/kubernetes/issues/2630#issuecomment-379940087 ,
или отключить поток
https://github.com/notifications/unsubscribe-auth/AFVgVPn8KDON0zSROa1Qy1uFgMsaR9jqks5tnAQHgaJpZM4DBDWs
.

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

Более того, даже если вы выберете для использования другой неясный механизм контроля доступа Linux (например, fsuid ), будет _намеренно_, что все возможные типы привилегий будут отброшены, поэтому это будет уязвимостью безопасности, если приложения не откажутся от этой привилегии как хорошо. Это _is_ модель безопасности здесь.

В неконтейнерном мире единственный способ предоставить привилегии приложению после того, как оно отбрасывает привилегии, - это предоставить привилегии пользователю / группе / и т. Д., Которые приложение переключает _ на_. Отсюда мой первоначальный (3-х летний) комментарий о явной поддержке UID и GID, что позволило бы пользователю указать UID или GID, на которые приложение собирается переключиться.

В документации к PodSecurityContext говорится о fsGroup :

Специальная дополнительная группа, которая применяется ко всем контейнерам в пакете. Некоторые типы томов позволяют Kubelet изменять право собственности на этот том, чтобы он принадлежал поду:

1. Владельцем GID будет FSGroup.
2. Установлен бит setgid (новые файлы, созданные в томе, будут принадлежать FSGroup)
3. Биты разрешений объединяются оператором ИЛИ с rw-rw ---- Если не задано, Kubelet не будет изменять права собственности и разрешения любого тома.

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

Да, поэтому я думаю, что установка fsGroup для группы, настроенной в nginx.conf, позволит Nginx получить доступ к тому даже после сброса привилегий, а также заставит работать учет объема.

Но у меня есть еще один вопрос: помимо fsGroup в контексте безопасности модуля, пользователь также может установить fsGroup в контексте безопасности контейнера, поэтому, если в модуле есть несколько контейнеров, и каждый контейнер имеет свой собственный fsGroup , как мы можем убедиться, что все эти контейнеры могут получить доступ к тому (поскольку том может принадлежать только одной группе, а не нескольким)?

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

@tallclair FYI Я считаю, что мы можем закрыть эту проблему

/ sig auth

Ни одно из предложенных решений не работает для меня.

YML:

apiVersion: apps/v1beta1 # for versions before 1.8.0 use apps/v1beta1
kind: Deployment
metadata:
  labels:
    tier: frontend
spec:
  selector:
    matchLabels:
      tier: frontend
  strategy:
    type: Recreate
  template:
    metadata:
      labels:
        tier: frontend
    spec:
      securityContext:
        fsGroup: 1000
        runAsUser: 0
      initContainers:
      - image: some-sftp-container
        name: sftp-mount-permission-fix
        command: ["sh", "-c", "chown -R <user> /mnt/permission-fix"]
        volumeMounts:
        - name: azure
          mountPath: /mnt/permission-fix
      containers:
      - image: some-sftp-container
        name: sftp-container
        ports:
        - containerPort: 22
          name: port_22
        volumeMounts:
        - name: azure
          mountPath: /home/<user>/data
      volumes:
        - name: azure
          azureFile:
            secretName: azure-secret
            shareName: sftp-share
            readOnly: false

Как только Pod готов, я запускаю его в контейнер и проверяю каталоги, ничего не произошло:

root<strong i="10">@container</strong>:/# cd /home/<user>                                                                        
root<strong i="11">@container</strong>:/home/<user># ls -als
total 8
4 drwxr-xr-x 3 root root 4096 Apr 24 18:45 .
4 drwxr-xr-x 1 root root 4096 Apr 24 18:45 ..
0 drwxr-xr-x 2 root root    0 Apr 22 21:32 data
root<strong i="12">@container</strong>:/home/<user># cd data
root<strong i="13">@container</strong>:/home/<user>/data# ls -als
total 1
1 -rwxr-xr-x 1 root root 898 Apr 24 08:55 fix.sh
0 -rwxr-xr-x 1 root root   0 Apr 22 22:27 test.json
root<strong i="14">@container</strong>:/home/<user>/data# 

В какой-то момент на самом контейнере также был значок runAsUser: 0 . Но и это не сработало. Любая помощь приветствуется

Также не получилось запустить чавн после этого

@ eatnumber1, если группа входит в ваши дополнительные группы, не следует ли вам предполагать, что предполагалось, что у вас есть доступ к ресурсам этой группы? Отказ от дополнительных групп означает: «Я знаю, что вы сказали мне, что мне это нужно, но я не хочу этого», а затем жалуется, что у вас этого нет.

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

Может кто-нибудь резюмировать для меня? Или лучше опубликовать полную репродукцию с не вымышленными именами изображений?

@thockin IIUC, Nginx не просто удаляет дополнительные группы, он фактически сбрасывает их в соответствии с настройками в nginx.conf, вызывая initgroups .

Это сработало для меня .. часть сценария.

`` ''
спецификация:
контейнеры:
- имя: Дженкинс
изображение: jenkins / jenkins
порты:
- containerPort: 50000
- порт контейнера: 8080
объем
- mountPath: / var / jenkins_home
имя: jenkins-home
securityContext:
fsGroup: 1000
runAsUser: 0

решения не идеальны, теперь ваши контейнеры работают как root, что противоречит стандартам безопасности, которые k8s пытается навязать своим пользователям.

было бы замечательно, если бы постоянные тома могли быть созданы с учетом securityContext , т.е.
apiVersion: v1 kind: PersistentVolume metadata: name: redis-data-pv namespace: data labels: app: redis spec: securityContext: runAsUser: 65534 fsGroup: 65534 capacity: storage: 1Gi accessModes: - ReadWriteMany persistentVolumeReclaimPolicy: Retain claimRef: namespace: data name: redis-data hostPath: path: "/data"

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

@robbyt прокомментировал
В качестве обходного пути я использую обработчик жизненного цикла postStart, чтобы привязать данные тома к правильным разрешениям. Это может работать не для всех приложений, потому что обработчик жизненного цикла postStart может работать слишком поздно, но он более безопасен, чем запуск контейнера с правами root, а затем исправление разрешений и удаление root (или использование gosu) в сценарии точки входа.

Мы используем initContainer , может ли хук жизненного цикла иметь другой securityContext, чем сам контейнер?

грустно видеть, что после того, как мне снова придется провести исследование, опция @chicocvenancio (которую я тоже использую), по-видимому, по-прежнему остается единственным способом добиться этого.

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

Вот пример из мира PostgreSQL: смонтируйте сертификат клиента TLS для своего приложения с секретным томом. Как везде рекомендовано, вы не запускаете свой контейнер с правами root. Однако библиотека соединений postgres мгновенно пожалуется, что ключ доступен для чтения всем. Вы думаете: «Нет проблем» и меняете режим / режим по умолчанию, чтобы он соответствовал _demanded_ 0600 (что вполне разумно требовать этого в качестве клиентской библиотеки). Однако сейчас это тоже не сработает, потому что теперь root - единственный пользователь, который может читать этот файл.

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

Теперь PostgreSQL определенно является стандартной базой данных и продуктом, которым пользуется множество людей. И запрос на монтирование клиентских сертификатов способом с Kubernetes, который не требует initContainer в качестве обходного пути, не так уж много, чтобы спросить imho.

Так что давайте найдем золотую середину в этом вопросе, а не просто закроем его. :молиться:

Я пытаюсь смонтировать ssh-ключ в пользовательский каталог .ssh с defaultMode 0400, чтобы приложение могло использовать ssh без пароля. Но это не сработает, если секрет установлен как владелец root. Не могли бы вы еще раз объяснить, как это можно решить с помощью fsGroup или другого подобного механизма?
Я не вижу решения, если PodSecurityPolicy включен, поэтому приложения не могут работать от имени пользователя root. Пожалуйста, порекомендуйте.

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

• nginx удаляет дополнительные группы
• ssh / postgres требует определенного режима для ключей (и не принимает групповое чтение)
• что-то о работе с правами root?

Может ли кто-нибудь объяснить проблему (или проблемы) сверху вниз таким образом, чтобы я мог следить, не перечитывая всю цепочку?

Имейте в виду, что тома определены как конструкция Pod-scope, и 2 разных контейнера могут работать как 2 разных UID. Для этого идеально подходит групповая химическая завивка, но если она действительно не отвечает потребностям, давайте исправим. Но сначала мне нужно это понять.

@ saad-ali для вашего радара

@thockin Мой

Верно. Это кажется ясным. Если мы исправим это, применимо ли это ко всем сценариям использования
здесь? Или есть еще?

Я мог видеть добавление поля user в разных местах.

например, начнем с этого. Реализуйте его и добавьте несколько тестов. Мне нужен волонтер
носить футбол. Честно говоря, это не тонна усилий, наверное, меньше
чем на день, но в ближайшее время у меня не будет времени на это потратить.

Кто угодно?

diff --git a/staging/src/k8s.io/api/core/v1/types.go b/staging/src/
k8s.io/api/core/v1/types.go
index 99159ee75a..e98c035528 100644
--- a/staging/src/k8s.io/api/core/v1/types.go
+++ b/staging/src/k8s.io/api/core/v1/types.go
@@ -1048,6 +1048,9 @@ type SecretVolumeSource struct {
        // mode, like fsGroup, and the result can be other mode bits set.
        // +optional
        DefaultMode *int32 `json:"defaultMode,omitempty"
protobuf:"bytes,3,opt,name=defaultMode"`
+       // Optional: user ID to use on created files by default.  Default
is implementation-defined.
+       // +optional
+       DefaultUser *int64 `json:"defaultUser,omitempty"
protobuf:"varint,4,opt,name=defaultUser"`
        // Specify whether the Secret or it's keys must be defined
        // +optional
        Optional *bool `json:"optional,omitempty"
protobuf:"varint,4,opt,name=optional"`
@@ -1474,6 +1477,9 @@ type ConfigMapVolumeSource struct {
        // mode, like fsGroup, and the result can be other mode bits set.
        // +optional
        DefaultMode *int32 `json:"defaultMode,omitempty"
protobuf:"varint,3,opt,name=defaultMode"`
+       // Optional: user ID to use on created files by default.  Default
is implementation-defined.
+       // +optional
+       DefaultUser *int64 `json:"defaultUser,omitempty"
protobuf:"varint,4,opt,name=defaultUser"`
        // Specify whether the ConfigMap or it's keys must be defined
        // +optional
        Optional *bool `json:"optional,omitempty"
protobuf:"varint,4,opt,name=optional"`
@@ -1541,6 +1547,9 @@ type ProjectedVolumeSource struct {
        // mode, like fsGroup, and the result can be other mode bits set.
        // +optional
        DefaultMode *int32 `json:"defaultMode,omitempty"
protobuf:"varint,2,opt,name=defaultMode"`
+       // Optional: user ID to use on created files by default.  Default
is implementation-defined.
+       // +optional
+       DefaultUser *int64 `json:"defaultUser,omitempty"
protobuf:"varint,4,opt,name=defaultUser"`
 }

 // Projection that may be projected along with other supported volume types
@@ -1581,6 +1590,9 @@ type KeyToPath struct {
        // mode, like fsGroup, and the result can be other mode bits set.
        // +optional
        Mode *int32 `json:"mode,omitempty"
protobuf:"varint,3,opt,name=mode"`
+       // Optional: user ID to use on this file.
+       // +optional
+       User *int64 `json:"User,omitempty"
protobuf:"varint,4,opt,name=User"`
 }

 // Local represents directly-attached storage with node affinity (Beta
feature)
@@ -5080,6 +5092,9 @@ type DownwardAPIVolumeSource struct {
        // mode, like fsGroup, and the result can be other mode bits set.
        // +optional
        DefaultMode *int32 `json:"defaultMode,omitempty"
protobuf:"varint,2,opt,name=defaultMode"`
+       // Optional: user ID to use on created files by default.  Default
is implementation-defined.
+       // +optional
+       DefaultUser *int64 `json:"defaultUser,omitempty"
protobuf:"varint,4,opt,name=defaultUser"`
 }

 const (
@@ -5103,6 +5118,9 @@ type DownwardAPIVolumeFile struct {
        // mode, like fsGroup, and the result can be other mode bits set.
        // +optional
        Mode *int32 `json:"mode,omitempty"
protobuf:"varint,4,opt,name=mode"`
+       // Optional: user ID to use on this file.
+       // +optional
+       User *int64 `json:"User,omitempty"
protobuf:"varint,5,opt,name=User"`
 }

 // Represents downward API info for projecting into a projected volume.

Пт, 6 июля 2018 г., в 8:00 Reza [email protected] написал:

@thockin https://github.com/thockin Мой вариант использования очень прост. я
введение секрета (ключа ssh) в контейнер, который не запущен с правами root.
Ключ ssh в /home//.ssh должен иметь разрешение 400, что я могу сделать, но
также должен принадлежать UID, иначе это не сработает. Я не хочу давать это
pod любые привилегии root любого типа, поэтому контейнер инициализации, который изменяет
У меня не работает UID файла. Как мне это сделать, кроме включения
ssh-ключ на изображении?

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/kubernetes/kubernetes/issues/2630#issuecomment-403059487 ,
или отключить поток
https://github.com/notifications/unsubscribe-auth/AFVgVG5ERBNuP4MuNprc27c9YIyajAIJks5uD3uFgaJpZM4DBDWs
.

@ vikaschoudhary16 @derekwaynecarr это имеет некоторое перекрытие / последствия для сопоставления пространства имен пользователя.

@rezroo обходным

@thockin другой

@pearj - это именно обходной путь, который все используют ... и, как следует из названия: это обходной путь, и его нужно решать :) ... Однако есть проблема с этим обходным путем: обновленные секреты в конечном итоге будут обновлены в смонтированном тома, которые позволят действовать при изменении файла в работающем модуле; вы пропустите это обновление, если скопируете его из контейнера инициализации.

@pearj @mheese Эта работа в любом случае не сработает для меня - потому что наша PodSecurityPolicy не позволяет контейнерам запускаться от имени пользователя root - обычные контейнеры или контейнеры инициализации - не имеет значения - никто не может получить доступ к секрету, принадлежащему root, насколько это возможно. Я могу сказать.

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

1. Использование жесткого колпачка для всех контейнеров контейнера.

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

Я не могу использовать одну квоту для обеих целей. Жесткое ограничение применяется ко всем томам emptydir, доступному для записи слою и журналам, но квота, используемая для этой цели, не может использоваться для извлечения хранилища, используемого для каждого тома. Итак, что я хотел бы сделать, так это использовать квоты проекта без принудительного применения, чтобы получить объем хранилища, а также квоты пользователя или группы для реализации жесткого ограничения. Для этого требуется, чтобы каждый модуль имел уникальный UID или единственный уникальный GID (вероятно, лучше всего подойдет уникальный UID, поскольку могут быть причины, по которым модуль должен находиться в нескольких группах).

(Что касается идентификаторов групп и проектов, которые документируются как взаимоисключающие с XFS, на самом деле это уже не так, как я убедился. Я спросил об этом некоторых людей XFS, и они подтвердили, что документация устарела. и требует исправления; это ограничение было снято около 5 лет назад.)

@robbyt, расскажите, пожалуйста, как вам удалось поесть с postStart ? Мой контейнер работает как пользователь без полномочий root, поэтому после запуска по-прежнему используются разрешения без полномочий root, и они не могут их изменять:

chown: / home / user /: Операция запрещена
, сообщение: "chown: / home / user /: В доступе отказано \ nchown: / home / user /: Операция запрещена.

Та же проблема: если у вас есть Dockerized tomcat, который запускает наше веб-приложение, и мы используем jmx для их мониторинга, мы хотим обслуживать пользователя jmxremote и пароль jmxremote в качестве секретов, но tomcat, который, очевидно, не запускается как root, хочет, чтобы файлы jmx доступны для чтения только пользователю, запустившему tomcat.

Приложение: у нас много котов, и вы хотите запускать каждого из них как разные пользователи.

та же проблема!

На данный момент работает способ взлома - установить пользователю root в конце вашего файла dockerfile. И установите собственный сценарий точки входа. Выберите том в своем сценарии пользовательской точки входа, затем используйте gosu для запуска сценария точки входа по умолчанию в качестве пользователя по умолчанию. Что я ненавижу в этом, так это то, что я должен делать это для каждого отдельного изображения, которое использует том в кубернетах. Совершенно хромой. Укажите параметр UID GID в конфигурации монтирования тома или утверждения тома.

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

Правда. У всех хаков есть свои недостатки. Либо это, либо вход в систему как root после создания тома и выбор каталога вручную. Не уверен, что хуже :-D. Не могу поверить, что это вообще вещь.

@thockin из того, что я собираю после этой проблемы вот уже почти 4 года, решение, которое все хотят, - это возможность установить uid и gid для тома - в частности, секретных томов (но не только тех). 6 июля вы опубликовали отправную точку для возможного решения этой проблемы. Если это поддерживается разработчиками, я бы наконец начал и попытался решить эту проблему.

@mheese, я бы сказал,

@mheese Я буду сотрудничать с пиаром, если хочешь?

@mheese Похоже, что gid взято из SecurityContext, поэтому я думаю, для быстрого облегчения было бы достаточно реализации uid . Также потому, что gid высказал больше предположений во время обсуждения.

такая же проблема с psql здесь

@ michalpiasecki1 Посмотри, как я решил это с помощью PostStart -hook: https://github.com/xoe-labs/odoo-operator/blob/1be88b67d4ded5c4a0aea6e26b711241f0d09f89/pkg/controller/odoocluster86 / odoocluster

столкнулся с той же проблемой. есть ли какое-либо рекомендуемое решение для этого?

@blaggacao : спасибо за подсказку, но я нашел другой обходной путь
@debianmaster : я бы порекомендовал securityContext и fsGroup, как описано в https://kubernetes.io/docs/tasks/configure-pod-container/security-context/

Я закончил сертификаты, принадлежащие root, и группу postgres с разрешениями 440

@ michalpiasecki1, не могли бы вы дать больше информации о том, как вы решили эту

У меня есть файлы server.crt и server.key, хранящиеся в секрете k8s pg-certs-secret и я хочу смонтировать их в свой контейнер с запущенным postgres:9.6 . У меня это настроено с помощью:

      containers:
      - name: pg
         image: postgres:9.6
         ...
         volumeMounts:
         - name: pg-certs
            mountPath: "/etc/certs/"
            readOnly: true
            args: ["-c", "ssl=on", "-c", "ssl_cert_file=/etc/certs/server.crt", "-c", "ssl_key_file=/etc/certs/server.key"]
      volumes:
        - name: pg-certs
           secret:
           secretName: pg-certs-secret
           defaultMode: 384

Но при его развертывании контейнер умирает с ошибкой FATAL: could not load server certificate file "/etc/certs/pg_server.crt": Permission denied

Я предполагаю, что это связано с тем, что сертификаты загружены так, что они принадлежат root , тогда как они должны принадлежать postgres . Из документации и т. Д. Неясно, что мне делать, чтобы сменить владельца без создания собственного образа Docker, но я бы предпочел этого не делать. Похоже, что предложенные вами securityContext и fsGroup могут сработать, но я был бы признателен, если бы вы поделились дополнительной информацией о том, как именно вы этого добились.

Также стоит отметить: я добавил defaultMode: 384 чтобы файлы были добавлены с разрешениями 0600 . До того, как я это добавил, контейнер умер с ошибкой

FATAL:  private key file "/etc/certs/pg_server.key" has group or world access
DETAIL:  File must have permissions u=rw (0600) or less if owned by the database user, or permissions u=rw,g=r (0640) or less if owned by root.

Для справки, я только что понял это, и это сработало, когда я добавил

     securityContext:
        fsGroup: 999

к спец.

У меня такая же проблема №72085
Может кто-нибудь мне помочь

@izgeri я попробовал ссылку
но не работает, ты можешь мне помочь?

Есть ли шанс исправить эту проблему? Ребята из Kubernetes работают над решением?

Этот вопрос не был для нас проблемой очень давно. Мы устанавливаем "fsGroup" в контексте безопасности модуля, чтобы он соответствовал идентификатору группы пользователя, который запускает основную точку входа Docker, и любые тома в модуле становятся доступными для основного процесса этого контейнера:

https://kubernetes.io/docs/tasks/configure-pod-container/security-context/

Обратите внимание, что правильный идентификатор группы будет зависеть от того, как создается и запускается контейнер Docker. Я обычно проверяю это, вставляя kubectl exec в модуль оболочки и набирая id -g

@ charles-crain: Ваше предложение действительно хорошо работает в большинстве случаев.

Вот еще один случай, который не рассматривается:

Если контейнер запускается как root, но использует такой инструмент, как gosu чтобы стать другим пользователем (для некоторых процессов).

Затем блокировка контейнера только в одной группе с помощью fsGroup предотвратит такие случаи, как «Я хочу, чтобы мой пользователь без полномочий root имел доступ к SSH-ключам, установленным в его каталог ~/.ssh , в то время как мой пользователь root имеет доступ к другим средствам монтирования. тоже".

Один из примеров этого: «контейнер DinD, в котором dockerd должен запускаться от имени пользователя root, но последующие контейнеры запускаются пользователем без полномочий root».

Привет, @ charles-crain, я столкнулся с очень интересной проблемой, которая соответствует теме этой ветки. Кажется, что fsGroup работает не во всех случаях,
вот пример развертывания, это тестовое развертывание nginx, я пытаюсь смонтировать nfs и дополнительно смонтировать пустой каталог - просто для сравнения.
apiVersion: apps/v1 kind: Deployment metadata: name: nginx-test labels: app: nginx-test spec: selector: matchLabels: app: nginx-test strategy: type: Recreate template: metadata: labels: app: nginx-test spec: securityContext: fsGroup: 2000 volumes: - name: nfs-volume nfs: server: # nfs with no_root_squash path: /nfs - name: test-fs-group emptyDir: {} containers: - image: nginx name: nginx-test imagePullPolicy: Always volumeMounts: - name: nfs-volume mountPath: /var/local/test5 - name: test-fs-group mountPath: /var/local/test6
когда я выполняю bash в контейнере nginx пода, GID применяется только к пустому каталогу, а не к каталогу, установленному для nfs. Nfs настроен без корневого сквоша в целях тестирования, процесс в моем контейнере имеет пользователя без полномочий root, так что это проблема, ее можно решить с помощью chown, однако я пытаюсь добиться этого с помощью собственного решения

Я также сталкиваюсь с той же проблемой, описанной выше.

этот выпуск открыт уже 5 лет. никто из kubernetes не заинтересован в этом, и это может быть по какой-то причине, действительной или нет. Было много верных решений этой простой проблемы, но ни одно из них не было реализовано.

Не уверен, почему эта проблема просто не закрывается

Помогите поговорить с компом.

В пн, 18 февраля 2019 г., 12:44 Эркин Хайдаров < [email protected]
написал:

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

Не уверен, почему эта проблема просто не закрывается

-
Вы получаете это, потому что подписаны на эту ветку.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/kubernetes/kubernetes/issues/2630#issuecomment-464824407 ,
или отключить поток
https://github.com/notifications/unsubscribe-auth/Atif5VY8mSFL1QRED9HS2oRbV3qyhPQ4ks5vOuZngaJpZM4DBDWs
.

@mheese Как вы прокомментировали здесь https://github.com/kubernetes/kubernetes/issues/2630#issuecomment -424876108, чтобы установить uid и gid для тома, вы все еще пытаетесь над этим работать? Спасибо!

Я тоже столкнулся с этой проблемой. Есть ли какой-нибудь план по созданию жизнеспособного решения для этого? Локальные постоянные тома не могут заменить все варианты использования тома hostPath

То же самое.

@ jingxu97 Я еще не пробовал, потому что я действительно не чувствую, что существует консенсус, что это то, что нужно делать.

Позвольте мне составить подробное предложение и опубликовать его здесь, когда оно будет готово.

Ok

Для справки, я только что понял это, и это сработало, когда я добавил

     securityContext:
        fsGroup: 999

к спец.

Для postgres:11.1-alpine используйте это:

securityContext:
  fsGroup: 70

Я просто могу надеяться, что участники kubernetes уделяют этому вопросу первостепенное внимание. ИМО, это действительно блокиратор, особенно с точки зрения безопасности и риск возникновения уязвимостей: '(

долгосрочная проблема (примечание для себя)

Я нажимаю на это в контексте секретов, управляемых менеджером сертификатов. Я использовал initContainer, чтобы скопировать сертификаты в нужное место и обновить разрешения. Cert-manager должен обновить секреты на месте, чтобы этот трюк не сработал. Я исследую обходной путь fsGroup.

@ incubus8
Я пытаюсь работать над этим вопросом. Не могли бы вы описать свой вариант использования и какого поведения вы ожидаете? Спасибо!

@ jingxu97 Я могу предложить два примера. Образ докера Prometheus запускает службу prometheus от имени пользователя nobody (uid 65534), а образ докера Grafana запускает Grafana как uid = 472 (https://grafana.com/docs/installation/docker/)

Оба они не могут создать каталоги при первом запуске из-за этих разрешений. Я работал над этим в своей настройке с помощью initContainer который создает необходимые каталоги и chown s соответственно.

@ ford-prefect, если вы установите fsGroup в PodSecurityContext и runAsUser, разве у этих служб не будет разрешения на запись?

нет, потому что разрешения установлены для модуля, а не для тома, который был создан независимо. было бы здорово, если бы PodSecurityContext мог фактически изменить разрешения томов или, по крайней мере, не смонтировать и выдать ошибку

@ekhaydarov , в текущей функции setVolumeOwnerrhsip, если предоставляется fsGroup, у нее будет разрешение rw-rw ----, так что эта группа имеет разрешение rw. И когда контейнер запущен, он настроит дополнительную группу, чтобы он мог читать и писать на том. Что-то мне не хватает?

@ jingxu97 это не всегда решение, например: мы используем секреты для jmxremote.password и jmxremote.user, которые необходимы для jmxmonitoring java-приложений, java требует, чтобы эти файлы принадлежали пользователю, который запускает приложение te и имеет разрешения 400 , поэтому в настоящее время нет возможности использовать секреты таким образом в ранчо 2.x

Я был озадачен, увидев, что fsGroup был вариантом, а fsUser - нет.
Кроме того, сбивает с толку часть разрешений / режима. Мы должны прояснить, как тома, такие как EmptyDir, получают свой режим по умолчанию или позволяют пользователю устанавливать его явно, поскольку это довольно обычная задача администратора unix.

Если root - единственный пользователь, который когда-либо может владеть вашим томом (помимо использования initContainer для его изменения во время выполнения), API поощряет использование root для пользователя приложения, что является слабой практикой безопасности.

@ jingxu97 Что ты думаешь?

@stealthybox , спасибо за отзыв. В настоящее время я работаю над предложением по API, касающимся корпоративного владения и разрешения, и скоро поделюсь с сообществом. Отзывы / комментарии приветствуются.

Привет.

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

Почему pv.beta.kubernetes.io/gid не работает для локального провайдера пути к хосту?

Привет,

Я тоже с этим сталкиваюсь, буду благодарен за новости :).

это был мой обходной путь:
initContainers: - name: init image: busybox:latest command: ['/bin/chown', 'nobody:nogroup', '/<my dir>'] volumeMounts: - name: data mountPath: /<my dir>

это был мой обходной путь:

      - name: init
        image: busybox:latest
        command: ['/bin/chown', 'nobody:nogroup', '/<my dir>']
        volumeMounts:
        - name: data
          mountPath: /<my dir>

К сожалению, обходные пути с chown ing не работают для томов только для чтения, таких как секретные монтирования.

Мне это тоже понадобится (довольно срочно), потому что у нас есть программное обеспечение, которое не запускается из-за того, что разрешения не могут отличаться от 0600 . Если мы сможем смонтировать том под определенным UID, моя (и не только) проблема будет решена.

Вы можете запустить задание как часть своего развертывания, чтобы обновить разрешения тома и использовать состояние готовности для проверки разрешения на запись в качестве временного решения. Или вы можете использовать fsGroup, чтобы указать группу для тома и добавить пользователя приложения в группу, которой принадлежит том. Вариант 2 мне кажется чище. Раньше я использовал вариант 1, но теперь я использую вариант 2.

Обратите внимание, что если Kubernetes действительно поддерживает опцию fsUser , то вы перейдете через https://github.com/kubernetes/kubernetes/issues/57923, где всем файлам в установленном секрете будет предоставлено 0440 permission (или 0660 для монтирования с возможностью записи) и игнорирует любую другую конфигурацию.

@woodcockjosh fsGroup не распространяется на вариант использования чувствительного к безопасности программного обеспечения, такого как Vault, пытающегося работать как vault:vault и загрузки файла закрытого ключа, требующего разрешений, равных или меньших 0600 . @wjam fsUser было бы идеально, если бы мы могли также установить разрешения 0400 (для таких вещей, как файлы закрытых ключей).

Мы достигли этого, пытаясь настроить Vault для аутентификации в базе данных PostgreSQL с помощью сертификатов. Базовая библиотека Go не работает, если биты разрешений различаются (https://github.com/lib/pq/blob/90697d60dd844d5ef6ff15135d0203f65d2f53b8/ssl_permissions.go#L17).

@ jingxu97 : Есть какие-нибудь новости по этому

Эта статья выглядит как работающая, я не тестировал ее, но я протестирую ее в понедельник, если кто-то может это сделать b4, то сообщите нам об этом.
Подробности здесь
Сохранение данных настраивается с использованием постоянных томов. Из-за того, что Kubernetes монтирует эти тома с пользователем root в качестве владельца, некорневые контейнеры не имеют разрешений на запись в постоянный каталог.

Вот некоторые вещи, которые мы можем сделать, чтобы решить эти проблемы с разрешениями:

Используйте init-контейнер, чтобы изменить разрешения тома перед его монтированием в некорневой контейнер. Пример:
`` ''
спецификация:
initContainers:
- имя: том-разрешения
изображение: busybox
команда: ['sh', '-c', 'chmod -R g + rwX / bitnami']
объем
- mountPath: / bitnami
имя: nginx-data
контейнеры:
- изображение: bitnami / nginx: latest
имя: nginx
объем
- mountPath: / bitnami
имя: nginx-data

Use Pod Security Policies to specify the user ID and the FSGroup that will own the pod volumes. (Recommended)
  ```
    spec:
        securityContext:
          runAsUser: 1001
          fsGroup: 1001
        containers:
        - image: bitnami/nginx:latest
          name: nginx
          volumeMounts:
          - mountPath: /bitnami
            name: nginx-data

Привет,
Я видел по всему Интернету обходной путь с этим слабым initContainer, работающим от имени пользователя root.
Я также боролся с fsGroup, которые применяются только к области действия модуля, а не к каждому контейнеру в модуле, что [также] досадно.
Просто создайте собственный образ (nonroot-initContainer) на основе alpine, с установленным sudo и настраиваемым / etc / sudoers, дающим моему пользователю без полномочий root полную возможность применять действия chmod. К сожалению, я наткнулся на другую стену:

sudo: effective uid is not 0, is /usr/bin/sudo on a file system with the 'nosuid' \
option set or an NFS file system without root privileges?

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

Заранее спасибо !

Есть ли fsGroup для файлов развертывания Kubernetes?

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

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

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

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

👍

Это все еще проблема? Я провел несколько тестов (Minikube 1.14, 1.15, 1.19 и EKS 1.14), и разрешения для тома emptyDir равны 777, как и предполагалось:

apiVersion: v1
kind: Pod
metadata:
  name: debug
  namespace: default
spec:
  containers:
  - image: python:2.7.18-slim
    command: [ "tail", "-f" ]
    imagePullPolicy: Always
    name: debug
    volumeMounts:
    - mountPath: /var/log/test-dir
      name: sample-volume
  volumes:
  - emptyDir:
      sizeLimit: 10M
    name: sample-volume

Запись файлов в каталог работает с любым пользователем, как и ожидалось.