Код контроллера доступа находится на рассмотрении: https://github.com/kubernetes/kubernetes/pull/24600 .

Эта функция переходит прямо в бета-версию, поскольку она была первоначально представлена ​​​​в OpenShift.

По умолчанию он будет отключен в kubernetes/kubernetes#24600. После этого нам нужны изменения в контроллере доступа, чтобы связать PSP с пользователями.

Отмечая https://github.com/kubernetes/kubernetes/pull/20573 как зависимость для следующего шага на PSP (доступ на уровне темы)

Каков статус этого? Описание в первом комментарии актуально?

Актуально ли описание в первом комментарии?

нет (у меня нет прав на обновление). Я считаю, что все требования альфа-версии были выполнены. Первоначальные типы, API и тесты были объединены. Контроллер допуска не включен по умолчанию.

IMO оставшаяся работа для бета/1.4 — это интеграция авторизации для разрешений, обновление для новых полей, которые мы хотим ограничить (seccomp — в процессе, sysctl), и любые необходимые документы/учебники.

И тест e2e.

Во вторник, 12 июля 2016 г., в 6:23, Пол Вейл, [email protected] , написал:

Актуально ли описание в первом комментарии?

нет (у меня нет прав на обновление). я верю всем альфам
требования выполнены. Начальные типы, API и тесты были
объединены. Контроллер допуска не включен по умолчанию.

IMO оставшаяся работа для бета/1.4 - это интеграция авторизации для разрешений,
обновление для новых полей, которые мы хотим ограничить (seccomp - в процессе,
sysctl) и любые необходимые документы/руководства.

—
Вы получаете это, потому что вы создали тему.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/kubernetes/features/issues/5#issuecomment-232045429 ,
или заглушить тему
https://github.com/notifications/unsubscribe/AHuudqFwephlYk0Y1PS77y0xxA5QW0_-ks5qU5U7gaJpZM4IaU8n
.

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

@therc это должно быть сделано через ServiceAccount.

@goltermann Я заметил, что это было отмечено альфа-версией, но я полагаю, что для этого, вероятно, нужен тег бета-версии на основе https://github.com/kubernetes/features/issues/5#issuecomment -217939650

@erictune правильно ли звучит бета-версия, судя по комментарию @pweil-?

@goltermann Я думаю, что технически это была бы бета-версия 1.3, она не нова для 1.4, хотя разработка продолжается.

Да, бета правильная. Я был неправ, когда сегодня сказал "альфа".

отлично, исправил

@pweil- Документы готовы? Обновите документы до https://github.com/kubernetes/kubernetes.github.io , а затем добавьте номера PR и установите флажок «Документы» в описании проблемы.

@janetkuo документы PR https://github.com/kubernetes/kubernetes.github.io/pull/1150

редактировать: https://github.com/kubernetes/kubernetes.github.io/pull/1206 - правильный 1.4 PR

копия @kubernetes/feature-reviewers

@pweil- Я полагаю, этот PR актуален - https://github.com/kubernetes/kubernetes.github.io/pull/1206?

правильный

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

Предотвратите автоматическое закрытие задач с помощью комментария /lifecycle frozen .

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

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

в версии 1.10 ведется работа по перемещению PSP в группу API без расширений.
копия @php-кодер

Обновление документа @erictune , пожалуйста? См. также [таблицу отслеживания функций 1.10[(https://docs.google.com/spreadsheets/d/17bZrKTk8dOx5nomLrD1-93uBfajK5JS-v1o-nCLJmzE/edit#gid=0). лк если есть вопросы. Нам нужно, чтобы документация по связям с общественностью была рассмотрена и объединена к 9 марта. Спасибо!

@php-кодер ^

@Bradamant3 @liggitt Какие обновления документов требуются?

Для изменений, связанных с переходом группы API, я отправил: https://github.com/kubernetes/website/pull/7562 , https://github.com/kubernetes/examples/pull/206 и https:/ /github.com/kubernetes/examples/pull/208

Я не являюсь владельцем обновлений PSP Doc.

В пт, 02 марта 2018 г., 11:26, Вячеслав Семушин <
уведомления@github.com> написал:

@Bradamant3 https://github.com/bradamant3 @liggitt
https://github.com/liggitt Какие обновления документов требуются?

Для изменений, связанных с переходом группы API, я отправил:
kubernetes/веб-сайт#7562 https://github.com/kubernetes/веб-сайт/pull/7562 ,
kubernetes/examples#206 https://github.com/kubernetes/examples/pull/206 ,
и кубернеты/примеры#208
https://github.com/kubernetes/examples/pull/208

—
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/kubernetes/features/issues/5#issuecomment-370026485 ,
или заглушить тему
https://github.com/notifications/unsubscribe-auth/AHuudtBCup17Kt91pqJzBRpKWStoXUt-ks5taZzcgaJpZM4IaU8n
.

Это все, что нам нужно. Я добавил PR в таблицу отслеживания. Спасибо!

@php-coder @liggitt @tallclair
Есть планы на это в 1.11?

Если да, не могли бы вы убедиться, что эта функция обновлена ​​с помощью соответствующего:

• Описание
• Веха
• Правопреемник (и)
• Ярлыки:
  
  
  
  • stage/{alpha,beta,stable}
  
  
  • sig/*
  
  
  • kind/feature
  
  

копия @idvoretskyi

@php-coder Можете ли вы ответить на комментарий @justaugustus о работе, которую вы здесь делаете? Есть ли какие-либо изменения, кроме перемещения группы политик?

Есть ли какие-либо изменения, кроме перемещения группы политик?

Нет, я работал только над этим.

Я надеюсь, что @liggitt обновит описание, когда у него будет время (потому что у меня нет соответствующих разрешений).

Сделанный.

@tallclair просто чтобы уточнить, мы отслеживаем стабильную версию как цель для 1.11, верно?
Я обновил этикетку, просто хочу убедиться.

Нет, это все еще будет бета. Я не уверен, что PodSecurityPolicy когда-нибудь перейдет в стабильную версию (т.е. будет заменен чем-то другим), но другие могут не согласиться со мной по этому поводу.

Понятно. Спасибо за обновление, @tallclair!

@justaugustus Я

Обновления для 1.12 не запланированы

@tallclair Возможно, я смогу получить ручки RunAsGroup для PSP в версии 1.12.

Подтвердить Это все еще будет в бета-версии. На данный момент нет планов по переходу PSP в GA. Есть несколько серьезных проблем с удобством использования, которые необходимо решить, прежде чем мы приступим к этому. (см. https://github.com/kubernetes/kubernetes/issues/60001 и https://github.com/kubernetes/kubernetes/issues/56174)

/отменить назначение

/assign @tallclair

Привет
Это улучшение уже отслеживалось ранее, поэтому мы хотели бы проверить, есть ли какие-либо планы по выпуску этапов в Kubernetes 1.13. Этот выпуск нацелен на то, чтобы быть более «стабильным» и иметь агрессивные сроки. Включайте это улучшение только в том случае, если есть высокая степень уверенности в том, что оно уложится в следующие сроки:

• Документы (открытые PR-заполнители): 8 11
• Код Слякоть: 11/9
• Начало заморозки кода: 15 ноября
• Документы завершены и проверены: 27 ноября

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

Спасибо!

Никаких изменений в 1.13 не планируется.

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

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

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

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

@tallclair Привет. Я руковожу усовершенствованием версии 1.14 и проверяю эту проблему, чтобы узнать, какая работа (если таковая имеется) запланирована для выпуска версии 1.14. Заморозка улучшений 29 января, и я хочу напомнить, что все улучшения должны иметь KEP

Ничего не запланировано на 1.14.

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

Прежде чем мы сможем перейти к GA, нам нужно исправить следующие проблемы:

1. Несовершенная модель авторизации — использование PSP предоставляется через RBAC и может быть предоставлено либо пользователю, либо созданному модулю. Предоставление его пользователю является интуитивно понятным подходом, но проблематичным (см. объяснение). Этот подход также имеет некоторые проблемы с безопасностью.
2. Сложность развертывания . Поскольку модули по умолчанию отклоняются, мы не можем развернуть PSP на всех кластерах, не сломав их. Точно так же пользователи, которые хотели бы включить PSP, должны обеспечить полное покрытие всех рабочих нагрузок, прежде чем они смогут включить его, что затрудняет включение (отсюда и относительно низкий уровень использования). Поскольку эта функция должна быть включена явно, у нас нет адекватного тестового покрытия (матрица функций слишком сложна).
3. Непоследовательный API . Менее фундаментальная проблема, но эволюция PSP API на протяжении долгого периода выпусков k8s привела к ряду несоответствий, затрудняющих его использование. В частности, мутация объединяется с проверкой, что может привести к неожиданным результатам, когда модуль имеет доступ к нескольким PSP.

@liggitt и у меня есть некоторые идеи о том, как решить эту проблему, но остается открытым вопрос о том, относится ли это к ядру Kubernetes. Я хотел бы иметь дорожную карту в следующем месяце, либо план перехода к GA, либо план устаревания.

Спасибо за обмен информацией!

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

Думаю, это не совсем то. Мы сделали это, создав PodSecurityPolicy, который сначала был достаточно открытым (или даже открывал все), а затем постепенно дорабатывали его.

@ zhouhaibing089 пользователь Kubrenetes может использовать этот метод, который работает, потому что они контролируют политики. Однако мы не можем развернуть это как стандартное решение Kubernetes, поскольку PodSecurityPolicy только открывает кластер, а это означает, что очень сложно управлять PSP, контролируемым системой.

Здравствуйте, @liggitt @tallclair , я руководитель отдела усовершенствования версии 1.15. Будет ли эта функция выходить из альфа-/бета-/стабильной стадии в версии 1.15? Пожалуйста, дайте мне знать, чтобы его можно было правильно отследить и добавить в электронную таблицу. Предложение сообщества необходимо будет перенести в KEP для включения в версию 1.15.

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

Никаких изменений в 1.15 не планируется

@tallclair Очень хотелось бы увидеть эту землю как GA в 1.16. Это возможно?

@ lachie83 Нет, мы не уверены, что хотим, чтобы PodSecurityPolicy перешел в GA. Неясно, должен ли этот вариант использования решаться ядром Kubernetes, и мы рассматриваем альтернативы вне ядра. Если вы хотите обсудить это более подробно, это хорошая тема для SIG-Auth.

@tallclair Будут ли такие вещи, как привратник Open Policy Agent, лучшим путем, чтобы спуститься вниз?

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

Единственное, чего я ждал, — это инструмент, который потенциально мог бы переводить политику PodSecurityPolicy --> OPA rego. Это значительно облегчило бы их осуждение с вашей точки зрения.

@tallclair ценю быстрый ответ

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

Привет, @tallclair , ты упомянул дорожную карту для GA или план прекращения поддержки. Похоже, мы склоняемся к последнему.

Есть ли у нас что-то написанное, чтобы помочь людям, которые рассматривают PSP как решение, замкнуть круг?

Еще нет. Частично сомнения заключаются в том, что мы не хотим говорить, что откажемся от него в пользу чего-то другого, пока не будет четкой замены. Хотя я в восторге от привратника, у него пока нет тех функций (или стабильности), которые нам нужны для замены PSP. Другая возможность заключается в том, что мы могли бы переместить PSP из дерева и перенести его в GA в качестве веб-перехватчика доступа (эти два варианта не исключают друг друга). Мы еще официально не разработали дорожную карту.

Втф

Привет , @tallclair , похоже, здесь ничего не происходит и с 1.16, поэтому я оставлю все как есть.

Привет, @tallclair -- здесь руководство по улучшению 1.17 -- похоже, что для версии 1.17 все останется как есть. Если это изменится, пожалуйста, не стесняйтесь, ткните меня, и я могу добавить его в лист отслеживания 👍

Было ли еще какое-нибудь обсуждение ясного пути для будущего PSP?

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

@tallclair — большинство проверок PSP мы реализовали в Kyverno. Можешь помочь взглянуть? Хотелось бы обсудить идеи и детали.

https://github.com/nirmata/kyverno/blob/master/samples/README.md

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

копия @maxsmythe @sozercan @tsandall

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

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

@tallclair, один из вариантов использования, который мы рассматриваем, связан с мультиарендностью на основе пространства имен. Цель состоит в том, чтобы использовать политики для обеспечения соблюдения ограничений и обеспечения правильной настройки пространств имен.

Прежде чем мы сможем перейти к GA, нам нужно исправить следующие проблемы:

1. Несовершенная модель авторизации — использование PSP предоставляется через RBAC и может быть предоставлено либо пользователю, либо созданному модулю. Предоставление его пользователю является интуитивно понятным подходом, но проблематичным (см. объяснение). Этот подход также имеет некоторые проблемы с безопасностью.

@tallclair , меня интересует вышеизложенное - можете ли вы уточнить, почему этот подход проблематичен и / или имеет проблемы с безопасностью?

Может кто-то более информированный, пожалуйста, подтвердите этот твит:

https://twitter.com/TechJournalist/status/1197658440040165377

И если это правда, что должны делать люди, использующие PSP для ограничения возможностей Linux сегодня в будущем?

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

Мы рассмотрели как OPA Gatekeeper, так и PodSecurityPolicies, а также усилия по повторной реализации PSP в ограничениях OPA.
Фундаментальная проблема, которую мы обнаружили при этом сравнении, заключается в том, что мы имеем дело с двумя противоположными моделями.

• OPA Gatekeeper следует модели открытого по умолчанию, в которой все разрешено, а администратор запрещает определенные вещи с ограничениями.
• PSP следует закрытой по умолчанию модели, в которой все запрещено, а администратор разрешает определенные вещи с помощью политик.

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

Как вы планируете преодолеть этот фундаментальный разрыв в архитектуре между PSP и Constraint Framework?

/cc @ritazh Я хотел бы услышать ваше мнение по этому поводу, так как вы работали над переносом функций PSP на OPA.

Различные подходы определенно усложняют миграцию. Мы изучаем различные способы сделать переход более плавным.

Я согласен, что в идеальном мире отказ от всего по умолчанию является более безопасным подходом. Тем не менее, это одна из вещей, которая делает PSP такой сложной в использовании и развертывании. На практике я думаю, что постепенное снижение разрешений более осуществимо, и, как гласит старая поговорка, «лучшая безопасность — это безопасность, которую вы используете».

Кроме того, мы также обсуждаем, как отказаться / исключить / получить исключения из ограничений (например, для защиты пространства имен kube-system). В зависимости от того, как это работает, вы можете реализовать подход «запрет по умолчанию», блокируя все, а затем предоставляя исключения. Я не уверен, что это вариант использования, для которого мы хотим разработать дизайн...

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

Никаких изменений в 1.18 не запланировано

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

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

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

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

@tallclair Привет, Тим. Есть планы на это в 1.19?

Планов на версию 1.19 нет, хотя я надеюсь увидеть какое-то движение во временных рамках версии 1.20.

Только что наткнулся на Kubernetes Pod Security Policies с Open Policy Agent . @tallclair , можете ли вы поделиться тем, что нам мешает и где нужна помощь, я тоже рад внести свой вклад.

Вы можете поделиться тем, что нам мешает?

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

1. Нет замены — рекомендуем выбрать сторонний вариант с веб-перехватчиком допуска. Недавно опубликованный документ по стандартам безопасности Pod пытается сделать это более плавным, продвигая эквивалентную функциональность.
2. Альтернативные встроенные элементы управления
   
   
   
   1. @deads2k предложил поднимать вверх openshifts SecurityContextConstraints
   
   
   2. Я предложил минимально настраиваемую функцию, которая применяет только стандартные политики, указанные выше (и рекомендую стороннее решение, когда требуется больше возможностей настройки)
   
   
3. Исправление политики безопасности модуля. Хотя некоторые из проблем являются достаточно важными для дизайна, это должно быть несовместимо с предыдущими версиями, и в этот момент это также может быть новой альтернативой в (2)

Правильно ли я читаю https://github.com/kubernetes/kubernetes/pull/90603 , что, поскольку стандарты безопасности pod опубликованы, нет запланированной замены PSP на сервере API, и любая замена должна быть реализована как внешняя система?

См. https://github.com/kubernetes/enhancements/issues/5#issuecomment-637066475 .

График устаревания текущей бета-версии в 1.22 не зависит от того, будет ли предоставляться реализация стандартных профилей безопасности модулей в дереве. Это еще не определено.

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

График устаревания не относится к PSP и был добавлен как часть https://github.com/kubernetes/enhancements/tree/master/keps/sig-architecture/1635-prevent-permabeta .

если я правильно понимаю, что подталкивает к устареванию, так это то, что ни один API не должен находиться в одной и той же бета-версии более 9 месяцев, поэтому PSP необходимо продвигать или устареть, и поскольку не будет никаких новых бета-версий или GA PSP. он должен встать на путь устаревания, даже если решение о замене еще не принято?

если я правильно понимаю, что подталкивает к устареванию, так это то, что ни один API не должен находиться в одной и той же бета-версии более 9 месяцев.

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

Привет @tallclair

Улучшения ведут сюда. Есть планы на это в 1.20?

Спасибо,
Кирстен

Нет планов на v1.20.

Эта ситуация чрезвычайно расстраивает тех из нас, кому необходимо запускать кластеры с высоким уровнем безопасности. Наши варианты:

1. Сиди и жди, когда PSP устарят.
2. Передайте обеспечение безопасности во время выполнения рабочей нагрузки поставщику (Styra), поскольку OPA не документирует, как запустить полностью ограничительную замену PSP с помощью Rego.

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

ИМО, бета-версия PSP должна быть объединена с основным ядром kubernetes. Мои причины:

1. Хотя у PSP есть недостатки, они работают и работают уже 10 выпусков.
2. Kubernetes как проект должен заботиться о безопасности выполнения рабочих нагрузок. Побег из контейнера слишком прост. PSP — один из немногих инструментов, усложняющих задачу злоумышленникам.
3. Идеальное — враг Готового. Объедините PSP как есть и отложите «лучшую» реализацию в policy/v2.
4. Наконец, что наиболее важно, это позволяет разработчикам OSS запускать кластеры с более высоким уровнем безопасности, а не только компаниям, которые могут позволить себе таких поставщиков, как Styra.

@ zapman449 , не могли бы вы уточнить, что вы подразумеваете под «полностью ограничительной заменой PSP»?

Надеемся, что библиотека Gatekeeper PSP упрощает применение правил, аналогичных тем, которые используются в PSP. Меня определенно интересуют любые функциональные пробелы, которые вы видите.

@ zapman449 у тебя случайно нет ссылки на этот пост в блоге?

@christianhuening https://developer.squareup.com/blog/kubernetes-pod-security-policies

@maxsmythe Я еще не проверю .

Однако я имею в виду следующее:

1. Полный контроль над возможностями процессов, такими как NET_BIND_SERVICE, SYS_ADMIN и т. д.
2. Ограничить UID/GID/FSGroups ненулевыми значениями
3. Явный список путей хоста, которые могут быть смонтированы
4. Явный список разрешенных типов монтирования томов
5. Блокировка привилегий, блокировка повышения привилегий
6. Блокировать доступ к примитивам межпроцессного взаимодействия на уровне хоста
7. Заблокировать доступ к хост-сети
8. ограничить разрешенные хост-порты
9. Принудительно использовать readOnlyRootFilesystem
10. Точка подключения для SELinux

Они предоставляются сегодня с PSP.

Если мы просим список желаний, мне бы хотелось:

1. Умные значения по умолчанию для SysCalls из контейнеров. Существует небольшой процент от общего списка системных вызовов Linux, который необходим большинству контейнеров. Позвольте мне ограничить большинство контейнеров этим списком, а затем разрешить мне явно разрешать определенные вызовы для определенных модулей, принадлежащих определенным учетным записям служб, или предоставлять карт-бланш определенным учетным записям служб.
2. Дайте мне еще немного помечтать, и я что-нибудь придумаю. ;-)

@zapman449. Если вы еще не видели, мы обсуждали будущее PSP на последнем собрании по подписке (https://docs.google.com/document/d/1woLGRoONE3EBVx-wTb4pvp4CI7tmLZ6lS26VTbosLKM/view#heading=h.hsgtsqg83z5u). ). Мы продолжим обсуждение на собрании 9 декабря, если вы сможете это сделать, но мы также не будем принимать никаких окончательных решений, пока предложение не будет отправлено в список рассылки.

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