Контейнеры и K8s - головная боль, с которой вам придется жить
После активного уикэнда на коньках, я решила весь день не вставать из гамака, а потому начну писать заметки на тему контейнеров - то, чем мне приходится активно интересоваться, несмотря на внутреннее старперское сопротивление.
Для ИБшника на четвертом десятке лет, особенно успевшего забраться относительно высоко по карьерной лестнице (типа ciso или principal architect) необходимость терпеть на вверенной территории инфраструктуру контейнеров почти так же неприятна, как адаптация политик и тренингов персонала под нужды смузисосущих миллениало-хипстеров. Бринг-ёр-оун айфон и сельфи-палку со встроенной алексой, вот это всё...
С другой стороны, если вы работаете в компании, где CEO/CTO по возрасту отстают от вас уже почти на поколение, то с новой реальностью придется смириться и быть стильно-модно-молодежным.
Соответственно, нужно понять, что такое эти контейнеры, чем они отличаются от привычных вам виртуальных машин, и на что обращать внимание при создании или оценке систем их защиты.
Как же обрести сакральное знание в этом потоке видео от вендоров, традиционно обещающих заткнуть любую дыру в безопасности в один клик, если только вы сможете выдавить охулиончик-другой из CFO на покупку их вундерсофта?
Вот несколько каналов, относительно свободных от спонсорского контента:
- The Linux Foundation - содержит определенное количество спонсорских видео, но в не очень агрессивном формате. Большинство видео все же вендорно-нейтральны, с содержанием, соответствующим заявленной теме
- Cloud Native Computing Foundation (CNCF) - тоже вендорно-нейтральный канал, с упором на облачные технологии
- Cloud with Raj - видеоблог архитектора облачной безопасности из AWS, который не пытается продать вам практически ничего, кроме своих курсов на Udemy, при этом выкладывая солидную часть знаний бесплатно на тытрубке. Автор канала обладает весьма разборчивым для индуса акцентом и хорошим чувством юмора (на мой вкус). Бонусом идут типичные вопросы-ответы на интервью, которые вы можете использовать, если появится бюджет на расширение команды.
- GITrepo с черновиками книги Liz Rice, чистовая версия которой доступна для скачивания с сайта компании AquaSecurity (чистовик содержит больше продакт-плейсмента)
- AppSecEngineer Youtube Channel - владелец канала, как и упомянутый выше Raj, продвигает свои тренинги, но при этом выкладывает и множество информативных видео, причем это не просто разговоры, но и живая демонстрация настроек
Ниже я привожу краткий конспект просмотренных видео, с комментариями из личного опыта
1. Почему опыт защиты виртуальных машин сложно перенести на контейнеры, хотя между этими объектами много общего?
В первую очередь, потому что, контейнеры, по своей природе, очень динамичны. Они могут быть созданы, перезапущены и уничтожены множество раз в течение дня. Поэтому традиционный подход "внести в CMDB, поставить антивирус, составить план патчинга" работать не будет
2. Кто является ответственным за контейнеры и их безопасность?
Здесь все одновременно и проще, и сложнее, чем с виртуалками. Если в эпоху виртуалок за приложение был ответственным разработчик/бизнес-владелец для покупного софта, за инфраструктуру отвечали сисадмины, а за аудит - безопасники, то контейнеры пришли вместе с infrastructure-as-a-code (Terraform, CloudFormation...) Да, еще они пришли вместе с облаками и принятой там моделью разделения ответственности между пользователем и облачным вендором (для контейнеров это будет комбинацией IaaS/PaaS). В соответствии с парадигмой shift-left, принятой в DevSecOps, безопасность теперь вынуждена водить бесконечный хоровод с разработчиками и инфраструктурщиками.
На практике это означает, что никого невозможно призвать к ответственности безопасность должна присутствовать на всех трех этапах жизненного цикла контейнеров:
- Разработка
Убедиться, что разработчики не таскают образы контейнеров, откуда попало, а только из одобренных реестров. Все образы должны быть просканированы на наличие уязвимостей/ошибок конфигурации до того, как их запустят вместе с содержащимися внутри приложениями. Доверенные образы должны содержать цифровую подпись, чтобы снизить риски заражения вредоносными программами и обеспечить защиту от несанкционированных изменений.
- Создание инфраструктуры
Убедиться, что используются только согласованные образы виртуальных машин, что весь обслуживающий контейнеры софт (Jenkins, GIT, Swarm, Compose, Kubernetes, Open Shift, Core OS, Puppet, Chef, Ansible...) пропатчен. Периодически запускать CIS benchmarks или его аналог, предоставленный облачным вендором (AWS Inspector/Azure Security Benchmark etc). CIS = Center for Internet Security, а не иностранная аббревиатура для СНГ :) Разработать правила для файерволов для общения контейнеров между собой и с окружающей сетью. Ввести ограничения на использование ресурсов. Разработать правила для RBAC/IAM. Настроить решение для хранения секретов (пароли, ключи доступа).
В идеале - автоматизировать все описание инфраструктуры Терраформом (или чем-то подобным) и сканировать шаблоны какой-нибудь софтиной (например, Checkov).
Этот этап жизненного цикла - наиболее привычен и понятен безопасникам. Самое главное - найти ответственных за весь этот патчинг и убедиться, что все требования выполняются.
- Функционирование контейнера
Проводить динамическое сканирование активных контейнеров, чтобы убедиться, что никто не меняет их в обход шаблонов (т.н. container drifting), настроить аудит и автоматизированную реакцию на те или иные важные события (перерасход ресурсов, подозрение на компрометацию...)
3. Типичные угрозы для контейнеров:
- Запуск злоумышленниками майнинга криптовалюты за счет облачных ресурсов вашей компании
- Кража секретов (паролей, ключей доступа) или других важных данных, к которым имеют доступ контейнеры, для дальнейших атак на инфраструктуру
- Использование вашей инфраструктуры для организаций ddos-атак через ботнет
- Внесение несанкционированных изменений в образы контейнеров
4. Некоторые широко применяемые инструменты для защиты контейнеров (постаралась сюда намеренно не включать ничего откровенно коммерческого, типа Qualys, вне зависимости от эффективности софта)
- OPA (open policy agent) + gatekeeper - инструмент для создания и применения политик к контейнерам
- Falco - опенсорсный статический сканер от sysdig, "подаренный" общественности в лице CNCF, использующийся по умолчанию для проверки образов контейнеров Docker (имеет коммерческого брата под названием Falco Runtime для динамического сканирования)
- kube-bench - стандартный инструмент для проверки на соответствие CIS Benchmarks
- kube-hunter - еще один бесплатный инструмент для поиска уязвимостей (предоставлен вендором AquaSecurity, у которых есть и множество платных продуктов)
- calico, illuminatio - утилиты для тестирования сетевых правил внутри кластера
- Clair, OpenSCAP - сканеры уязвимостей
- Kubei - опенсорсный сканер активных контейнеров на предмет динамических уязвимостей (активация вредоносной программы, несанкционированный запуск контейнера, превышение привилегий)
Для ИБшника на четвертом десятке лет, особенно успевшего забраться относительно высоко по карьерной лестнице (типа ciso или principal architect) необходимость терпеть на вверенной территории инфраструктуру контейнеров почти так же неприятна, как адаптация политик и тренингов персонала под нужды смузисосущих миллениало-хипстеров. Бринг-ёр-оун айфон и сельфи-палку со встроенной алексой, вот это всё...
С другой стороны, если вы работаете в компании, где CEO/CTO по возрасту отстают от вас уже почти на поколение, то с новой реальностью придется смириться и быть стильно-модно-молодежным.
Соответственно, нужно понять, что такое эти контейнеры, чем они отличаются от привычных вам виртуальных машин, и на что обращать внимание при создании или оценке систем их защиты.
Как же обрести сакральное знание в этом потоке видео от вендоров, традиционно обещающих заткнуть любую дыру в безопасности в один клик, если только вы сможете выдавить охулиончик-другой из CFO на покупку их вундерсофта?
Вот несколько каналов, относительно свободных от спонсорского контента:
- The Linux Foundation - содержит определенное количество спонсорских видео, но в не очень агрессивном формате. Большинство видео все же вендорно-нейтральны, с содержанием, соответствующим заявленной теме
- Cloud Native Computing Foundation (CNCF) - тоже вендорно-нейтральный канал, с упором на облачные технологии
- Cloud with Raj - видеоблог архитектора облачной безопасности из AWS, который не пытается продать вам практически ничего, кроме своих курсов на Udemy, при этом выкладывая солидную часть знаний бесплатно на тытрубке. Автор канала обладает весьма разборчивым для индуса акцентом и хорошим чувством юмора (на мой вкус). Бонусом идут типичные вопросы-ответы на интервью, которые вы можете использовать, если появится бюджет на расширение команды.
- GITrepo с черновиками книги Liz Rice, чистовая версия которой доступна для скачивания с сайта компании AquaSecurity (чистовик содержит больше продакт-плейсмента)
- AppSecEngineer Youtube Channel - владелец канала, как и упомянутый выше Raj, продвигает свои тренинги, но при этом выкладывает и множество информативных видео, причем это не просто разговоры, но и живая демонстрация настроек
Ниже я привожу краткий конспект просмотренных видео, с комментариями из личного опыта
1. Почему опыт защиты виртуальных машин сложно перенести на контейнеры, хотя между этими объектами много общего?
В первую очередь, потому что, контейнеры, по своей природе, очень динамичны. Они могут быть созданы, перезапущены и уничтожены множество раз в течение дня. Поэтому традиционный подход "внести в CMDB, поставить антивирус, составить план патчинга" работать не будет
2. Кто является ответственным за контейнеры и их безопасность?
Здесь все одновременно и проще, и сложнее, чем с виртуалками. Если в эпоху виртуалок за приложение был ответственным разработчик/бизнес-владелец для покупного софта, за инфраструктуру отвечали сисадмины, а за аудит - безопасники, то контейнеры пришли вместе с infrastructure-as-a-code (Terraform, CloudFormation...) Да, еще они пришли вместе с облаками и принятой там моделью разделения ответственности между пользователем и облачным вендором (для контейнеров это будет комбинацией IaaS/PaaS). В соответствии с парадигмой shift-left, принятой в DevSecOps, безопасность теперь вынуждена водить бесконечный хоровод с разработчиками и инфраструктурщиками.
На практике это означает, что никого невозможно призвать к ответственности безопасность должна присутствовать на всех трех этапах жизненного цикла контейнеров:
- Разработка
Убедиться, что разработчики не таскают образы контейнеров, откуда попало, а только из одобренных реестров. Все образы должны быть просканированы на наличие уязвимостей/ошибок конфигурации до того, как их запустят вместе с содержащимися внутри приложениями. Доверенные образы должны содержать цифровую подпись, чтобы снизить риски заражения вредоносными программами и обеспечить защиту от несанкционированных изменений.
- Создание инфраструктуры
Убедиться, что используются только согласованные образы виртуальных машин, что весь обслуживающий контейнеры софт (Jenkins, GIT, Swarm, Compose, Kubernetes, Open Shift, Core OS, Puppet, Chef, Ansible...) пропатчен. Периодически запускать CIS benchmarks или его аналог, предоставленный облачным вендором (AWS Inspector/Azure Security Benchmark etc). CIS = Center for Internet Security, а не иностранная аббревиатура для СНГ :) Разработать правила для файерволов для общения контейнеров между собой и с окружающей сетью. Ввести ограничения на использование ресурсов. Разработать правила для RBAC/IAM. Настроить решение для хранения секретов (пароли, ключи доступа).
В идеале - автоматизировать все описание инфраструктуры Терраформом (или чем-то подобным) и сканировать шаблоны какой-нибудь софтиной (например, Checkov).
Этот этап жизненного цикла - наиболее привычен и понятен безопасникам. Самое главное - найти ответственных за весь этот патчинг и убедиться, что все требования выполняются.
- Функционирование контейнера
Проводить динамическое сканирование активных контейнеров, чтобы убедиться, что никто не меняет их в обход шаблонов (т.н. container drifting), настроить аудит и автоматизированную реакцию на те или иные важные события (перерасход ресурсов, подозрение на компрометацию...)
3. Типичные угрозы для контейнеров:
- Запуск злоумышленниками майнинга криптовалюты за счет облачных ресурсов вашей компании
- Кража секретов (паролей, ключей доступа) или других важных данных, к которым имеют доступ контейнеры, для дальнейших атак на инфраструктуру
- Использование вашей инфраструктуры для организаций ddos-атак через ботнет
- Внесение несанкционированных изменений в образы контейнеров
4. Некоторые широко применяемые инструменты для защиты контейнеров (постаралась сюда намеренно не включать ничего откровенно коммерческого, типа Qualys, вне зависимости от эффективности софта)
- OPA (open policy agent) + gatekeeper - инструмент для создания и применения политик к контейнерам
- Falco - опенсорсный статический сканер от sysdig, "подаренный" общественности в лице CNCF, использующийся по умолчанию для проверки образов контейнеров Docker (имеет коммерческого брата под названием Falco Runtime для динамического сканирования)
- kube-bench - стандартный инструмент для проверки на соответствие CIS Benchmarks
- kube-hunter - еще один бесплатный инструмент для поиска уязвимостей (предоставлен вендором AquaSecurity, у которых есть и множество платных продуктов)
- calico, illuminatio - утилиты для тестирования сетевых правил внутри кластера
- Clair, OpenSCAP - сканеры уязвимостей
- Kubei - опенсорсный сканер активных контейнеров на предмет динамических уязвимостей (активация вредоносной программы, несанкционированный запуск контейнера, превышение привилегий)