Как АНБ говорит, что вы должны защищать Kubernetes

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

Аутентификация и авторизация

Реализовать механизмы аутентификации и авторизации

Администраторы внедряют методы аутентификации для упрощения аутентификации и авторизации механизмов, поскольку методы автоматической аутентификации по умолчанию отсутствуют. в Kubernetes для учетных записей пользователей. Это можно сделать с помощью клиентских сертификатов, токенов-носителей, подключаемых модулей аутентификации или любого другого поддерживаемого протокола аутентификации. Однако следует любой ценой избегать слабых методов, таких как статические файлы паролей.

Настроить управление доступом на основе ролей

RABC можно использовать для ограничения доступа ко всем ресурсам в кластере. Роли устанавливают разрешения для определенного пространства имен, а ClusterRoles устанавливают разрешения на уровне кластера. Между тем, RoleBindings и ClusterRoleBindings связывают эти разрешения с конкретным пользователем, группой или учетной записью службы. Все эти привязки должны следовать принципу предоставления наименьших привилегий только с абсолютно необходимыми разрешениями.

Уровень управления безопасностью

Управление доступом к плоскости управления Kubernetes

Являясь мозгом кластера, плоскость управления должна быть защищена путем принудительного шифрования TLS и использования надежного метода аутентификации. Кроме того, доступ к плоскости управления должен быть ограничен с помощью политик RBAC и сетевых элементов управления, таких как брандмауэр, который блокирует несанкционированный доступ к API Kubernetes. API не должен быть доступен в Интернете или какой-либо ненадежной сети.

Внутренняя база данных Harden Etcd

База данных Etcd хранит информацию о состоянии и секреты кластера для защиты файла Etcd. Он должен быть доступен только через сервер API с кластерным методом аутентификации и RBAC, ограничивающим пользователей. Администраторы также должны обеспечить связь HTTPS между сервером API и Etcd с использованием сертификатов TLS. Более того, им следует настроить Etcd так, чтобы он доверял только сертификатам, назначенным серверам API.

Защитить файлы Kubeconfig

Файлы kubeconfig в каталоге $HOME/.kube рабочих и управляющих узлов содержат конфиденциальную информацию о кластере, включая пользователя, пространство имен, данные аутентификации и т. д. Эти файлы должны быть защищены от непреднамеренных изменений, и их доступ должен быть заблокирован для любых пользователей без полномочий root, не прошедших проверку подлинности, чтобы предотвратить их компрометацию.

Безопасность модуля Kubernetes

Запуск приложения от имени непривилегированного пользователя

Запускайте приложения от имени пользователя без полномочий root в группе без полномочий root в контейнере или с помощью ядра контейнера без полномочий root для запуска в непривилегированном контексте. Это помогает свести к минимуму воздействие, если контейнер скомпрометирован.

Создать неизменяемую файловую систему-контейнер

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

Создание безопасных образов контейнеров

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

Применить политики безопасности Pod

Политики безопасности подов позволяют обеспечить безопасность всего кластера для подов, которые должны выполняться в кластере. Он устанавливает минимальный порог безопасности для всех модулей, даже если механизмы безопасности не указаны для модуля или развертывания. Эти политики могут варьироваться от запрета привилегированных контейнеров и функций контейнера до применения служб безопасности, таких как SELinux и AppArmor.

Отключить автоматическое монтирование токена сервисной учетной записи Pod

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

Безопасность сети и ресурсов

Создайте отдельные пространства имен

Пользователи могут создавать отдельные пространства, изолированные друг от друга, создавая отдельные пространства имен для конкретных приложений или рабочих нагрузок. Затем этими пространствами имен можно управлять отдельно, применяя RBAC для конкретных пространств имен, сетевые политики, ограничения ресурсов и квоты.

Реализовать сетевые политики

Сетевые политики позволяют администраторам контролировать поток трафика между модулями, пространствами имен и внешними IP-адресами. Поскольку K8 по умолчанию разрешают неограниченный вход и выход, управление трафиком является ключом к устранению ненужного воздействия контейнерного трафика.

Внедрение политик ресурсов

Политики ресурсов позволяют ограничивать ресурсы, которые можно использовать на уровне пространства имен и узлов. LimtRanges ограничивает отдельные ресурсы для каждого модуля или контейнера, а ResourceQuota ограничивает совокупное использование ресурсов для всего пространства имен.

Зашифровать всю сеть

Весь трафик между компонентами, узлами и плоскостью управления должен быть зашифрован с использованием стандарта TLS 1.2 или 1.3. Более того, соответствующие сертификаты должны быть распространены и поддерживаться в актуальном состоянии на всех узлах кластера.

Шифровать секреты Kubernetes в REST

Секреты Kubernetes хранятся в незашифрованном виде по умолчанию. Эти секреты можно зашифровать либо путем настройки шифрования на сервере API, либо с помощью внешней службы управления ключами. Кроме того, доступ к секретам следует контролировать с помощью политик RBAC.

Реализовать безопасность на уровне инфраструктуры

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

Мониторинг Kubernetes

Реализовать ведение журнала для всех ресурсов

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

Настройка предупреждений для кластера

В K8s нет механизма оповещения по умолчанию. Однако существует множество инструментов мониторинга с возможностями мониторинга. Эти оповещения должны быть настроены для отслеживания всех аспектов кластера, включая ненормальное использование ресурсов, отключение служб, аномальные запросы, необычное поведение пользователей и т. д. Оповещения могут действовать как превентивная мера для быстрого обнаружения изменений в кластере K8s.

Правильная настройка всех упомянутых выше элементов в вашей среде Kubernetes может повысить уровень безопасности вашей среды и создать более устойчивую среду для кибератак. Такая платформа, как CloudPlex, позволяет объединять различные облачные платформы и технологии и упрощает разработку и развертывание контейнерных приложений. Более того, он предоставляет комплексные возможности мониторинга как для приложений, так и для окружающей среды.

Асад Файзи

Генеральный директор

Cloudplex.io, Inc

asad@cloudplex.io