Безопасность Kubernetes

kubernetes безопасность

Самое популярно средство контейнеризации и автоматизации развертывания приложений — Docker. Популярное, но не единственное: достойную конкуренцию ему составляет Kubernetes. Разумеется, он тоже представляет определенный интерес для злоумышленников. Сегодня поговорим о безопасности Kubernetes. Вы узнаете, как защитить Kubernetes от взлома и сетевых атак.

В статье Безопасность Docker я рассказал о том, как проверить текущий уровень защищенности очень популярной в DevOps-среде системы контейнеризации Docker и как улучшить эту самую защиту. В этой статье мы продолжим изучать вопросы безопасности DevOps-инфраструктуры, и у нас под прицелом система контейнерной оркестрации на базе Kubernetes. Мы разберем основные атаки, проанализируерм нашумевшие уязвимости, а также соберем набор инструментов, необходимый для обеспечения безопасности кластера на Kubernetes.

О Kubernetes в двух словах

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

Kubernetes, или, сокращенно, K8s, — система автоматизации развертывания и масштабирования контейнеризированных приложений и управления ими, реализованная на базе открытого программного обеспечения. Проект был основан в 2014 году. Оригинальная версия некогда разрабатывалась в недрах самой Google для внутренних нужд корпорации, но впоследствии была передана под управление опенсорсному фонду Cloud Native Computing Foundation, откуда и попала в широкие массы.

Изначально K8s задумывалась как система-менеджер для управления кластерами из контейнеров. Система динамическая, она реагирует на события в режиме реального времени и позволяет поднять сервис, который будет просто работать без танцев с бубном и масштабироваться по запросу. Гибко, быстро, экономически эффективно — именно то, что нужно разработчикам!

Архитектура системы контейнерной оркестрации K8s
Архитектура системы контейнерной оркестрации 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.

Результат поиска публичных сервисов K8s с помощью Shodan
Результат поиска публичных сервисов K8s с помощью Shodan

Обзор основных векторов атак на Kubernetes

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

  • Master Node — главный мастер-сервер, который управляет всем кластером рабочих узлов (подов) и развертыванием модулей на этих узлах;
  • Worker Node — рабочие серверы, на которых запускают контейнеры приложений и другие компоненты Kubernetes, к примеру такие, как K8s-агенты и прокси-серверы;
  • Pods — это неделимая элементарная единица развертывания и адресации в Kubernetes. Под имеет собственный IP-адрес и может содержать один или несколько контейнеров;
  • Services — сетевые службы, обеспечивающие обмен данными внутри кластера, балансировку, репликацию, обрабатывающие запросы и так далее;
  • System Components — ключевые системные компоненты, которые используются для управления кластером Kubernetes: сервер API, Kubelet и другие.
Типовые векторы атак на K8s
Типовые векторы атак на K8s

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

Как и в любой сложной системе, придуманной людьми, в инфраструктуре кластера K8s имеются типичные проблемы безопасности, с которыми часто сталкиваются системные администраторы. Ниже я перечислю самые известные из них.

  • Explosion of East-West Traffic, или атака «Взрыв трафика Восток — Запад». Суть этой атаки заключается в том, что контейнеры могут быть динамически развернуты в нескольких независимых друг от друга облаках, что значительно увеличивает трафик обмена данными внутри логического кластера. Это похоже на перегон поездов по железной дороге, и именно поэтому данный вид атак получил название «С востока на запад». Удаленное расположение контейнеров может использоваться злоумышленниками, например, для реализации DDoS-атак.
Схематичное описание атаки Explosion of East-West Traffic
Схематичное описание атаки Explosion of East-West Traffic
  • Increased Attack Surface (увеличенная площадь атаки). Проблема основывается на том, что каждый контейнер может иметь различную поверхность атаки и собственные уникальные уязвимости, которые используются хакерами для дальнейшего взлома. К примеру, могут использоваться уязвимости для Docker или системы авторизации AWS.
  • Container compromise (компрометация контейнера). Суть атаки кроется в использовании неверной конфигурации (security misconfiguration) для всех контейнеров кластера, которые косвенным образом способствуют компрометации или же включают в себя уязвимости приложений. К компрометациям контейнера относятся манипуляции внутренней коммутацией, управлением процессами или доступом к файловой системе.
  • Unauthorized connections between pods (несанкционированные соединения между подами внутри единого кластера). Скомпрометированные контейнеры могут соединяться с другими контейнерами на том же или на других хостах, чтобы запустить какую-либо атаку. Несмотря на то что фильтрация на уровне L3 (ACL-листы) обеспечивается сетевым оборудованием согласно настроенным правилам, некоторые неавторизованные обращения могут быть обнаружены только с помощью фильтрации на седьмом уровне модели OSI.
Некоторые нашумевшие кейсы, связанные с безопасностью K8s
Некоторые нашумевшие кейсы, связанные с безопасностью K8s

Примеры критических багов

Любой прикладной и системный софт имеет ряд критических уязвимостей, и K8s не исключение. Наличие подобных багов ставит под угрозу весь кластер, от запущенных контейнеров в целом до конкретных данных, хранящихся внутри БД на каком-либо отдельном поде.

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

Статистика уязвимостей K8s из реестра NIST
Статистика уязвимостей K8s из реестра NIST

Первая уязвимость получила номер CVE-2019-5736. Об этом баге, обнаруженном в текущем году, мы уже писали на страницах нашего сайта. Он позволяет вредоносному контейнеру перезаписать исполняемый файл runC на хост-системе, при этом никакого взаимодействия с пользователем не требуется. В результате подобной атаки злоумышленник может получить root-доступ к хосту и возможность исполнять на нем произвольный код. В феврале 2019 года эксплоит для CVE-2019-5736 был опубликован на GitHub.

Еще один баг, выявленный в марте 2019 года, имеет идентификатор CVE-2019-11246. Он позволяет атакующему доставлять файлы из пода на компьютер оператора или модифицировать их с помощью подмены tar binary, используя обычную внутреннюю команду kubectl cp.

Схематичное описание уязвимости CVE-2019-11246
Схематичное описание уязвимости CVE-2019-11246

Другой прошлогодний багCVE-2018-1002105 связан с эскалацией привилегий. Он позволяет атакующему повысить привилегии в кластере и получить к нему доступ из-за логической ошибки обработки API-вызовов. Эксперты по безопасности оценили уязвимость в 9,8 балла по шкале CVSS, поскольку брешь не требует предварительной аутентификации и проста в эксплуатации. Несанкционированный доступ открывается после отправки специфического запроса к API-серверу Kubernetes. Все уязвимые сборки Kubernetes некорректно обрабатывают вредоносный запрос, позволяя обратиться к бэкенду с использованием учетных данных TLS, прописанных в настройках API-сервера. Через несколько дней после обнаружения проблемы PoC-эксплоит был опубликован на GitHub. Позже выпустили патч, закрывающий эту уязвимость.

Схематичное описание уязвимости CVE-2018-1002105
Схематичное описание уязвимости CVE-2018-1002105

Вот общий сценарий действий хакеров при использовании уязвимости CVE-2018-1002105.

  1. Определение локации в ИТ-ландшафте, где запущен K8s.
  2. Эксплуатация известных уязвимостей облачных провайдеров.
  3. Запуск команд внутри контейнера.
  4. Доступ к файловой системе node.
  5. Разведка во внутренней сети, горизонтальное расширение и закрепление внутри взломанных систем.

Еще один громкий кейс, связанный с K8s, имел место в 2018 году. Речь идет о взломе аккаунта всем известной компании Tesla в облаке Amazon Web Services. Как позже выяснили эксперты, учетные данные в одном из подов Kubernetes открыли доступ к среде AWS Tesla, которая содержала корзину Amazon S3. В ней, в свою очередь, хранились конфиденциальные данные, в том числе телеметрия. Однако вместо кражи этих данных хакеры начали майнить криптовалюту на одном из подов Tesla.

Пошаговый сценарий взлома AWS облака Tesla c целью майнинга
Пошаговый сценарий взлома AWS облака Tesla c целью майнинга

Хороший и доступный каждому админу бенчмарк проверки безопасности K8s — набор CIS Kubernetes Benchmark, который можно бесплатно забрать с официального сайта CIS или GitHub-репозитория. Набор включает список рекомендуемых требований безопасности, чек-лист проверки и скрипты для автоматического анализа текущих конфигураций K8s.

Усиливаем безопасность Kubernetes

Обеспечение безопасности Kubernetes условно можно представить двумя практическими подходами. Первый подход — это настройка опций безопасности (security hardening) и использование лучших практик (security best practices) на всех ключевых элементах K8s-инфраструктуры. Второй подход — применение сторонних утилит с открытыми исходниками и коммерческих решений для обеспечения мониторинга, контроля и управления уровнем безопасности.

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

  1. Повсеместное использование шифрования TLS. Для каждого инфраструктурного компонента K8s, поддерживающего протокол TLS, он должен быть включен. Это гарантирует защиту от сниффинга трафика, форсирование удостоверения идентичности сервера и (в случае Mutual TLS) удостоверения идентичности клиента.
  2. RBAC-ориентированная модель доступа и минимально возможные привилегии. Управление доступом на основе ролей (Role-based access control, RBAC) обеспечивает тонкое управление политиками, с использованием которых пользователи получают доступ к таким ресурсам, как пространства имен.
  3. Сторонняя аутентификация для API server. Централизация аутентификации и авторизации для всей компании, к примеру на базе LDAP и Single Sign On, помогает выдавать и отзывать права для сотрудников предприятия.
  4. Инкапсуляция кластера etcd за сетевым экраном. Поскольку кластер etcd хранит информацию о состоянии Kubernetes и секретах доступа (токены, сертификаты), он является критичным компонентом K8s. Именно поэтому etcd должен быть защищен отдельно от остального кластера, лучше за файрволом и изолированной VPC.
  5. Систематическая ротация ключей шифрования. Регулярная ротация (по сроку и событию) ключей безопасности и сертификатов — одна из лучших практик в обеспечении безопасности любой ИТ-системы. Она позволяет ограничить «радиус поражения» при компрометации ключа доступа.
  6. Регулярный статический анализ YAML-файлов конфигурации. Конфиденциальная информация, продекларированная в YAML-формате, не должна храниться в открытом виде на подах. А конфиденциальные конфигурации и секреты доступа (пароли) должны быть зашифрованы с помощью таких инструментов, как git-crypt. Статический анализ конфигурации YAML может использоваться для установления базовых показателей безопасности, причем проводить такой анализ следует регулярно.
  7. Ограничения на запуск контейнеров под учетной записью root. Зачастую у контейнеров, которые запускаются с правами суперпользователя root, намного больше прав, чем того требуют их рабочие нагрузки, что в случае компрометации помогает атакующим получить еще больше возможностей.
  8. Обязательные сетевые политики. По умолчанию сеть в Kubernetes разрешает весь трафик между подами без каких-либо ограничений. Эту настройку можно ограничить сетевой политикой — NetworkPolicy.
  9. Некоторые команды для форсирования безопасности на элементах K8s-инфраструктуры. Чтобы повысить безопасность сетевой инфраструктуры в Kubernetes, можно использовать специальный набор команд, которые я привожу ниже.

Для API-сервера:

Для etcd-сервера:

Рекомендуемые шаги для усиления безопасности перед развертыванием 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
Результат сканирования утилитой kube-bench

Примеры использования некоторых команд утилиты kube-bench:

Еще одна утилита — Kubeaudit — это инструмент командной строки для аудита кластеров Kubernetes на предмет различных проблем безопасности. Поддерживает проверку множества опций, к примеру таких, как запуск контейнеров под учетной записью root, хранение секретов доступа (токены, сертификаты), возможность записи в корневую директорию.

Для установки утилиты в систему используй следующие команды:

Запустить все имеющиеся тесты в последовательном режиме можно так:

Для проверки безопасности для сервисных аккаунтов предусмотрена вот такая команда:

А эта команда предназначена для проверки безопасного использования привилегий:

Результат сканирования утилитой Kubeaudit
Результат сканирования утилитой Kubeaudit

Kubesec — инструмент управления секретами доступа для Kubernetes с поддержкой таких сервисов, как GPG, Google Cloud KMS и AWS KMS backends. Служба оценивает, насколько ресурсы Kubernetes используют возможности для повышения безопасности. Пользователь получает рекомендации, как повысить общую безопасность системы. Посмотреть вживую, как работает эта утилита, можно на демонстрационном видеоролике.

Легитимность используемых образов

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

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

Архитектура сканера уязвимостей Clair
Архитектура сканера уязвимостей Clair

Еще одна похожая утилита носит название Dagda. Это инструмент для статического анализа известных уязвимостей, поиска троянов, вирусов, вредоносных программ, а также других угроз в образах и контейнерах Docker. Кроме того, Dagda используется для мониторинга сетевых служб Docker и запуска контейнеров в целях обнаружения аномальных действий. Проверка зависимостей основана на проектах OWASP и Retire.js для анализа безопасности таких слоев, как Java, Python, Node.js, JS, Ruby, PHP.

Архитектура сканера уязвимостей Dagda
Архитектура сканера уязвимостей Dagda

Trivy — простой и комплексный сканер уязвимостей для контейнеров, поддерживающий командную строку. Trivy обнаруживает уязвимости программных пакетов ОС (Alpine, RHEL, CentOS и других) и зависимостей приложений (Bundler, Composer, npm, yarn и так далее).

Запуск утилиты Trivy
Запуск утилиты Trivy

Безопасность эксплуатации

Для того чтобы обеспечить безопасную эксплуатацию Kubernetes, был придуман целый арсенал специальных утилит. Одна из них называется Falco. Это крутецкий опенсорсный сканер от Sysdig Secure для обнаружения вторжений и проблем безопасности на платформах Cloud Native, таких как Kubernetes, Mesosphere и Cloud Foundry. Falco умеет искать аномалии, нетипичное поведение и предупреждает админа через Slack, Fluentd, NATS, а также другие мессенджеры.

Дашборд сканера Falco
Дашборд сканера Falco

Cilium — сервис, обеспечивающий фильтрацию сетевой активности с учетом API-вызовов в контейнерной инфраструктуре на базе Linux, в частности в Docker и Kubernetes. Используя новую технологию ядра Linux под названием BPF (Berkeley Packet Filter), Cilium предоставляет простой и эффективный способ определять и применять политики безопасности как сетевого уровня, так и уровня приложений на основе идентификатора контейнера или модуля.

Архитектура Cilium
Архитектура Cilium

Vault — сервис от всем известной компании HashiCorp. Он позволяет хранить и строго контролировать доступ к токенам, паролям, сертификатам, ключам шифрования для защиты секретов и других конфиденциальных данных из пользовательского интерфейса, CLI-строки или с помощью API-вызовов по протоколу HTTP.

Архитектура HashiCorp Vault
Архитектура HashiCorp Vault

Безопасность сетевого взаимодействия

Решение Calico обеспечивает безопасное сетевое взаимодействие между контейнерами и виртуальными машинами в одном кластере. По сути, Сalico представляет собой софтовый свитч (Softswitch), который создает сеть третьего уровня и управляет ею, назначая каждому инстансу полностью маршрутизируемый IP-адрес. В средах, где требуется наложение, Calico использует туннелирование IP-in-IP, что позволяет работать с другими наложенными сетями.

Архитектура Calico
Архитектура Calico

Еще одно полезное приложение — Cilium представляет собой контейнерный межсетевой экран. Программа использует технологию ядра Linux BPF для фильтрации, детекта, мониторинга и перенаправления данных с использованием вызовов ядра. Cilium помогает развертывать политики доступа к сети на основе идентификатора контейнера с использованием меток тегов. Помимо этого, софтина интерпретирует несколько протоколов уровня 7, таких как HTTP или gRPC, что позволяет использовать набор вызовов REST.

Архитектура Cilium
Архитектура Cilium

Коммерческие решения для безопасности Kubernetes

А теперь — несколько слов о коммерческих решениях для обеспечения безопасности Kubernetes в частности и всей облачной ИТ-инфраструктуры вообще. Как показывает практика, использование коммерческих Enterprise-решений оправданно с точки зрения удобства управления инструментами из единого окна, скорости их работы и более гибкого масштабирования, предоставляемого по запросу. Игроков на рынке Cloud Security довольно много, мы остановимся лишь на самых известных и проверенных сервисах.

Aqua Security — сервис, нацеленный на мониторинг и контроль состояния безопасности для контейнеров и облачных приложений. Сервис представляет комплексное решение для автоматизации таких задач, как Vulnerability Management, Runtime Protection, Secrets Management, Embedded CI/CD Scanning, Container Firewall, Compliance & Auditing. Некоторые утилиты, используемые для Enterprise, доступны для бесплатного использования на GitHub-страничке проекта.

Комплексный подход к обеспечению безопасности от Aqua Security
Комплексный подход к обеспечению безопасности от Aqua Security

Cavirin — еще один известный сервис для автоматического обнаружения и постоянной оценки гибридной облачной среды без установки end-point-агентов на конечных хостах. Cavirin обеспечивает непрерывный мониторинг базовых показателей безопасности на основе фреймворков и лучших практик, включая PCI, HIPAA, NIST, усиление защиты AWS. Сервис предоставляет также точную и своевременную информацию об обновлениях безопасности и уязвимостях. Архитектура Cavirin на основе API-интерфейса легко интегрируется с другими локальными приложениями, а также с SaaS и облачными сервисами.

Консоль офицера безопасности Cavirin
Консоль офицера безопасности Cavirin

NeuVector — это довольно известная и неплохо зарекомендовавшая себя сквозная платформа безопасности для всех DevOps-процессов и, в частности, для обеспечения безопасности Kubernetes. Услуга включает в себя такие фичи, как управление уязвимостями для образов, контроль доступа, защита процессов в памяти и файловых систем в контейнерах, файрвол вплоть до седьмого уровня OSI.

Декларативная политика безопасности обеспечивает быстрое масштабирование приложений без ручного вмешательства. Решение, поставляемое NeuVector, — это, по сути, сам контейнер, сертифицированный Red Hat и Docker, который легко развертывается на каждом хосте, обеспечивая межсетевое взаимодействие (файрвол), мониторинг процессов и файловых систем внутри контейнера, аудит безопасности с помощью тестов CIS и сканирование уязвимостей.

Консоль офицера безопасности NeuVector Kubernetes Security
Консоль офицера безопасности NeuVector Kubernetes Security

Sysdig Secure — широко известный стек решений для комплексной безопасности облачных сервисов. Услуга включает наборы приложений для обеспечения таких процедур, как Vulnerability management, Compliance, Runtime security, Forensics, Audit. Помимо решений, позиционируемых как Enterprise, вендор предлагает качественные опенсорсные утилиты для аудита и контроля безопасности. Также для бесплатного использования всем желающим предоставлен сканер Falco, о котором мы более подробно писали в статье про безопасность Docker (ссылка в начале статье).

Консоль офицера безопасности Sysdig Secure
Консоль офицера безопасности Sysdig Secure

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

Дополнительные утилиты для усиления безопасности 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 с точки зрения безопасности и знаешь несколько системных команд, позволяющих обезопасить свой кластер и спать спокойнее по ночам.

Понравилась статья? Поделиться с друзьями:
Добавить комментарий