Самое популярно средство контейнеризации и автоматизации развертывания приложений — Docker. Популярное, но не единственное: достойную конкуренцию ему составляет Kubernetes. Разумеется, он тоже представляет определенный интерес для злоумышленников. Сегодня поговорим о безопасности Kubernetes. Вы узнаете, как защитить Kubernetes от взлома и сетевых атак.
В статье Безопасность Docker я рассказал о том, как проверить текущий уровень защищенности очень популярной в DevOps-среде системы контейнеризации Docker и как улучшить эту самую защиту. В этой статье мы продолжим изучать вопросы безопасности DevOps-инфраструктуры, и у нас под прицелом система контейнерной оркестрации на базе Kubernetes. Мы разберем основные атаки, проанализируерм нашумевшие уязвимости, а также соберем набор инструментов, необходимый для обеспечения безопасности кластера на Kubernetes.
- О Kubernetes в двух словах
- Обзор основных векторов атак на Kubernetes
- Проблемы безопасности K8s
- Примеры критических багов
- Усиливаем безопасность Kubernetes
- Для API-сервера:
- Для etcd-сервера:
- Рекомендуемые шаги для усиления безопасности перед развертыванием K8s-кластера
- Утилиты для аудита безопасности
- Легитимность используемых образов
- Безопасность эксплуатации
- Безопасность сетевого взаимодействия
- Коммерческие решения для безопасности Kubernetes
- Дополнительные утилиты для усиления безопасности Kubernetes
- Заключение
О Kubernetes в двух словах
Я думаю, каждый, кто хотя бы однажды сталкивался с миром DevOps, имеет общее представление о том, что такое Kubernetes. Если кратко, то это довольно популярная система контейнерной оркестрации (правда, к музыке и оркестрам она не имеет ни малейшего отношения). На чем основывается популярность Kubernetes и чем он так хорош?
Kubernetes, или, сокращенно, K8s, — система автоматизации развертывания и масштабирования контейнеризированных приложений и управления ими, реализованная на базе открытого программного обеспечения. Проект был основан в 2014 году. Оригинальная версия некогда разрабатывалась в недрах самой Google для внутренних нужд корпорации, но впоследствии была передана под управление опенсорсному фонду Cloud Native Computing Foundation, откуда и попала в широкие массы.
Изначально K8s задумывалась как система-менеджер для управления кластерами из контейнеров. Система динамическая, она реагирует на события в режиме реального времени и позволяет поднять сервис, который будет просто работать без танцев с бубном и масштабироваться по запросу. Гибко, быстро, экономически эффективно — именно то, что нужно разработчикам!
В практике администрирования Kubernetes используется понятие подов (pods). Каждый под — это группа объединенных общей задачей контейнеров (к примеру, на том же Docker), которые могут быть и микросервисом, и массивным приложением, разнесенным на несколько параллельно работающих машин. Kubernetes призван решать проблемы с эффективным распределением выполнения контейнеров по узлам кластера в зависимости от изменения нагрузки и текущей потребности в сервисах. Иными словами, перед нами — система гибкого управления инфраструктурой контейнеризации с возможностью балансировки нагрузки.
Давай перечислим основные технические задачи, которые можно решить с помощью Kubernetes:
- запуск большого числа контейнеров Docker или Rocket на большом количестве хостов;
- мониторинг состояния run-time-среды и своевременное реагирование на изменения;
- управление запущенными контейнерами, обеспечение их совместного размещения и межконтейнерной репликации;
- масштабирование и балансировка большого количества хостов в пределах кластера.
Сегодня K8s стал неким стандартом для современных DevOps-сред как в больших компаниях, так и среди стартапов. Он активно используется в облачных сервисах вроде AWS, Microsoft Azure или Google Cloud.
По своей сути Kubernetes представляет собой один из стратегических компонентов всего DevOps-процесса, именно поэтому атаки на него всегда были и остаются актуальными. Ведь, взломав эту систему, хакер получит доступ ко всем нодам и контейнерам, запущенным внутри K8s, а это уже прямой путь и к компрометации или утечке конфиденциальных данных.
Самое печальное, что в сети до сих пор полно публичных K8s-серверов, доступ к которым можно получить из интернета. Как? Широко известен, например, замечательный сервис Shodan, который позволяет искать уязвимые версии ПО, доступные из интернета и «готовые к атаке». От таких незакрытых уязвимостей в свое время пострадали десятки тысяч публичных баз MongoDB. Если ты захочешь проверить, как работает Shodan на практике, это можно сделать при помощи поискового скрипта, выложенного на GitHub.
Обзор основных векторов атак на Kubernetes
Как мы выяснили чуть раньше, K8s имеет довольно сложную архитектуру и использует в своем составе множество компонентов. Потому векторы и типы атак на эту систему тоже разнятся. Итак, общая площадь атак включает в себя:
- Master Node — главный мастер-сервер, который управляет всем кластером рабочих узлов (подов) и развертыванием модулей на этих узлах;
- Worker Node — рабочие серверы, на которых запускают контейнеры приложений и другие компоненты Kubernetes, к примеру такие, как K8s-агенты и прокси-серверы;
- Pods — это неделимая элементарная единица развертывания и адресации в Kubernetes. Под имеет собственный IP-адрес и может содержать один или несколько контейнеров;
- Services — сетевые службы, обеспечивающие обмен данными внутри кластера, балансировку, репликацию, обрабатывающие запросы и так далее;
- System Components — ключевые системные компоненты, которые используются для управления кластером Kubernetes: сервер API, Kubelet и другие.
Проблемы безопасности K8s
Как и в любой сложной системе, придуманной людьми, в инфраструктуре кластера K8s имеются типичные проблемы безопасности, с которыми часто сталкиваются системные администраторы. Ниже я перечислю самые известные из них.
- Explosion of East-West Traffic, или атака «Взрыв трафика Восток — Запад». Суть этой атаки заключается в том, что контейнеры могут быть динамически развернуты в нескольких независимых друг от друга облаках, что значительно увеличивает трафик обмена данными внутри логического кластера. Это похоже на перегон поездов по железной дороге, и именно поэтому данный вид атак получил название «С востока на запад». Удаленное расположение контейнеров может использоваться злоумышленниками, например, для реализации DDoS-атак.
- Increased Attack Surface (увеличенная площадь атаки). Проблема основывается на том, что каждый контейнер может иметь различную поверхность атаки и собственные уникальные уязвимости, которые используются хакерами для дальнейшего взлома. К примеру, могут использоваться уязвимости для Docker или системы авторизации AWS.
- Container compromise (компрометация контейнера). Суть атаки кроется в использовании неверной конфигурации (security misconfiguration) для всех контейнеров кластера, которые косвенным образом способствуют компрометации или же включают в себя уязвимости приложений. К компрометациям контейнера относятся манипуляции внутренней коммутацией, управлением процессами или доступом к файловой системе.
- Unauthorized connections between pods (несанкционированные соединения между подами внутри единого кластера). Скомпрометированные контейнеры могут соединяться с другими контейнерами на том же или на других хостах, чтобы запустить какую-либо атаку. Несмотря на то что фильтрация на уровне L3 (ACL-листы) обеспечивается сетевым оборудованием согласно настроенным правилам, некоторые неавторизованные обращения могут быть обнаружены только с помощью фильтрации на седьмом уровне модели OSI.
Примеры критических багов
Любой прикладной и системный софт имеет ряд критических уязвимостей, и K8s не исключение. Наличие подобных багов ставит под угрозу весь кластер, от запущенных контейнеров в целом до конкретных данных, хранящихся внутри БД на каком-либо отдельном поде.
По статистике, собранной из реестра уязвимостей NIST, больше всего критических ошибок было обнаружено в 2018 году — восемь штук, и четыре уязвимости найдены уже в текущем году. Ниже я расскажу о самых громких багах, наделавших много шуму среди разработчиков, которые использовали Kubernetes.
Первая уязвимость получила номер CVE-2019-5736. Об этом баге, обнаруженном в текущем году, мы уже писали на страницах нашего сайта. Он позволяет вредоносному контейнеру перезаписать исполняемый файл runC на хост-системе, при этом никакого взаимодействия с пользователем не требуется. В результате подобной атаки злоумышленник может получить root-доступ к хосту и возможность исполнять на нем произвольный код. В феврале 2019 года эксплоит для CVE-2019-5736 был опубликован на GitHub.
Еще один баг, выявленный в марте 2019 года, имеет идентификатор CVE-2019-11246. Он позволяет атакующему доставлять файлы из пода на компьютер оператора или модифицировать их с помощью подмены tar binary, используя обычную внутреннюю команду kubectl cp.
Другой прошлогодний баг — CVE-2018-1002105 связан с эскалацией привилегий. Он позволяет атакующему повысить привилегии в кластере и получить к нему доступ из-за логической ошибки обработки API-вызовов. Эксперты по безопасности оценили уязвимость в 9,8 балла по шкале CVSS, поскольку брешь не требует предварительной аутентификации и проста в эксплуатации. Несанкционированный доступ открывается после отправки специфического запроса к API-серверу Kubernetes. Все уязвимые сборки Kubernetes некорректно обрабатывают вредоносный запрос, позволяя обратиться к бэкенду с использованием учетных данных TLS, прописанных в настройках API-сервера. Через несколько дней после обнаружения проблемы PoC-эксплоит был опубликован на GitHub. Позже выпустили патч, закрывающий эту уязвимость.
Вот общий сценарий действий хакеров при использовании уязвимости CVE-2018-1002105.
- Определение локации в ИТ-ландшафте, где запущен K8s.
- Эксплуатация известных уязвимостей облачных провайдеров.
- Запуск команд внутри контейнера.
- Доступ к файловой системе node.
- Разведка во внутренней сети, горизонтальное расширение и закрепление внутри взломанных систем.
Еще один громкий кейс, связанный с K8s, имел место в 2018 году. Речь идет о взломе аккаунта всем известной компании Tesla в облаке Amazon Web Services. Как позже выяснили эксперты, учетные данные в одном из подов Kubernetes открыли доступ к среде AWS Tesla, которая содержала корзину Amazon S3. В ней, в свою очередь, хранились конфиденциальные данные, в том числе телеметрия. Однако вместо кражи этих данных хакеры начали майнить криптовалюту на одном из подов Tesla.
Хороший и доступный каждому админу бенчмарк проверки безопасности K8s — набор CIS Kubernetes Benchmark, который можно бесплатно забрать с официального сайта CIS или GitHub-репозитория. Набор включает список рекомендуемых требований безопасности, чек-лист проверки и скрипты для автоматического анализа текущих конфигураций K8s.
Усиливаем безопасность Kubernetes
Обеспечение безопасности Kubernetes условно можно представить двумя практическими подходами. Первый подход — это настройка опций безопасности (security hardening) и использование лучших практик (security best practices) на всех ключевых элементах K8s-инфраструктуры. Второй подход — применение сторонних утилит с открытыми исходниками и коммерческих решений для обеспечения мониторинга, контроля и управления уровнем безопасности.
Начну с общих рекомендаций и советов, как усилить безопасность Kubernetes, которыми в состоянии воспользоваться любой DevOps-администратор.
- Повсеместное использование шифрования TLS. Для каждого инфраструктурного компонента K8s, поддерживающего протокол TLS, он должен быть включен. Это гарантирует защиту от сниффинга трафика, форсирование удостоверения идентичности сервера и (в случае Mutual TLS) удостоверения идентичности клиента.
- RBAC-ориентированная модель доступа и минимально возможные привилегии. Управление доступом на основе ролей (Role-based access control, RBAC) обеспечивает тонкое управление политиками, с использованием которых пользователи получают доступ к таким ресурсам, как пространства имен.
- Сторонняя аутентификация для API server. Централизация аутентификации и авторизации для всей компании, к примеру на базе LDAP и Single Sign On, помогает выдавать и отзывать права для сотрудников предприятия.
- Инкапсуляция кластера etcd за сетевым экраном. Поскольку кластер etcd хранит информацию о состоянии Kubernetes и секретах доступа (токены, сертификаты), он является критичным компонентом K8s. Именно поэтому etcd должен быть защищен отдельно от остального кластера, лучше за файрволом и изолированной VPC.
- Систематическая ротация ключей шифрования. Регулярная ротация (по сроку и событию) ключей безопасности и сертификатов — одна из лучших практик в обеспечении безопасности любой ИТ-системы. Она позволяет ограничить «радиус поражения» при компрометации ключа доступа.
- Регулярный статический анализ YAML-файлов конфигурации. Конфиденциальная информация, продекларированная в YAML-формате, не должна храниться в открытом виде на подах. А конфиденциальные конфигурации и секреты доступа (пароли) должны быть зашифрованы с помощью таких инструментов, как git-crypt. Статический анализ конфигурации YAML может использоваться для установления базовых показателей безопасности, причем проводить такой анализ следует регулярно.
- Ограничения на запуск контейнеров под учетной записью root. Зачастую у контейнеров, которые запускаются с правами суперпользователя root, намного больше прав, чем того требуют их рабочие нагрузки, что в случае компрометации помогает атакующим получить еще больше возможностей.
- Обязательные сетевые политики. По умолчанию сеть в Kubernetes разрешает весь трафик между подами без каких-либо ограничений. Эту настройку можно ограничить сетевой политикой — NetworkPolicy.
- Некоторые команды для форсирования безопасности на элементах K8s-инфраструктуры. Чтобы повысить безопасность сетевой инфраструктуры в Kubernetes, можно использовать специальный набор команд, которые я привожу ниже.
Для API-сервера:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
// Отключение анонимного доступа --anonymous-auth=false // Разрешение только авторизованных запросов --authorizationmode AlwaysAllow // Форсирование ограничений прав на kubelets, включая NodeRestriction на API server --admission-control // Форсирование использование RBAC-модели доступа к объектам K8s --authorization-mode=RBAC // Отключение небезопасных портов --insecure-port=0 |
Для etcd-сервера:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
// Форсирование использования защищенного HTTPS connections к серверу etcd --cert-file and --key-file // Включение принудительной авторизации при обращении к etcd --client-cert-auth=true // Использование только подписанных сертификатов --trusted-ca-file // Отключение использования автоподписанных сертификатов --auto-tls=false // Использование только безопасных методов подключения --peer-client-cert-auth=true --peer-autotls=false and specify --peer-cert-file, --peer-key-file // Запуск etcd в защищенном исполнении --peer-trusted-ca-file // Форсирование авторизации с использованием сертификатов для API-сервера --etcd-cafile |
Рекомендуемые шаги для усиления безопасности перед развертыванием K8s-кластера
- Используй на всю катушку пространства имен (namespaces).
- Форсируй SELinux (хотя бы в продакшен-среде!).
- Используй Seccomp.
- Используй Cgroups.
- Используй минимальное количество запущенных хостов.
- Не забывай про установку обновлений и патчей (обновления ядра, библиотек и так далее).
- Периодически запускай тесты безопасности CIS Benchmark для контроля состояния защищенности.
Перед любыми операциями конфигурирования не забывай сделать бэкап конфига! Документируй все изменения, чтобы потом не потерять лог изменений и не вырвать себе с досады волосы на затылке.
Утилиты для аудита безопасности
Аудит безопасности Kubernetes для эффективной комплексной оценки должен включать в себя несколько следующих областей:
- безопасность конечных хостов (Host security);
- безопасность мастер-ноды и API-сервера Kubernetes (Master node Kubernetes security);
- безопасность демонов Docker (Docker daemon security);
- контейнерную безопасность (Container security);
- правила использования модели RBAC-доступа (Properly configured RBACs);
- безопасность хранимых и передаваемых данных (Securing data at rest and in transit).
Утилитка-сканер kube-bench — это шустрое приложение, написанное на Go, которое проверяет, насколько безопасно развернут Kubernetes. Для этого kube-bench прогоняет все проверки, описанные в тесте CIS Kubernetes. Тесты настраиваются с помощью файлов YAML, что позволяет легко обновлять их по мере развития спецификаций.
Примеры использования некоторых команд утилиты kube-bench:
1 2 3 4 5 6 7 8 |
// Запуск утилиты в автоматическом режиме (автопоиск мастер-ноды) # kube-bench master // Запуск тестов безопасности CIS Kubernetes # kube-bench node --version 1.13 // Запуск утилиты внутри контейнера # docker run --pid=host -v /etc:/etc:ro -v /var:/var:ro -t aquasec/kube-bench:latest [master|node] --version 1.13 |
Еще одна утилита — Kubeaudit — это инструмент командной строки для аудита кластеров Kubernetes на предмет различных проблем безопасности. Поддерживает проверку множества опций, к примеру таких, как запуск контейнеров под учетной записью root, хранение секретов доступа (токены, сертификаты), возможность записи в корневую директорию.
Для установки утилиты в систему используй следующие команды:
1 2 3 |
# go get -v github.com/Shopify/kubeaudit # make # make install |
Запустить все имеющиеся тесты в последовательном режиме можно так:
1 |
# kubeaudit all |
Для проверки безопасности для сервисных аккаунтов предусмотрена вот такая команда:
1 |
# kubeaudit sat сервиск акунт |
А эта команда предназначена для проверки безопасного использования привилегий:
1 |
# kubeaudit priv |
Kubesec — инструмент управления секретами доступа для Kubernetes с поддержкой таких сервисов, как GPG, Google Cloud KMS и AWS KMS backends. Служба оценивает, насколько ресурсы Kubernetes используют возможности для повышения безопасности. Пользователь получает рекомендации, как повысить общую безопасность системы. Посмотреть вживую, как работает эта утилита, можно на демонстрационном видеоролике.
Легитимность используемых образов
Легитимность использования образов для развертывания контейнеров — один из ключевых критериев безопасности. Но эта фича относится скорее к Docker, чем к Kubernetes, поэтому я расскажу об используемых для этого инструментах очень кратко. Более подробную информацию ты можешь найти в нашей статье по безопасности Docker.
Clair — это проект с открытым исходным кодом для статического анализа уязвимостей в контейнерах appc и docker. Данные об уязвимостях постоянно импортируются из известных источников и соотносятся с индексированным содержимым образов контейнера, чтобы сформировать списки уязвимостей, угрожающих каждому контейнеру в отдельности.
Еще одна похожая утилита носит название Dagda. Это инструмент для статического анализа известных уязвимостей, поиска троянов, вирусов, вредоносных программ, а также других угроз в образах и контейнерах Docker. Кроме того, Dagda используется для мониторинга сетевых служб Docker и запуска контейнеров в целях обнаружения аномальных действий. Проверка зависимостей основана на проектах OWASP и Retire.js для анализа безопасности таких слоев, как Java, Python, Node.js, JS, Ruby, PHP.
Trivy — простой и комплексный сканер уязвимостей для контейнеров, поддерживающий командную строку. Trivy обнаруживает уязвимости программных пакетов ОС (Alpine, RHEL, CentOS и других) и зависимостей приложений (Bundler, Composer, npm, yarn и так далее).
Безопасность эксплуатации
Для того чтобы обеспечить безопасную эксплуатацию Kubernetes, был придуман целый арсенал специальных утилит. Одна из них называется Falco. Это крутецкий опенсорсный сканер от Sysdig Secure для обнаружения вторжений и проблем безопасности на платформах Cloud Native, таких как Kubernetes, Mesosphere и Cloud Foundry. Falco умеет искать аномалии, нетипичное поведение и предупреждает админа через Slack, Fluentd, NATS, а также другие мессенджеры.
Cilium — сервис, обеспечивающий фильтрацию сетевой активности с учетом API-вызовов в контейнерной инфраструктуре на базе Linux, в частности в Docker и Kubernetes. Используя новую технологию ядра Linux под названием BPF (Berkeley Packet Filter), Cilium предоставляет простой и эффективный способ определять и применять политики безопасности как сетевого уровня, так и уровня приложений на основе идентификатора контейнера или модуля.
Vault — сервис от всем известной компании HashiCorp. Он позволяет хранить и строго контролировать доступ к токенам, паролям, сертификатам, ключам шифрования для защиты секретов и других конфиденциальных данных из пользовательского интерфейса, CLI-строки или с помощью API-вызовов по протоколу HTTP.
Безопасность сетевого взаимодействия
Решение Calico обеспечивает безопасное сетевое взаимодействие между контейнерами и виртуальными машинами в одном кластере. По сути, Сalico представляет собой софтовый свитч (Softswitch), который создает сеть третьего уровня и управляет ею, назначая каждому инстансу полностью маршрутизируемый IP-адрес. В средах, где требуется наложение, Calico использует туннелирование IP-in-IP, что позволяет работать с другими наложенными сетями.
Еще одно полезное приложение — Cilium представляет собой контейнерный межсетевой экран. Программа использует технологию ядра Linux BPF для фильтрации, детекта, мониторинга и перенаправления данных с использованием вызовов ядра. Cilium помогает развертывать политики доступа к сети на основе идентификатора контейнера с использованием меток тегов. Помимо этого, софтина интерпретирует несколько протоколов уровня 7, таких как HTTP или gRPC, что позволяет использовать набор вызовов REST.
Коммерческие решения для безопасности Kubernetes
А теперь — несколько слов о коммерческих решениях для обеспечения безопасности Kubernetes в частности и всей облачной ИТ-инфраструктуры вообще. Как показывает практика, использование коммерческих Enterprise-решений оправданно с точки зрения удобства управления инструментами из единого окна, скорости их работы и более гибкого масштабирования, предоставляемого по запросу. Игроков на рынке Cloud Security довольно много, мы остановимся лишь на самых известных и проверенных сервисах.
Aqua Security — сервис, нацеленный на мониторинг и контроль состояния безопасности для контейнеров и облачных приложений. Сервис представляет комплексное решение для автоматизации таких задач, как Vulnerability Management, Runtime Protection, Secrets Management, Embedded CI/CD Scanning, Container Firewall, Compliance & Auditing. Некоторые утилиты, используемые для Enterprise, доступны для бесплатного использования на GitHub-страничке проекта.
Cavirin — еще один известный сервис для автоматического обнаружения и постоянной оценки гибридной облачной среды без установки end-point-агентов на конечных хостах. Cavirin обеспечивает непрерывный мониторинг базовых показателей безопасности на основе фреймворков и лучших практик, включая PCI, HIPAA, NIST, усиление защиты AWS. Сервис предоставляет также точную и своевременную информацию об обновлениях безопасности и уязвимостях. Архитектура Cavirin на основе API-интерфейса легко интегрируется с другими локальными приложениями, а также с SaaS и облачными сервисами.
NeuVector — это довольно известная и неплохо зарекомендовавшая себя сквозная платформа безопасности для всех DevOps-процессов и, в частности, для обеспечения безопасности Kubernetes. Услуга включает в себя такие фичи, как управление уязвимостями для образов, контроль доступа, защита процессов в памяти и файловых систем в контейнерах, файрвол вплоть до седьмого уровня OSI.
Декларативная политика безопасности обеспечивает быстрое масштабирование приложений без ручного вмешательства. Решение, поставляемое NeuVector, — это, по сути, сам контейнер, сертифицированный Red Hat и Docker, который легко развертывается на каждом хосте, обеспечивая межсетевое взаимодействие (файрвол), мониторинг процессов и файловых систем внутри контейнера, аудит безопасности с помощью тестов CIS и сканирование уязвимостей.
Sysdig Secure — широко известный стек решений для комплексной безопасности облачных сервисов. Услуга включает наборы приложений для обеспечения таких процедур, как Vulnerability management, Compliance, Runtime security, Forensics, Audit. Помимо решений, позиционируемых как Enterprise, вендор предлагает качественные опенсорсные утилиты для аудита и контроля безопасности. Также для бесплатного использования всем желающим предоставлен сканер Falco, о котором мы более подробно писали в статье про безопасность Docker (ссылка в начале статье).
Как видишь, очень часто вместе с проприетарными решениями можно успешно использовать и бесплатные опенсорсные утилиты, что усиливает суммарный общий эффект от их применения.
Дополнительные утилиты для усиления безопасности Kubernetes
Расскажу о нескольких небольших утилитах, которые пригодятся тебе при формировании правильной матрицы доступа к инфраструктурным элементам K8s-кластера.
Audit2rbac — инструмент, позволяющий определить, какие разрешения необходимы для определенного ПО в составе K8s, при этом он автоматом генерирует RBAC-роли.
Rbac-manager — еще одна тулза, по сути оператор Kubernetes, который упрощает управление RBAC-ролями и привязку их к учетным записям администраторов.
Kube2iam — тулза, которая подставляет учетные данные из сервиса управления доступом AWS IAM для всех контейнеров в кластере.
И в завершение нашего сегодняшнего материала несколько интересных ресурсов по теме обеспечения безопасности Kubernetes, включающих best practices, обзоры утилит и примеры некоторых системных команд.
Kubernetes Security resource center of O’Reilly — онлайн-версия книги Kubernetes Security Operating Kubernetes Clusters and Applications Safely издательства O’Reilly Media. Наиболее полный и содержательный гайд по планированию и настройкам безопасности кластеров на базе Kubernetes. Электронную версию книги можно бесплатно скачать здесь.
Overview of Cloud Native Security — официальный документ от разработчиков Kubernetus с описанием общих рекомендаций по обеспечению безопасности.
The Ultimate Guide to Kubernetes Security — неплохая обзорная статья, описывающая некоторые векторы атак, проблемы безопасности и типовые рекомендации по защите K8s, собранные компанией NeuVector — разработчиком решений ИБ для облачных сред.
Kubernetes Security Best-Practices — отлично структурированный и содержательный документ с описанием функций безопасности Kubernetes, которые можно настроить самостоятельно. Этот же документ есть и на GitHub.
Заключение
Сегодня мы разобрали очень важную для всего DevOps-сообщества тему безопасности системы контейнерной оркестрации Kubernetes. Теперь ты имеешь представление об основных векторах атак, типовых проблемах и потенциальных рисках при использовании этого сверхпопулярного опенсорсного фреймворка, познакомился с общими требованиями к проектированию и развертыванию K8s с точки зрения безопасности и знаешь несколько системных команд, позволяющих обезопасить свой кластер и спать спокойнее по ночам.