Kubernetes используется для автоматизации таких процессов, как развертывание, администрирование и масштабирование контейнерных приложений. Например, в Kubernetes работает Docker, который развертывает микросервисы и управляет ими. В Kubernetes рекомендуется запускать на одном узле по одному контейнеру, потому что так гораздо безопаснее. Или можно интегрировать несколько программ в один процесс, чтобы оптимизировать обработку и управление. Некорректная конфигурация может затронуть разные уровни Kubernetes, включая облако, кластер, контейнер и код. Например, у нас есть образ, который использует уязвимый программный пакет и находится в контейнере. Через эту уязвимость злоумышленник может получить доступ ко всему кластеру, куда входит много контейнеров. В Kubernetes мы продумываем защиту с разных сторон. Например, мы должны защищать хост и его компоненты, а также обеспечить безопасность на этапе сборки, развертывания или выполнения. У каждого аспекта безопасности есть свои методы и стандартные рекомендации для Kubernetes. Безопасность должна обеспечиваться на разных уровнях — код, кластер, контейнер, облако. Давайте рассмотрим методы обеспечения безопасности в Kubernetes. Пространства имен позволяют разделить наборы ресурсов в одном кластере. В одном пространстве имена должны быть уникальными, но между пространствами имен они могут повторяться. Каждый ресурс Kubernetes находится только в одном пространстве имен, и в пространство имен можно вложить не больше одного пространства имен. С их помощью мы реализуем логическое разделение кластера и ограничиваем разрешения пользователей. Задать пространство имен можно следующей командой: kubectl — это утилита командной строки в Kubernetes. В этой команде мы используем образ nginx с флагом --namespace для установки пространства имен. Добавив пространство имен, мы обращаемся к pod’ам в нем следующей командой: Если мы хотим указать пространство имен сразу для нескольких последующих команд, мы выполняем следующую команду: Пространство имен обеспечивает логическое разделение и изоляцию ресурсов. Если кластеры Kubernetes выполняются на стандартных портах, то для поиска открытых портов достаточно будет выполнить простой скан, и если порт не требует аутентификации, к нему будет легко подключиться. Поэтому рекомендуется настраивать на портах кластера и узлов аутентификацию и авторизацию. Кроме того, мы можем ограничить потребление ресурсов в кластере, установив минимальное и максимальное значение. Если не продумать эти значения, один контейнер может захватить все ресурсы, ничего не оставив другим. Указывая минимум и максимум для контейнера, мы оставляем запас для дефолтных операций и обеспечиваем нормальное функционирование для всей среды. По умолчанию все объекты в кластере Kubernetes создаются с неограниченными ресурсами ЦП и памяти. После создания пространства имен Kubernetes можно назначить политики с квотами, чтобы ограничить потребление ресурсов. Ниже мы создаем пространство имен, чтобы ограничить память, ЦП и pod’ы. Мы назвали этот фрагмент кода “com-resources.yaml”. Теперь развернем его в пространстве имен следующей командой: Ограничение доступа к ресурсам Kubernetes Чтобы ограничить доступ к ресурсам Kubernetes, организация должна заблокировать SSH и рекомендовать пользователям использовать kubectl exec, чтобы получать доступ к контейнеру, не получая доступ к хосту. В Kubernetes есть плагины авторизации, где можно детально настроить правила контроля доступа пользователей к ресурсам. Мы можем действовать через запросы Kubernetes API, и это будет работать как наша первая линия обороны, но нужно четко понимать, у кого должен быть доступ и какие действия можно выполнять в среде. Сервисы должны общаться друг с другом через TLS, чтобы весь трафик был зашифрован, и злоумышленник не мог украсть информацию. Это важный шаг, потому что иногда мы считаем, что кластер и так достаточно защищен и можно не тратить ресурсы на шифрование. Шифрование также осуществляется через Kubernetes API. Мы знаем, какое важное место в Kubernetes занимает Kubernetes API, так что для защиты API можно использовать аутентификацию. В Kubernetes есть несколько встроенных методов аутентификации (статичный файл токена, токен аккаунта сервиса и т. д.), но они не подходят для продакшена. Приходится использовать внешние методы аутентификации, например OpenID Connect (OIDC), поставщики удостоверений, имперсонацию в Kubernetes и т. д. Кроме того, для API требуется авторизация с использованием управления доступом на основе ролей (RBAC). Как следует из названия, RBAC предоставляет пользователям доступ к ресурсам в зависимости от роли. Когда в Kubernetes поступает запрос, он сопоставляется с пользователем или группой. Если у них достаточно разрешений, запрос будет обработан. Если нет — отклонен. Авторизация RBAC использует группу API rbac.authorization.k8s.io, чтобы динамически настраивать политики через Kubernetes API. Команда для этой задачи: Нужно перезапустить сервер API с флагом authorization-mode и указать список для RBAC через --more-options. Каждый день мы слышим о новых уязвимостях в разных опенсорс-пакетах. Скорее всего, ваша организация тоже использует какие-то пакеты с уязвимостями, поэтому лучше отслеживать их все. Если вы управляете списком всего используемого программного обеспечения, вы будете вовремя замечать проблемы и при необходимости обновляться. При этом не стоит устанавливать обновление прямо в продакшене, потому что оно может быть несовместимо с уже используемыми пакетами ПО. Сначала нужно все как следует протестировать в стейджинге и только потом выкатывать в продакшен. Для обновления мы используем команду: apt- update. В Kubernetes лучше всегда использовать функцию последовательных апдейтов и заменять экземпляры pod’ов по одному, чтобы обновление прошло без простоев. Новые pod’ы планируются на узлах, где есть достаточно ресурсов для их размещения. Мы можем определить в файле deployment.yaml контекст безопасности, например разрешения, чтобы запретить несанкционированный доступ к pod’ам, контейнерам и томам. Например, мы можем указать SecurityContext->runAsNonRoot, чтобы контейнер мог выполняться, только если у пользователя нет прав root. Можно настроить и другие параметры безопасности. Пример кода для pod’а: Сегодня все больше организаций переносят рабочие нагрузки в контейнеры и стараются обеспечить безопасность в Kubernetes. Kubernetes содержит ресурсы на разных уровнях, и мы должны защищать каждый из них. Если на одном уровне возникнет уязвимость, вся система Kubernetes будет уязвима. Существует много способов защиты Kubernetes, здесь мы перечислили самые основные. В учебном центре Слёрм открыта запись на курс «Безопасность в Kubernetes» для инженеров безопасности, DevOps’ов, SRE и разработчиков, самостоятельно работающих в Kubernetes.  На курсе вы познакомитесь с основными моделями угроз, а также узнаете как им противостоять и что делать, чтобы контейнер запустился в срок, а безопасность была на всех этапах — от разработки до отправки на сервер и последующего разворачивания. Все знания вы можете закрепить на практике на стендах — проработаете теорию и будете уверены в решениях. Приятный бонус – дарим бесплатный демо-урок об основных принципах безопасности проекта, живущего в K8s, и о моделях угроз.  Если вы уже имеете базовые знания и хотите потрогать внутрянку Kuba, приходите на «Kubernetes Мега». Вас ждут 6 часов практики, приправленной щепоткой теории от спикеров. Что будет? авторизация в кластере  настройка autoscaling резервное копирование  Stateful приложения в кластере интеграция Kubernets и Vault для хранения секретов HorizontalPodAutoscaler ротация сертификатов в кластере Blue-Green Deploy и Canary Deploy настройка Service mesh «Мега» подойдет всем, кому предстоит запускать Kubernetes в продакшн и отвечать за работу проекта в дальнейшем: специалистам по безопасности, системным инженерам, администраторам, архитекторам, DevOps и др. Пройдите бесплатный курс, чтобы научиться устанавливать Kubernetes в ручном режиме. Комплектом дешевле:  Мы предлагаем комплекты видеокурсов (тариф "Стандарт") со скидкой от 20%   «Безопасность» + «Мега» = 90 000 рублей вместо 130 000 Узнать подробности и записаться: «Безопасность в Kubernetes», «Kubernetes Мега».