Kubernetes стал одним из самых популярных вариантов развертывания кода в облаке, при этом не стоит забывать о мерах безопасности. Итак, вы подняли кластер. Может, у вас уже развернуты какие-то приложения. Как же теперь защитить эту сложную систему? Вот несколько базовых советов.
1. Используйте RBAC
Убедитесь, что в кластерах активированы политики избирательного управления доступом (RBAC). Это поможет контролировать, кто может получить доступ к API Kubernetes и какие разрешения у них есть.
В Kubernetes 1.6 и более поздних версиях RBAC обычно включены по умолчанию, но если вы обновились и не изменили свою конфигурацию, стоит проверить настройки. Возможно, придется включить RBAC и отключить устаревшее управление доступом на основе атрибутов (ABAC).
Помните: RBAC недостаточно включить, нужно также эффективно его использовать. Как правило, следует избегать общекластерных разрешений в пользу разрешений, специфичных для пространства имен.
Вот еще несколько полезных советов:
- Не нужно предоставлять кому-либо привилегии администратора кластера, даже для отладки. Гораздо безопаснее предоставлять доступ только по мере необходимости в каждом конкретном случае. Используйте kubectl get clusterrolebinding или kubectl get rolebinding –all-namespaces, чтобы узнать об используемых ролях.
- Всякий раз при установке чарта Helm проверяйте, что включена опция rbac.enabled: true. Она позволяет создавать специфичные для данного приложения объекты RBAC.
- Инструмент RBAC Manager помогает прописать политики RoleBindings и ClusterRoleBindings и создать простой файл CRD (Custom Resource Definitions), который связывает пользователей, группы и сервис-аккаунты (то есть аккаунты, управляемые Kubernetes API) с их ролями.
- Наконец, когда вы глубоко увязли в настройках RBAC и уже не можете понять, почему у кого-то нет доступа к какому-то ресурсу, или, наоборот, доступ есть, а его быть не должно, разобраться поможет утилита RBAC Lookup.
Более подробно о RBAC и уровнях доступа мы писали в другой статье о защите кластера Kubernetes.
Если вашему приложению необходим доступ к API Kubernetes, создайте учетные записи служб индивидуально и предоставьте им наименьший набор необходимых разрешений. Это лучше, чем предоставление слишком широких разрешений учетной записи по умолчанию для пространства имен.
Есть множество хороших примеров политик RBAC для различных сервисов в кластере, а также документация.
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, можно воспользоваться каким-либо из них.
Источник: https://mcs.mail.ru/blog/osnovy-bezopasnosti-vnutri-kubernetes
Что еще почитать по теме:
Три уровня автомасштабирования в Kubernetes и как их эффективно использовать
Рабочие узлы Kubernetes: много маленьких или мало больших?
Балансировка нагрузки и масштабирование долгоживущих соединений в Kubernetes