Kubernetes — это де-факто платформа управления контейнерами в современном облачном мире. Это позволяет гибко и масштабируемо разрабатывать, развертывать и управлять микросервисами. Kubernetes работает с различными облачными провайдерами, интерфейсами среды выполнения контейнеров, провайдерами аутентификации и расширяемыми точками интеграции. Развернуть готовый к продакшену кластер можно в облаке сервиса Serverspace.

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

Согласно отчету Red Hat о безопасности « Состояние Kubernetes » за 2022 год, доставка большинства пользователей Kubernetes была остановлена ​​из-за нерешенных проблем безопасности. Кроме того, в течение предыдущих 12 месяцев почти каждый пользователь Kubernetes, участвовавший в исследовании, сталкивался как минимум с одним инцидентом безопасности. Поэтому будет справедливо сказать, что среды Kubernetes небезопасны по умолчанию и подвержены рискам.

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

1. Секреты Kubernetes

Секреты являются одним из основных строительных блоков Kubernetes для хранения конфиденциальных данных, таких как пароли, сертификаты или токены, и их использования внутри контейнеров. Есть три критических проблемы, связанные с секретами Kubernetes:

• Секреты хранят конфиденциальные данные в виде строк в кодировке base-64, но по умолчанию они не зашифрованы. Kubernetes предлагает шифрование ресурсов для хранения, но его необходимо настроить. Кроме того, самая большая угроза секретам заключается в том, что любой модуль — и любые приложения, работающие внутри модуля — в одном и том же пространстве имен могут получить к ним доступ и прочитать их.
• Управление доступом на основе ролей (RBAC) позволяет вам регулировать, кому предоставляется доступ к ресурсам Kubernetes. Вам необходимо правильно настроить правила RBAC, чтобы только соответствующие люди и приложения имели доступ к секретам.
• Секреты и ConfigMaps — это два метода передачи данных в работающие контейнеры. Наличие старых и неиспользуемых секретов или ресурсов ConfigMap может привести к путанице и утечке уязвимых данных. Например, если вы удалите развертывание внутреннего приложения, но забудете удалить секрет, содержащий пароли вашей базы данных, любой вредоносный модуль сможет использовать их в будущем.

2. Образы контейнеров с уязвимостями

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

Поэтому необходимо сканировать образы перед развертыванием, чтобы убедиться, что в кластере будут работать только образы из доверенных реестров без критических уязвимостей (таких как удаленное выполнение кода). Сканирование образов контейнеров также должно быть интегрировано в системы CI/CD для автоматизации и раннего обнаружения дефектов.

3. Угрозы во время выполнения

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

Доступны широко распространенные инструменты с открытым исходным кодом, такие как Seccomp , SELinux и AppArmor на уровне ядра Linux, для реализации политик и ограничения доступа. Эти инструменты не являются внутренними для Kubernetes и требуют внешней настройки и усилий для обеспечения защиты от угроз во время выполнения. Чтобы защитить Kubernetes автоматически, попробуйте использовать подход Kubernetes Security Posture Management (KSPM) . KSPM использует инструменты автоматизации для обнаружения, устранения и оповещения о проблемах безопасности, конфигурации и соответствия требованиям, используя целостный подход.

4. Неправильная конфигурация кластера и настройки по умолчанию

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

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

• Конфигурации Kubernetes по умолчанию полезны, поскольку они пытаются повысить гибкость и маневренность, но они не всегда являются самыми безопасными вариантами.
• Онлайн-примеры ресурсов Kubernetes полезны для начала работы, но необходимо еще раз проверить, какие определения этих примеров ресурсов будут развернуты в вашем кластере.
• При работе с кластерами принято вносить изменения в ресурсы Kubernetes с помощью команд «kubectl edit». Однако если вы забудете обновить исходные файлы, изменения будут перезаписаны при следующем развертывании, а неотслеживаемые изменения могут привести к непредсказуемому поведению.

5. Политики RBAC Kubernetes

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

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

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

6. Доступ к сети

В Kubernetes модуль может подключаться к другим модулям и внешним адресам за пределами кластера; другие могут подключаться к этому модулю из кластера по умолчанию. Сетевые политики — это собственные ресурсы Kubernetes для управления и ограничения сетевого доступа между модулями, пространствами имен и блоками IP.

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

7. Целостный мониторинг и ведение журналов аудита

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

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

8. Kubernetes API

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

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

9. Запросы и ограничения ресурсов Kubernetes

Помимо планирования и запуска контейнеров, Kubernetes также может ограничивать использование ресурсов контейнеров с точки зрения ЦП и памяти. Хотя пользователи Kubernetes в основном пренебрегают ими, запросы ресурсов и лимиты имеют решающее значение по двум причинам:

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

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

10. Данные и хранилище

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

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

Вывод

Kubernetes — бесспорная платформа управления контейнерами для запуска микросервисных приложений. Однако комплексная безопасность по-прежнему является одним из его недостатков, поскольку не является основным направлением проекта. Поэтому вам необходимо предпринять дополнительные шаги, чтобы сделать ваши кластеры и приложения более безопасными.