Многие компании стали использовать открытое программное обеспечение Kubernetes в продуктивной среде, настолько выросла его популярность за последние три года. Хотя в целом Kubernetes соответствует основным принципам обеспечения безопасности ПО, часть соответствующих обязанностей ложится на плечи конечных пользователей. При этом поставщики облачных услуг и заказчики несут совместную ответственность за обеспечение безопасности управляемых сервисов Kubernetes. Поставщики управляемых облачных сервисов Kubernetes, например Oracle Cloud Infrastructure Container Engine for Kubernetes (также известен как Oracle Kubernetes Engine, или OKE), Azure Kubernetes Service (AKS) и других, как правило, отвечают за управление и безопасность контролирующих элементов кластера Kubernetes (сервер API, планировщик, сервис хранения состояний etcd, контроллеры) , а заказчики управляемого сервиса – за обеспечение безопасности зоны обработки данных (пулы узлов, маршрутизация запросов, сетевые соединения, взаимодействие между сервисами и т. д.).
Вот 5 рекомендаций по обеспечению безопасности Kubernetes, основанные на многолетнем опыте и лушчих практиках использования боксов Vagrant для Kubernetes на Oracle Linux.
- Используйте контроль доступа на основе ролей (RBAC).
- Секреты должны оставаться в тайне.
- Обеспечьте безопасность узлов и подов.
- Устраните риски для безопасности контейнеров.
- Аудит, ведение журнала и мониторинг крайне важны.
Рассмотрим отдельно каждую из этих составляющих безопасности.
Используйте контроль доступа на основе ролей (RBAC)
Контроль доступа на основе ролей (Role Bases Access Control, RBAC) позволяет заказчику определять, у каких пользователей должен быть доступ к API Kubernetes и какие полномочия им следует предоставить. Как правило, функция RBAC активирована в Kubernetes по умолчанию. Однако, если до обновления Kubernetes использовалась очень старая версия, где функция RBAC была отключена, необходимо проверить настройки и убедиться, что она была активирована. Кроме того, следует помнить, что просто включить RBAC недостаточно. Пользователь должен управлять политиками авторизации и применять их надлежащим образом.
Используйте RBAC, чтобы ограничить полномочия пользователей и групп только теми действиями и задачами, которые могут им понадобиться. Всегда придерживайтесь принципа минимальных прав: пользователям и учетным записям сервиса Kubernetes Service Accounts необходимо предоставлять минимально достаточный набор прав. Выдавать разрешения на весь кластер, а также наделять пользователей правами администратора кластера следует только, если это совершенно необходимо.
Подробнее в официальной документации Kubernetes по RBAC. Oracle Cloud Infrastructure Identity and Access Management (OCI IAM) предоставляет полный контроль доступа для операций с кластерами Kubernetes, созданными и управляемыми с помощью Oracle Container Engine for Kubernetes.
Секреты должны оставаться в тайне
Секреты – это конфиденциальные данные, такие как пароль, маркер доступа или SSH-ключ. Секреты Kubernetes помогают обеспечить безопасность подов (pods) при их инициализации с помощью таких артефактов, как ключи, пароли, маркеры доступа и т. д. При запуске поду, как правило, требуется доступ к секретам. При создании учетной записи сервиса автоматически генерируется секрет Kubernetes, в котором хранится маркер ее авторизации.
Kubernetes поддерживает шифрование данных при хранении. Шифрование ресурсов секретов в сервисе хранения состояний etcd позволяет предотвратить просмотр содержимого этих секретов при доступе к резервным копиям etcd. Это обеспечивает дополнительный уровень защиты, если резервные копии не зашифрованы или злоумышленник получает доступ на чтение etcd. Передачу данных между пользователями и сервером API, а также между сервером API и агентами kubelet следует защитить с помощью SSL/TLS в соответствии с приведенными здесь указаниями.
Хорошая практика – задавать короткое время жизни для секрета или учетных данных, чтобы злоумышленнику было труднее ими воспользоваться. Также рекомендуется задавать короткое время жизни сертификатов и автоматизировать их ротацию. Кроме того, необходимо помнить о сторонних интеграциях, которые запрашивают доступ к секретам кластера Kubernetes. В подобных случаях необходимо внимательно проверять разрешения RBAC и запрошенный доступ. Иначе можно поставить под угрозу профиль безопасности кластера.
Обеспечьте безопасность узлов и подов
Узлы. Узел Kubernetes — это рабочий узел, который может представлять собой как виртуальную, так и физическую машину, работающую, как правило, под управлением операционной системы (ОС) Linux. На узле выполняются следующие сервисы: среда выполнения контейнера, агент kubelet и прокси kube-proxy. Крайне важно повысить надежность и обеспечить безопасность ОС, запущенной на узлах. Это входит в обязанности поставщика облачных сервисов и администратора Kubernetes.
На узлах Oracle Kubernetes Engine (OKE) установлен усиленный образ Oracle Linux. После выделения заказчику узлов администратор Kubernetes должен регулярно применять исправления к системе безопасности образа Oracle Linux, запущенного на узлах OKE. Вместе с управляемым сервисом OKE для узлов также используется набор Kubernetes Benchmark Центра интернет безопасности (CIS).
Помимо обеспечения безопасности ОС, рекомендуется размещать узлы в частной сети и закрывать доступ к ним из Интернета. При необходимости для доступа к другим сервисам за пределами сети можно настроить шлюз. Доступ к сетевым портам на узлах следует контролировать с помощью списков сетевого доступа. Кроме того, рекомендуется ограничить доступ к узлам по протоколу SSH.
Дополнительно в документации по безопасности пула узлов Oracle Kubernetes Engine.
Поды. Под (pod) – это группа из одного или нескольких контейнеров, которые запущены на узлах и используют общее хранилище/сеть. По умолчанию под можно запускать на любых узах – ограничений нет. Для задания правил передачи данных между подами в рамках одного кластера используйте политики сети. Политики сети реализуются сетевым подключаемым модулем. Для их использования может потребоваться сетевой драйвер, поддерживающий политики. Oracle Kubernetes Engine предлагает различные варианты обеспечения безопасности при передаче данных в кластер с рабочими сервисами заказчика и обратно.
Для усиления безопасности сети следует рассмотреть возможность совместного использования политик сети (для обеспечения безопасной передачи данных по сети на уровне подов) и списков безопасности (для обеспечения безопасной передачи данных по сети на уровне хостов). Политики безопасности пода Pod Security Policies позволяют заказчику управлять такими свойствами подов в среде выполнения, как право запускать контейнеры как привилегированные или использование файловой системы, сети и портов хоста. По умолчанию запуск пода можно запланировать на любом узле кластера.
Kubernetes предлагает различные способы управления распределением подов между узлами, например политики для управления размещением подов на узлах и размещения и вытеснения подов на основе taint. При использовании Oracle Kubernetes Engine (OKE) можно настроить политики безопасности подов, как описано в документации.
Устраните риски для безопасности контейнеров
Приложения упаковываются в виде образов контейнера (как правило, образов Docker). Образы контейнеров (образы Docker) хранятся и извлекаются из реестра контейнеров, а затем развертываются в качестве контейнеров среды исполнения внутри подов. С самого начала работы над исходным кодом и библиотеками с целью создания образов контейнера для приложений к обеспечению безопасности необходимо подходить как к принципу разработки.
Реализуйте меры по обеспечению безопасности в инструментальной цепочке CI/CD, а также на протяжении всего процесса создания, хранения и развертывания образов контейнера. Сюда входит безопасное хранение образов контейнера, сканирование этих образов на уязвимости, а также управление безопасностью среды выполнения контейнеров. В рамках цикла DevSecOps рекомендуется автоматизировать сканирование на предмет уязвимости сторонних библиотек, которые предполагается использовать для создания приложений. При использовании Oracle Kubernetes Engine имеет смысл присмотреться к некоторым решениям наших партнеров, например NeuVector и Twislock.
При создании образов и контейнеров Docker применяйте усиленные компактные образы ОС и следите за тем, чтобы пользователям, запускающим приложение, были предоставлены минимальные права на использование ОС, необходимые для запуска процессов внутри контейнера. Кроме того, важно не забывать о регулярной установке обновлений для системы безопасности исходного образа и последующем развертывании этого образа в виде обновленного контейнера. Важно также использовать частные реестры Docker, например Oracle Cloud Infrastructure Registry, с применением надлежащего контроля доступа и политик, а также регулированием управления образами контейнеров. Рекомендуется подписывать образы контейнеров и поддерживать систему доверия для содержимого контейнеров.
Аудит, ведение журнала и мониторинг крайне важны
Аудит, ведение журналов и мониторинг — это важные аспекты безопасности, способные усилить защиту кластера. Журналы аудита Kubernetes представляют собой подробные описания всех вызовов к серверу API Kubernetes. Эти журналы аудита содержат полезную информацию о том, что происходит в кластере. Их можно использовать для аудита, обеспечения соответствия нормативным требованиям и анализа безопасности.
Записи аудита Kubernetes включают записи безопасности, в которых хранятся полные последовательности действий. Они могут помочь обнаружить аномальное поведение и несанкционированный доступ к конфиденциальным ресурсам. Рекомендуется включить ведение журналов аудита и сохранять их в безопасном репозитории для анализа в случае нарушения безопасности.
Kubernetes также предлагает ведение журнала кластера для записи действий контейнеров в центральную подсистему протоколирования. Стандартный вывод и стандартный вывод ошибок каждого контейнера в кластере Kubernetes можно перенаправлять с помощью такого агента, как Fluentd, запущенного на всех узлах, в такие инструменты, как Elasticsearch, и просматривать с помощью Kibana.
Наконец, выполняйте мониторинг контейнеров, подов, приложений, сервисов и других компонентов кластера. Для мониторинга, обзора и трассировки кластера можно использовать такие инструменты, как Prometheus, Grafana и Jaeger.
Те, кто использует сервис Oracle Cloud Infrastructure Container Engine for Kubernetes (также известный как Oracle Kubernetes Engine, или OKE), могут ознакомиться с руководством по безопасности OCI и дополнительными рекомендациями по обеспечению безопасности Oracle Kubernetes Engine. OKE также интегрирован с сервисом Oracle Cloud Infrastructure Identiy and Access Management (OCI IAM), который предлагает дополнительные встроенные средства безопасности для аутентификации с помощью нативной функции идентификации OCI.
