Команда VK Cloud перевела конспект конференции InfoQ Live со специалистами мирового класса. В этот раз на ней говорили о безопасности в Kubernetes и облачных средах. Спикеры обсудили распространенные ошибки и передовые методы обеспечения безопасности кластеров Kubernetes, поговорили о том, как начать новичкам, и об инструментах, упрощающих жизнь.

Информация о спикерах

Лозио: Меня зовут Ренато Лозио. Я ведущий архитектор в компании Funambol и редактор в InfoQ. Для начала познакомимся с нашими участниками, дадим им пару минут, чтобы представиться и рассказать нашей аудитории, как они связаны с безопасностью и Kubernetes.

Нардьелло: Меня зовут Якопо Нардьелло. Я основатель и генеральный директор SIGHUP. Мы — миланский скейлап, работающий в основном в Европе. Занимаемся внедрением open source-решений Kubernetes на предприятиях, работаем с вышестоящими системами облачной среды и показываем, как эффективно использовать ее в крупных организациях. Сейчас Kubernetes переживает вторую волну популярности, и у людей возникает вопрос: «У нас уже есть кластеры, а что дальше?». Конечно, безопасность — это важная часть общей дискуссии.

Девочко: Меня зовут Кристина Девочко. Я живу в Осло (Норвегия). Трудно сказать в двух словах, чем я занимаюсь, потому что моя работа включает множество функций. Но вообще я называю себя «архитектор программного обеспечения». Я много работаю с Kubernetes и в своей сети, и когда вношу личный вклад в развитие сообщества. Прежде всего это касается сервиса Managed Kubernetes, например, Azure Kubernetes Service от Microsoft. С тех пор как я стала разработчиком, я всегда интересовалась вопросами безопасности. Когда на работе мы перешли на Kubernetes, это были кардинальные перемены. Думаю, безопасность в экосистеме Kubernetes — это чрезвычайно обширная область.

Ченетс: Я Майкл Ченетс, работаю в подразделении Outshift компании Cisco. Cisco не ограничивается только сетевыми решениями. Я вообще никак не связан с сетевым оборудованием. У нас есть облачные технологии, связанные с защитой облачных приложений, с Istio и Kafka. Я помогаю людям, которые переносят инфраструктуру в облако, людям, которые считают: «Надо взять устаревшее приложение и превратить его в микросервисы». И я должен продумать все элементы, необходимые, чтобы это приложение нормально работало. Я по специальности разработчик. Мы, разработчики, знаем, что главный акцент делается на скорости, в том смысле, что нужно, чтобы это приложение заработало сразу же. Когда вам говорят, что надо настроить микросервисы, вы не думаете о безопасности. Эта мысль приходит потом. CNCF — отличная инициатива, но в ней аж 5 000 составляющих. И вот вы думаете, как сделать так, чтобы все это работало? Как обеспечить безопасность решения? Это такой стресс.

Проблемы безопасности кластера Kubernetes

Лозио: Допустим, у меня есть кластер Kubernetes в облаке или где-то в другом месте, где он мне нужен. С точки зрения безопасности в чем вы видите основную проблему? Майкл только что отметил слишком большое количество вариантов, когда трудно решить, с чем работать. А что вы считаете основной проблемой?

Нардьелло: То, что это такая сложная тема. Что мы понимаем под безопасностью? Анализ угроз? Управление артефактами, список зависимостей программного обеспечения? Безопасность среды исполнения, управление секретами? Как мы работаем со сборками и пайплайнами? Все это проблемы. Уже не говоря о законодательной стороне дела, о сертификации. Недавно Евросоюз принял новый закон CRA, который предусматривает ответственность за недостатки open source-программ.

Девочко: Мы много слышим о сложности Kubernetes и его экосистемы. Есть отличные мемы с разработчиками, у которых вот-вот случится инфаркт, когда они смотрят инфографику про все составляющие проекта CNCF. Что выбрать?

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

Ченетс: Вот о чем я всегда думаю. Первое: действительно ли здесь нужен именно Kubernetes? В первую очередь надо думать не о платформе, а о потребностях приложения. Что нужно для вашего приложения? Составьте список вопросов. Нужны ли вам микросервисы? А если нужны, то может, вам подойдет и Wasm? Нужна ли вам избыточность? Хотите ли вы, чтобы ваши разработчики работали самостоятельно, а в конце объединили свои наработки? Возможно, вам действительно нужны микросервисы. Я не утверждаю, что это не так. Но отталкиваться в первую очередь от платформы это неверный подход в проектировании. Если вы уже приняли решение, обдумайте, как вы будете проектировать систему, чтобы обеспечить ее масштабируемость, безопасность и управляемость. 

К сожалению, на примере Log4j мы видели, что цепочка поставок — это проблема. Разработчики стремятся выбрать самый простой API, который более или менее справится с нашими задачами. Это и хорошо, и плохо одновременно. Мы не думаем о последствиях, пока они не наступят. Знаете, нечто вроде: «Приложение норм. Мы его сделали, собрали, оно работает. Я тут установил эту клевую штуку, называется Kubernetes. Все, несу в продакшн». А вот и нет. Вы подумали о последствиях? Хотя на самом деле мы не можем возлагать на разработчиков ответственность за все и считать их экспертами по безопасности. Это другая область знаний.

Начало работы с Kubernetes

Лозио: Я разработчик. Да, возможно, мне придется использовать Kubernetes. Разве это проблема для меня? В чем тут барьер для разработчика, для архитектора? Я прекрасно знаком с концепцией shift left. Якопо уже упомянул, что безопасность можно понимать совершенно по-разному. Так что должно меня беспокоить? Понимаю ли я, что прячу голову в песок? «Меня все это не волнует, безопасность — не мой фронт работ». Да, знаю, так нельзя. Какую цель видят разработчики? Я знаю, что могут наступить 10 000 разных последствий, но если я сегодня начинаю работать с Kubernetes, что мне делать как разработчику?

Нардьелло: Если мы говорим о безопасности, для разработчика абсолютный минимум — это иметь некоторое представление о примитивах Kubernetes, о RBAC, об управлении политиками. Что это значит — использовать Kubernetes безопасно? Иногда разработчику вообще не хочется знать, как он работает. Все это не его головная боль. И все же я думаю, что как разработчик вы должны иметь представление об этих базовых вещах. И еще один момент, не то чтобы непосредственно связанный с Kubernetes: важно иметь представление о своих зависимостях. Кстати, ваша операционная система — это зависимости, как и все библиотеки в ней. Да, у нас есть процессы, которые выполняются в ядре. Но, работая с контейнерами, вы как разработчик выбираете, какой базовый образ использовать. Вам нужно понимать, что вы выбираете. Да, каждый разработчик должен иметь представление о зависимостях и о базовых вещах вроде управления политиками и RBAC. Необязательно быть экспертом в других, узкоспециализированных вопросах, но хотя бы эти темы надо изучить качественно.

Девочко: Многое зависит от того, как устроены процессы в организации, как работают ваши команды. Я участвовала в проектах, в которых разработчики работали непосредственно с Kubernetes, потому что в силу разных ограничений у них не было отдельной команды по развитию платформы. В более зрелых организациях есть отдельная группа, отвечающая за эксплуатацию и администрирование кластеров Kubernetes. Разработчику важно понимать основы Kubernetes, знать, что это такое, что такое контейнеризация, технологии оркестрации. Еще важно разбираться в политиках и шлюзах, которые настраивают другие сотрудники, отвечающие за безопасность и надежность рабочих нагрузок и кластера Kubernetes. Если вы неправильно настроите конфигурацию, автоматизированные шлюзы остановят процесс — и к этому надо быть готовым. В этом случае нужно проверять, как все работает, и нести ответственность за сервис, который вы разрабатываете. Многие команды отвечают за создание контейнеризированных приложений; в этом случае они должны обеспечить защищенность образа контейнера, использовать slim-версию базового образа и т. п. Важно знать, как это делается, и поддерживать контакт с администраторами кластеров Kubernetes (если они у вас есть), — они смогут снять с вас часть когнитивной нагрузки.

Если вы начинаете работать с цепочкой поставок, с любой цепочкой поставок, не используйте wildcard-сертификаты. Не используйте latest version. В Kubernetes у вас разные кластеры, но единая база исходного программного кода, где вы определяете последнюю версию. И эти кластеры развертываются и предоставляются в разные моменты времени. Если вы используете latest version, то окажется, что после выхода нового релиза вы используете разные версии одной и той же библиотеки. Я сталкивалась с этой проблемой в Log4j, когда пытаешься разобраться, какую версию библиотеки и в каком кластере используешь. Это непросто, если вы используете latest как часть определения исходного кода. Учитывать этот нюанс и использовать конкретную версию — это простой, но важный шаг. С него и можно начать.

Ченетс: Недавно мы обсуждали это в эфире с Келси Хайтауэром. И он сказал: «Вы же не вызываете сантехника, чтобы он починил вам электрику». Мне нравится, как доходчиво он формулирует свои мысли. Действительно, самое важное — это помнить про цель. Для бизнеса главная цель проектирования приложений — это прибыль. Разработка приложения не должна отклоняться от этой цели. Да, разработчикам все-таки нужно заниматься безопасным программированием. Это значит, что нам нужно организовать другие процессы, подключить другие инструменты, чтобы создать и сохранить определенные рамки. Нужно обязательно проверять такие вещи как цепочка поставок, разного рода распространенные уязвимости и риски и так далее.

Специфические уязвимости Kubernetes

Лозио: Я полностью согласен с примером про Log4j. Как разработчик я бы сказал, что такие проблемы безопасности могут возникать не только в Kubernetes. Но в распределенной архитектуре Kubernetes они могут быть еще серьезнее. Есть ли характерные для Kubernetes уязвимости, которые специалисты по облачным решениям должны держать в поле зрения?

Ченетс: На самом деле на сайте Kubernetes представлен очень хороший обзор облачной безопасности. Они рассказывают про 4C облачной безопасности: code, container, cluster и cloud (код, контейнер, кластер и облако), про colo или корпоративные центры обработки данных. На своем сайте они рассказывают о разных конфигурациях и о том, на что нужно обращать внимание в вопросах безопасности в облаке. На самом деле все сводится к тому, что по умолчанию контейнеры и элементы Kubernetes задуманы как открытые, чтобы приложения могли нормально работать. Люди жаловались бы, что у них не работает приложение, отправляли бы намного больше тикетов, у них возникло бы гораздо больше проблем и Kubernetes внедряли бы намного хуже. По определению это по-настоящему открытое решение, и нужно много всего сделать, чтобы его «закрыть». Вот в чем все дело.

Как обеспечить безопасность кластера Kubernetes

Лозио: Да, вот в этом все дело. Человеку, который начинает знакомиться с Kubernetes, мы говорим: «Ок, все по умолчанию открыто». В каком направлении нужно сделать первые шаги, чтобы обезопасить кластер Kubernetes?

Нардьелло: При работе с Kubernetes и инструментами поверх кластера Kubernetes нужно учитывать множество аспектов. Легко сказать: «Просто используйте Managed Kubernetes, это снимет часть проблем». Но одна из проблем это как раз работа с кластерами. И здесь нужно учитывать еще столько всего.

Преимущества Managed Kubernetes по сравнению с альтернативными решениями

Лозио: В разрезе безопасности, какие преимущества вы видите в управляемом решении — AWS, Azure или Google Cloud — по сравнению с тем, чтобы все делать самому?

Нардьелло: Я эксперт по этой теме, потому что мы работаем с собственным дистрибутивом. Работа Kubernetes в локальной среде — одно из наших основных направлений. При использовании Managed Kubernetes принципиальная разница заключается в том, что вы получаете заранее заданную конфигурацию и некоторые продвинутые функции, которые провайдер предоставляет в упрощенном виде. Безусловно, это важнейшее преимущество. И все-таки надо разбираться в том, чем занимаешься. Может быть, у вас по умолчанию настроен общий доступ к панели управления. Если вы имеете дело с рабочими нагрузками продакшн-среды, так быть не должно. Еще одно важное преимущество заключается в том, что провайдер делает решение менее сложным и более доступным. Конечно, если вы работаете самостоятельно, то отвечаете за все в любой инфраструктуре, будь то экземпляры EC2, просто виртуальные машины или виртуальные машины со стороны провайдера. У всего есть достоинства и недостатки. На этот вопрос нет простого ответа.

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

• инфраструктура, включая сетевой доступ, доступ к CD;
  
• контейнеры, включая вопросы уязвимости, Image Signing, использования среды исполнения контейнера;
  
• безопасность рабочей нагрузки.
  

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

Девочко: Я вот зайду еще с точки зрения потребителя. Вам не только нужно работать со множеством вещей, включая панель управления, — а это ведь своего рода командный пункт системы. Это критически важный компонент Kubernetes. Вам нужно создать и поддерживать избыточное, отказоустойчивое, безопасное решение, ведь на него завязаны все ваши рабочие нагрузки. Для поддержки всех этих компонентов вам понадобится множество ресурсов, — вы же не хотите разорваться на части. Вам придется много чего докрутить, то есть вам понадобится больше сотрудников, чтобы подготовить решение к продакшну. Что касается Managed Kubernetes, поставщики облачных сервисов серьезно заботятся о безопасности. Они предоставляют вам готовые средства контроля, например, на уровне инфраструктуры, серверов, на которых работают ноды Kubernetes, а также саму панель управления. Это может очень пригодиться, особенно если у вас немного опыта с запуском сервиса Kubernetes в продакшн без дополнительных инструментов.

Допустим, вы разработчик или архитектор, который хотел бы разобраться в вопросах безопасности Kubernetes. Если вы задумываетесь об использовании Managed Kubernetes в облаке, в первую очередь обратите внимание на управление безопасностью, поддерживаемое поставщиком облачных сервисов для своего Managed Kubernetes. Благодаря этой информации можно понять, как кластеры настроены по умолчанию в самом начале работы. Например, в конфигурации Azure Kubernetes Service по умолчанию настроен не самый высокий уровень безопасности, потому что в целом их стратегия — позволить пользователям начать работу с сервисом быстро и без лишних сложностей. По умолчанию API-сервер включен и общедоступен. Это можно выяснить из документации, в которой для каждого уровня шаг за шагом объясняется, какие настройки заданы по умолчанию, что нужно сделать, чтобы повысить уровень безопасности, и какие ограничения это подразумевает. Если вы планируете работать с частным кластером, который доступен в частном режиме только по внутренним IP-адресам, то возникают ограничения по агентам сборки и по функционированию всего потока CI/CD. В качестве отправной точки я советую оценивать подход к управлению безопасностью. Это поможет лучше понять, что именно предлагают поставщики сервисов Managed Kubernetes.

Ченетс: Важно учитывать и человеческий фактор. Мы живем в эпоху, когда люди часто меняют работу. Сотрудник, который поддерживает эти сервисы у вас в компании, может уволиться, и вам придется искать ему замену. Если пользоваться облачным решением, это повышает шансы, что и дальше найдутся люди, способные грамотно его поддерживать. Это первое. Второе — это различия в наборе умений и навыков. Для работы с экосистемой поставщика облачных сервисов и для управления решением в локальной среде нужны разные навыки. Для соблюдения стандартов безопасности в облаке и в локальной среде нужны не совсем одинаковые знания.

Плагины или операторы Kubernetes

Лозио: Что вы думаете о плагинах Kubernetes с точки зрения безопасности? Это действительно так страшно, как все говорят?

Нардьелло: Что вы называете плагинами Kubernetes? Вы имеете в виду операторы?

Лозио: Ну да, наверное операторы.

Нардьелло: Это элементы программного обеспечения, которые используют систему на базе событий Kubernetes для работы с состояниями элементов инфраструктуры. Они очень сложные. Они могут содержать в себе произвольную сложную логику. Действительно ли это так страшно? Думаю, не так уж страшен черт, ведь Kubernetes предоставляет некий общий фреймворк и уровень логики. Вы можете встроить туда что хотите. Это просто еще одно программное обеспечение, которое вы используете в Kubernetes. Соглашусь, что это сложная тема. Несколько лет назад все просто с ума посходили по операторам, потому что они только появились, и всем казалось, что это круто. Думаю, сейчас их применение стало более зрелым. В целом это паттерн суперсилы. Они позволяют использовать цикл контрольной обратной связи Kubernetes внутри других элементов инфраструктуры. Опять же, они могут вводить некую сложную логику. Если они работают в проде, желательно, чтобы их поддержкой занимались специалисты или у вас хватало навыков, чтобы работать с ними.

Ченетс: Хочу вернуться к управлению цепочкой поставок. В конечном счете все сводится к вопросу «Из чего строится та или иная часть программы, будь то в контейнере или через API?». Если вы выполняете много операторов, значит, у вас в единой системе работает много составляющих. Это дополнительные элементы, которыми надо управлять, с разными образами и разными компонентами. Такое многообразие увеличивает площадь атаки, — не всегда, но с какой-то долей вероятности. Сто раз подумайте, точно ли вам нужен этот оператор? Мы уже говорили, что все стали с ума сходить по операторам. С Helm мы перешли на операторы, — всюду были только операторы. На самом деле надо серьезно подумать, что должно быть оператором. Какая у него функция? Вам нужно поддерживать какой-то жизненный цикл? Тогда, возможно, вам и правда нужен оператор. Но если есть более простой подход к задаче, где не нужно поддерживать жизненный цикл, то, возможно, оператор вам не нужен.

Безопасность кластера Kubernetes: передовые практики

Лозио: Я бы хотел узнать ваши рекомендации по поводу распространенных ошибок при обеспечении безопасности кластера Kubernetes. Например, что вы считаете передовыми практиками для применения принципа минимальных привилегий, управления секретами? Может быть, вы еще что-то посоветуете для безопасности кластера?

Ченетс: Я думаю, главное вот что: не давайте привилегированный доступ, если в этом нет острой необходимости. Это самое главное. Многие дают его по умолчанию, а ведь так можно открыть двери чему угодно. Обязательно используйте контроль доступа на основе ролей. Многие работают как администратор и пользователь Kubernetes по умолчанию, а так делать не стоит. Именно так люди создают себе проблемы. Не забывайте про сетевую политику для всех микросервисов: обязательно передавайте только то, что нужно. Что вы используете в качестве балансировщика нагрузки, для входящего сетевого трафика? Используете ли вы service mesh? Если да, какая у нее конфигурация? Здесь нужно учитывать множество нюансов. Правда, все сводится к принципу минимальных привилегий. Обязательно предоставляйте как можно меньше привилегий, необходимых для работы приложения. Если вы так делаете, это хорошее начало.

Девочко: Не нужно создавать широкий вектор угроз: даже если он возвращает, например, код ошибки 401 или unauthenticated, злоумышленник все равно извлекает полезную для себя информацию. Подумайте, что вы можете с этим сделать. Можете ли вы для начала ввести диапазоны IP-адресов или использовать частный кластер сам по себе? Здесь важно продвигаться шаг за шагом. Взять что-то одно, внедрить, посмотреть, как это работает и точно ли ничего не сломалось. Отбирайте самое лучшее и не пытайтесь внедрить все одновременно. В Managed Kubernetes можно использовать RBAC, которое предоставляет поставщик облачных сервисов. Это довольно удобно. В Microsoft Azure его можно интегрировать с Azure AD. Почему это хорошо? Потому что можно свести к минимуму роли и разрешения для каждого пользователя в кластере, предоставив доступ только к тому, что ему нужно для работы. Можно внедрить JIT-доступ, который вы по необходимости будете предоставлять сотрудникам для решения конкретных задач. Это еще одно преимущество Managed Kubernetes.

Очевидно, важны сетевые политики, так как в пространствах имен по умолчанию не предусмотрена изоляция. Изначально рабочие нагрузки и все пространства имен в кластере могут свободно взаимодействовать друг с другом. Здесь нужно вводить ограничения с помощью сетевых политик или service mesh, поддерживающих эти функции. Опять же, все эти стандарты безопасности следует использовать как чек-лист, как подсказку, даже как OWASP Top 10 для Kubernetes. Это отличная исходная точка. Так вы можете исправить проблему. Например, используя контекст безопасности подов и контейнеров, можно проверить, не запущены ли они как корневые. Может, чтобы упростить задачу, для начала можно внедрить какой-то инструмент, который будет сообщать вам об этих вещах и показывать общую картину, чтобы было понятно, чего не хватает.

Нардьелло: Еще стоит сказать о NIST. Он предоставляет очень грамотные рекомендации по безопасности контейнеризированных рабочих нагрузок. У этого стандарта очень широкая область применения. Он затрагивает не только Kubernetes, хотя это и одна из ключевых тем. Open Policy Agent — это главный элемент, который я бы однозначно включил во все эксплуатационные кластеры. У него есть и аналоги, например, Kyverno. Просто определите политики как код и решите, что это значит для вашей организации и что для нее приемлемо. Избегайте повышения привилегий, не запускайте контейнеры как корневые и т. д. Все это можно превратить в политику как код и встроить в кластер. Так кластеры поймут, что значит работать безопасно и что такое безопасная рабочая нагрузка.

Вот что я еще хочу сказать: подписывайте контейнеры. Есть программа Sigstore; используйте Cosign для кластеров. Нужно, чтобы выполнялись подписанные рабочие нагрузки, а не какие-то произвольные штуки, которые вы просто нашли в интернете. Нужно запускать то, что создал. Service mesh предоставляет базовые возможности, такие как Mutual TLS и базовые возможности наблюдаемости в кластере. Потратьте на service mesh силы и время — это очень эффективный подход, который однозначно стоит внедрять в кластеры. Не говоря уже о входящем трафике в целом. Как вы поддерживаете безопасность входящего трафика, настраиваете брандмауэр, каким рискам подвергаете сервисы? Это еще один важный вопрос. Он связан с service mesh, но не только.

Безопасность образа контейнера

Лозио: Вы упомянули безопасность образа контейнера. Тема показалась мне интересной. Что я как разработчик должен делать?

Нардьелло: Родная мне тема, в том смысле, что это момент игнорируют 90% времени. Кто бы ни использовал кластеры Kubernetes, все говорят: да я просто возьму все из Docker Hub и буду работать оттуда. Обязательно используйте исправные базовые образы. Можно сколько угодно вкладывать усилия в политику как код, в service mesh, в операторы, да во что хотите. Но если вы используете образ с вредоносным кодом, подменяющим адрес Bitcoin-кошелька на адрес злоумышленника, то это проблема. Думаю, прямо сейчас наступил поворотный момент, когда специалисты стали понимать значение защищенных базовых образов. В Sigstore, Cosign происходит множество изменений. Chainguard делает замечательные вещи с Wolfi и distroless-образами. У нас есть собственный каталог защищенных контейнеров от SIGHUP. Самое главное: обязательно используйте работоспособные образы. Под работоспособными я прежде всего имею в виду образы, подлежащие техобслуживанию, потому что иногда с ними просто никто ничего не делает. Во-вторых, у них грамотные настройки по умолчанию, в основном rootless. Далее это образы, в которых учли грамотные рекомендации. Какие именно это рекомендации, зависит от того, какие рабочие нагрузки вам нужны.

Девочко: Здесь важна возможность выбора. Выбирайте самый минимальный базовый образ, какой только есть, ведь многие поставщики базовых образов предлагают на выбор несколько вариантов. Важно понимать, какой образ вам нужен. Не просто взять тот, который предлагается по умолчанию, а продумать, можете ли вы использовать минимальный образ, хватит ли его для работы приложения. В плане безопасности это дает множество преимуществ: вы используете образ, который содержит только нужные компоненты, так что поверхность атаки сокращается. И с точки зрения потребления ресурсов образ будет меньше весить, если в него запаковано поменьше компонентов. Конечно, в плане безопасности преимуществом будут и доверенные реестры. Подумайте, из каких реестров вы получаете образы.

Ченетс: Это все вопрос воспроизводимости. Эту работу не хочется выполнять вручную. Обязательно надо настроить пайплайн, который будет все это проверять. Вы создаете приложение с микросервисами, и оно будет подтягивать образы Docker. Вам нужны инструменты, которые могут проверять эти образы и уровни образов, например, на предмет распространенных уязвимостей и рисков и т. п. А еще вам нужно проверять цепочки поставок ПО, SBOM и т. п. До запуска в продакшн нужно удостовериться, что все работает. Вы ведь не запускаете в продакшн что-либо, пока не убедитесь в его работоспособности. Этот процесс должен быть воспроизводимым. Такие вещи вручную не делаются. У нас в Cisco есть open source-инструменты, которые помогают с безопасностью API, Kubernetes, данных и так далее. Еще у нас есть полный пакет для защиты облачных приложений, с помощью которого можно проверять политики, например, политику Kubernetes, уязвимости в API. В принципе, можно автоматизировать множество таких вещей. Просто выберите подходящий инструмент: внедрите его, автоматизируйте все, что только можно, и предоставьте разработчикам заниматься кодом. Убедитесь, что вы можете доверять инструменту автоматизации, который будет проверять для вас все эти вещи.

Девочко: Множество базовых образов поставляются с пользователем root, который по умолчанию управляет этим контейнером. Некоторые поставщики таких образов предлагают и непривилегированные варианты. Например, у NGINX есть два варианта: с обычным уровнем привилегий и NGINX unprivileged. В варианте с обычным уровнем по умолчанию настроен пользователь root. Это возвращает нас к вопросу о подах с уязвимостями и о том, какому пользователю разрешено их использовать. Старайтесь использовать непривилегированные базовые образы. Если эта возможность недоступна, иногда придется доработать создаваемый образ. Например, его можно перезаписать. Можно пойти обходным путем, как в случае с .NET-образами, когда их перезаписывают и используют другого пользователя для работы с контейнерами. Кроме того, Open Policy Agent и политики помогут отметить контейнеры, работающие с редуктором.

Ченетс: Базовые образы постоянно меняются. Очень важно использовать инструменты типа Slim.AI и другие сервисы, которые непрерывно мониторят образы и выявляют в них уязвимости.

Урезанные дистрибутивы

Лозио: Кристина уже затрагивала тему максимально урезанных дистрибутивов, которые запускают как контейнеры. Чем меньше у вас пакет, тем он и быстрее, и безопаснее. Конечно, в этом смысле поставщики облачных сервисов двигаются в правильном направлении. Допустим, я пользуюсь облачным решением и, как следствие, дистрибутивом конкретного поставщика облачных сервисов, будь то Linux-дистрибутив Amazon 2 или другое решение. А что бы вы посоветовали тем, кто работает с собственным кластером? Есть ли у вас конкретные рекомендации для конкретных сценариев использования?

Ченетс: О, их очень много; все зависит от вашего провайдера. Мы уже упоминали Wolfi, Slim.AI — и это далеко не все. Есть масса разных способов получить отличный базовый образ. Самое главное, — придерживаться slim-версии и понимать, что в нем. Не берите первое, что попало под руку. Есть столько достойных вариантов. Не могу порекомендовать что-то одно, потому что все-таки это пока еще формирующееся пространство.

Правила для среды исполнения контейнера

Лозио: Было бы хорошо, если бы Kubelet мог остановить среду исполнения контейнера, если она не прошла проверку на работоспособность системы безопасности в соответствии с предварительно заданным набором правил.

Нардьелло: Kubelet — это просто процесс, как и среда исполнения контейнера. Так что вряд ли это возможно. По крайней мере, я о таком не слышал. Используя управление политикой, OPA и т. п., можно установить правила, по которым среда исполнения контейнера фактически выполняет контейнер. Если у вас скомпрометированная среда исполнения контейнера, скомпрометированный CRI, Kubelet или какие-то другие компоненты, это значит, что у вас скомпрометирован хост-сервер, узел. Это один уровень безопасности. А еще есть то, что происходит внутри контейнеров, или эскалации от контейнеров к узлу. В основном ваш ответ на проблемы безопасности внутри контейнера — это управление политиками OPA. Вы можете определять правила работы CRI либо полагаться на оркестратор, который запланирует работу контейнеров. Если мы говорим о безопасности среды исполнения на уровне ноды, обязательно надо упомянуть такие проекты как Falco, или инструменты безопасности на базе eBPF. Falco Security — это open source upstream-проект фонда CNCF, который проверяет безопасность среды исполнения в нодах. И еще два очень важных момента. Первый: динамическое управление секретами. Это прямо по нашей теме. Не стоит выполнять действие bake с паролями в контейнерах. Их нужно вводить в динамическом режиме. Как это сделать? Опять же, есть масса инструментов, более или менее корпоративных, open source, предназначенных для upstream-систем.

Open source-инструменты безопасности для Kubernetes

Лозио: Какие open source-инструменты или инструменты вообще вы бы посоветовали? Если бы вы могли рекомендовать что-то одно, какой инструмент вы бы посоветовали разработчику?

Девочко: Я бы посоветовала инструмент Trivy от Aqua Sec. Я уже какое-то время им пользуюсь. По-моему, хороший инструмент. В нем реализовано множество возможностей, например, проверка конфигурации образов контейнеров, исходного кода. В этом инструменте есть масса разных настраиваемых функций, и в составе CI/CD-пайплайна, и в самом кластере. Еще я бы отметила относительно новый инструмент Kubescape. Мне очень нравится, что его действительно легко настроить и что он потребляет очень мало ресурсов при сканировании конкретных фреймворков. Я думаю, он сканирует и на соответствие стандарту NIST. По крайней мере, он выполняет проверки на соответствие руководству NSA по защите Kubernetes, это тоже очень хороший стандарт. Мне особенно нравится, что он фактически может визуализировать конфигурации RBAC в кластере. Можно видеть все связи между разными сервисными аккаунтами, Role Binding и ClusterRole Binding, так что становится понятно, у кого какие разрешения. Мне кажется, для этой функции есть ограничения по количеству нод. Это надо проверить. Наверное, для работы в корпоративной продакшн-среде потребуется лицензия. Чтобы посмотреть инструмент в деле, попробовать разные настройки, можно воспользоваться бесплатной версией для нескольких нод. Я бы выбрала эти решения.

Управление секретами

Лозио: Для чего в управлении секретами переходить с поставщика облачных сервисов на нечто вроде Vault или на другие способы хранения секретов? Вроде бы решение по умолчанию достаточно хорошее.

Ченетс: Я думаю, это дело вкуса. Люди стремятся к наиболее простому решению, которое доступно им на данный момент, и это совершенно нормально. Если вы клиент поставщика облачных сервисов, всегда легче просто использовать то, что он предлагает. Если у вас изменились потребности, — возможно, вы начали работать в гибридной или локальной среде, — вам понадобится решение для управления секретами вроде Vault. Vault, пожалуй, самое распространенное. Есть операторы. Есть открытый Secrets Operator, который управляет некоторыми из них, всё равно используя решения вроде Vault. На самом деле все зависит от ваших потребностей. Скорее всего, предложения поставщика облачных сервисов — это самый простой способ. Если у вас нет каких-то других потребностей, ничего и не делайте. Если когда-то вам понадобится что-то еще, сделайте это. Это очень простой ответ, но на самом деле все сводится именно к этому. Все зависит от того, насколько крепко вы привязаны к своему провайдеру и насколько вам нужна открытость для решения других задач.

Инструментарий безопасности для Kubernetes

Лозио: Может быть, вы порекомендуете еще какой-то инструмент безопасности?

Нардьелло: Их так много. Kubernetes сам по себе планирует разные задачи на нодах, так что все остальное можно, в принципе, считать инструментами. Я полностью согласен с Майклом. Все зависит от того, в какой среде вы работаете, и от конкретного сценария использования. Вы крупное предприятие с аппаратным модулем безопасности? Скорее всего, тогда вам нужно корпоративное решение вроде Vault, CyberArk или аналогов. Вы работаете с AWS или другим провайдером? Пользуйтесь тем, что вам предлагает провайдер.

Как улучшить безопасность деплоймента Kubernetes: план действий

Лозио: Можете ли вы порекомендовать одно действие, которое разработчик может выполнить, чтобы повысить уровень безопасности Kubernetes прямо завтра? Например, прочитать статью, что-то посмотреть, что-то сделать, пройтись по определенному чек-листу.

Девочко: Я предпочитаю учиться на практике. Если вы используете Managed Kubernetes, — ведь это достаточно просто, — я бы предложила положиться на решение по управлению политиками, просто чтобы получить общее представление о конфигурации. Если начинать с теории, советую всем изучить стандарт NIST или OWASP, потому что он очень быстро подводит к конкретным действиям.

Ченетс: Обязательно вникните, за что вы взялись, выясните, что у вас есть, и визуализируйте это. Используйте инструменты. Например, новый open source-инструмент Monokle обеспечивает базовую безопасность и поддерживает множество других функций. Это нечто вроде IDE для всех действий с Kubernetes. Он также поддерживает инструменты сканирования. 

Вебинары по теме

У VK Cloud было два вебинара про безопасность в Kubernetes:

1. «Облака и безопасность сегодня. Executive briefing»

2. «Безопасность на уровне кода: как эту задачу помогает решать облако».

3 октября будет третий вебинар по этой теме: «DevSecOps: организация безопасной разработки на уровне процессов». Приглашаем его посетить.

Вы прямо сейчас можете воспользоваться Kubernetes от VK Cloud. Для тестирования мы начисляем новым пользователям 3 000 бонусных рублей и будем рады вашей обратной связи.

Stay tuned

Присоединяйтесь к Telegram-каналу «Вокруг Kubernetes», чтобы быть в курсе новостей из мира K8s: регулярные дайджесты, полезные статьи, а также анонсы конференций и вебинаров.