Комментарии 14
Одна проблема есть. Раньше в прометеус оператора это решение Kube-RBAC-Proxy было встроено. Но его потом не стало. Сейчас современные версии опираются на то, что у вас есть network policу и закрываете с помощью них
Да нет, вот же он — https://github.com/coreos/kube-prometheus/blob/master/jsonnet/kube-prometheus/kube-state-metrics/kube-state-metrics.libsonnet#L18
Отличный обзор из категории "вредные советы". Точнее — как делать не надо и как себя обезопасить. К сожалению, я подозреваю, что это только верхушка айсберга. И наверняка там под капотом еще куча более хитрых способов положить кластер. Какое может быть решение? Ну, или контроль. Или может быть просто из кластера не делать коммуналку? Каждому проекту по своему кластеру? Это не снимает вопросы ИБ, но по крайне мере снижает влияние пользователей-проектов друг на друга.
Еще очень интересно Ваше отношение к опеншифту. Поясню. Дело в том, что, насколько мне известно, опеншифту форсит правильные стратегии вроде "не используйте рута в контейнерах", маппит польщователей докера в рандомные на хосте, форсит psp и сетевую изоляцию… И пр. А раз так, то нужно сразу учиться с этис жить. Это больно. Никто не спорит. Зато потом за продакшен можно не беспокоиться. Потому что если заходить с другого конца — вообще ванильный кластер без ничего, то вроде быстро вкатываешься, но потом уже довел продукт до состояния препрод, а оказывается, что там еще очень много работы по поведению его к состоянию, в котором его можно выпускать в дикий мир (именно по соображениям иб и пр.)
Добавлю, что при работе с кубернетесом потихоньку выкристаллизовываются какие-то лучшие практики работы с ним. Например, очень круто заводить все внешние ресурсы, которые необходимы как Service внутрь неймспейса. Более того — это практически сама оф. рекомендация от гуголь. Зачем так делать? А чтобы получить наблюдаемость. Сразу видишь от каких внешних по отношению к кластеру сущностей зависит твой сервис. А в случае необходимости — ее (внешнюю сущность) можно будет затащить в кластер без каких-либо проблем.
Касательно уязвимостей — кластер, который апихой куда-либо смотрит — легко может эффективно использовать как ssh jump host внутрь корп. сети или DMZ…
1. Аутентификация компонентов кластера между собой по сертификатам.
2. Наличие понятных механизмов ротации этих самых сертификатов и никаких сертификатов на 100 лет.
3. Включенные аудит логи, настроенный их парсинг и алерты по полученным данным.
4. Наличие понятного и рабочего механизма обновления кластера и его компонентов с возможностью производить это так часто как требуется.
5. Настроенный файрвол для служебных портов кластера.
6. Включенные и настроенные сетевые политики.
7. Авторизация по RBAC, с пониманием и контролем прав в RBAC ролях.
8. Авторизация внешних пользователей в кластер через центральное юзерохранилище компании (аля LDAP) с ролями и тд + какой нибудь OAuth (аля Dex).
8. Включенные и настроенные PSP.
9. Включенные и настроенные LimitRange и ResourceQuota для всех нэймспэйсов.
10. Отдельные кластера для Dev/Stage и Prod.
11. Доступ на запуск новых абстракций только у CI, причем с четким контролем конкретных прав и нэймспэйсов для каждого проекта CI.
Это то что быстро в голову пришло. По идее этого должно хватить, чтобы ваша ИБ перестала прям уж сильно хвататься за голову. Но это все сильно прибавит работы Админам/Devops/SRE командам. Тут работает именно та диаграмма о которой я в докладе в начале говорил. Чем выше безопасность, тем ниже удобство.
А по поводу OpenShift полностью согласен. Как всегда «в опеншифт это их коробки».
Действительно там проведена огромная работа, и Кубернетис под капотом настроен по дефолту у них очень хорошо. Эти ребята читали документацию и занют о встроенных фичах Куба.
Дальше обычно следует вопрос – а почему вы не используете Опеншифт?
– Потому что я тоже читал документацию к Кубернетису и могу собрать под каждую задачу именно тот кластер, который мне нужен, а не тот который за меня преднастроил вендор, впилив сверху еще кучу своих костылей.
Дальше обычно следует вопрос – а почему вы не используете Опеншифт?
– Потому что я тоже читал документацию к Кубернетису и могу собрать под каждую задачу именно тот кластер, который мне нужен, а не тот который за меня преднастроил вендор, впилив сверху еще кучу своих костылей.
Если это про Вас или про Вашу компанию, то могу только порадоваться за Вас и Ваших клиентов. Проблема в том, что в голом виде кубернетес не очень пригоден. В том виде, в котором варят его некоторые коллеги — лучше б не варили. Сложно сказать как следует поступить потенциальным заказчикам, которые хотят уже идти в куб, но экспертизы соответствующей нет. Ведь нормальных полноценных дистрибутивов нет. Разве что жить в облаке на managed. Но там своих проблем и особенностей полно.
Кубернетис в компании это скорее всего отдельно выделенный инженер, а то и не один.
Это постоянная досборка/пересборка конструктора. Это огромная инфраструктура, которая должна сопутствовать кластеру.
Для небольшой компании, особенно исповедующей noops подходы это может стать непосильной задачей. Поэтому люди и выбирают всякие managed решения или Rancher и иже с ним (правда в последствии отгребая какие нибудь неожиданности от этих решений, которые потом не в состоянии никак починить, так как экспертизы то как не было так и нет, развернулось то все одной кнопкой).
Плюсов конечно у Куба много, но это большая сложная система. И что бы там ни писали в англоязычных блогах, как это все просто и как стартапы из двух девелоперов строят кластера на 5000 машин с rps под миллион, это все неправда. И нужно отдавать себе отчет при внедрении таких продуктов как Кубернетис. Что ты хочешь от него получить и чем придется взамен пожертвовать (например большим куском бюджета на ЗП специалисту).
Именно по этим причинам сейчас на рынке есть компании (и мы среди них) которые предлагают взять на себя все заботы по кластеру (да и вообще по инфраструктуре). Потому что такие компании могут потратить уйму времени и денег на хантинг нужных специалистов (которых правда мало). Потом могут выделить оплачиваемое время своих инженеров на чтение документации, эксперименты, написание собственных плагинов и тд. А потом этих инженеров задействовать в разных проектах, для разных клиентов. Таким образом фактически помогая рынку более эффективно использовать ограниченный ресурс в виде хороших специалистов, предоставляя их для разных задач, там где они нужны.
Например в моей практике случались моменты, когда коллеги пользовались дырками во внутренних инфраструктурах для того чтобы эффективней выполнять свою работу. Зачем писать задачу админам, если ты получил себе доступ куда не нужно было и теперь можешь по-тихому сам выполнять нужные действия.
Правда велика вероятность, что при этом такой сотрудник совершит рано или поздно какую нибудь ошибку (все таки при нормальном стечении обстоятельств изначальные ограничения были не просто так придуманы), которая в итоге может привести к очень плачевным последствиям. Хотя первоначальные цели этого «взлома» были как бы благими.
И обычно тут начинается выяснение кто и куда влез, зачем он так действовал, разборки, выговоры и увольнения. А виновата как бы система, которая предоставляла доступ куда не нужно, кому не следует, а не сотрудник.
А еще см. пример с 11 миллиардами контейнеров из доклада. Там вообще никакого умысла что то взламывать или портить не было. Систему сломал буквально несчастный случай.
Заделываем дыры в кластере Kubernetes. Доклад и расшифровка с DevOpsConf