Основы безопасности внутри Kubernetes: 10 простых советов

Kubernetes стал одним из самых популярных вариантов развертывания кода в облаке, при этом не стоит забывать о мерах безопасности. Итак, вы подняли кластер. Может, у вас уже развернуты какие-то приложения. Как же теперь защитить эту сложную систему? Вот несколько базовых советов.

1. Используйте RBAC

Убедитесь, что в кластерах активированы политики избирательного управления доступом (RBAC). Это поможет контролировать, кто может получить доступ к API Kubernetes и какие разрешения у них есть.

В Kubernetes 1.6 и более поздних версиях RBAC обычно включены по умолчанию, но если вы обновились и не изменили свою конфигурацию, стоит проверить настройки. Возможно, придется включить RBAC и отключить устаревшее управление доступом на основе атрибутов (ABAC).

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

Вот еще несколько полезных советов:

1. Не нужно предоставлять кому-либо привилегии администратора кластера, даже для отладки. Гораздо безопаснее предоставлять доступ только по мере необходимости в каждом конкретном случае. Используйте kubectl get clusterrolebinding или kubectl get rolebinding –all-namespaces, чтобы узнать об используемых ролях.
2. Всякий раз при установке чарта Helm проверяйте, что включена опция rbac.enabled: true. Она позволяет создавать специфичные для данного приложения объекты RBAC.
3. Инструмент RBAC Manager помогает прописать политики RoleBindings и ClusterRoleBindings и создать простой файл CRD (Custom Resource Definitions), который связывает пользователей, группы и сервис-аккаунты (то есть аккаунты, управляемые Kubernetes API) с их ролями.
4. Наконец, когда вы глубоко увязли в настройках RBAC и уже не можете понять, почему у кого-то нет доступа к какому-то ресурсу, или, наоборот, доступ есть, а его быть не должно, разобраться поможет утилита RBAC Lookup.

Более подробно о RBAC и уровнях доступа мы писали в другой статье о защите кластера Kubernetes.

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

2. Свободно используйте пространства имен

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

3. Создайте и определите сетевые политики кластера

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

4. Отделяйте критические рабочие нагрузки

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

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

Разделение можно осуществить с помощью пулов узлов, а также контролирующих механизмов Kubernetes, таких как пространства имен.

5. Включите ведение журнала аудита

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

6. Не запускайте несколько процессов в одном контейнере

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

7. Не запускайте контейнеры как привилегированные

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

8. Не запускайте контейнеры под рутом

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

spec:
securityContext:
runAsUser: 10324
Скопировать код

9. Не используйте все настройки по умолчанию

Docker запускает контейнеры с большим списком настроек Linux по умолчанию, многие из которых не нужны вашему приложению. Можете найти их в исходном коде. В следующей конфигурации удалены все настройки Linux, чтобы вы добавили только конкретные опции, которые действительно нужны вашему приложению:

spec:
containers:
- name: foo
securityContext:
capabilities:
drop:
- ALL
Скопировать код

10. Проверяйте контейнеры на наличие уязвимостей

Используйте известные инструменты для сканирования контейнеров на наличие уязвимостей, а затем устраните их. Мы составляли подробный список инструментов для безопасности Kubernetes, можно воспользоваться каким-либо из них.