Как повысить безопасность K8S: на основе недавно обновленного руководства по усилению защиты Kubernetes от АНБ

Единственное впечатление от этих шпионских фильмов — сцена, когда агенты АНБ подслушивают переговоры за пределами США. Но это не единственная работа, которую выполняет tон Агентство национальной безопасности. Кроме того, АНБ также вносит свой вклад в сообщество кибербезопасности.

АНБ сделало оригинальный SELinux, необязательный [обязательный контроль доступа] Linux(https://www.nsa.gov/Portals /70/images/resources/everyone/digital-media-center/publications/research-papers/flexible-support-for-security-policies-into-linux-jun2001-report.pdf) (MAC). Кроме того, они написали [рекомендации по обеспечению безопасности видеоконференций, тестирования и инструмента совместной работы] (https://www.zdnet.com/article/heres-the-nsas-guide-for-choosing-a-safe-text-chat- и-видео-конференц-услуги/), пока все работают удаленно. Недавно АНБ обновило Руководство по усилению безопасности Kubernetes, и, таким образом, Я хотел бы поделиться с вами этими замечательными ресурсами и другими рекомендациями по безопасности K8S.

Фон

Первая версия руководства по усилению защиты была выпущена в августе 2021 года под авторством Агентства национальной безопасности (АНБ). Руководство также было написано в соавторстве с [Агентством по кибербезопасности и безопасности инфраструктуры] (https://www.cisa.gov/) (CISA) для информирования пользователей о критических угрозах и конфигурациях для минимизации рисков.

В марте 2022 года АНБ обновило свое [Руководство по усилению безопасности Kubernetes] (https://media.defense.gov/2021/Aug/03/2002820425/-1/-1/0/CTR_Kubernetes_Hardening_Guidance_1.1_20220315.PDF), которое является более ценным. сегодня. Например, [Группа NCC] (https://www.nccgroup.com/us/) сделала несколько замечаний по версии 1.0.

NCC увидел, что информация первой версии об [аутентификации Kubernetes была «в основном неверной]» (https://research.nccgroup.com/2021/09/09/nsa-cisa-kubernetes-security-guidance-a-critical-review/) ”, потому что было заявлено, что Kubernetes не предоставляет метод аутентификации по умолчанию (Факт: K8S изначально поддерживает и аутентификацию с помощью токена, и аутентификацию по сертификату.)

Почему мы должны защищать K8S? Облачный опрос 2021 г.

Согласно [Обзору облачных вычислений 2021 г.] (https://www.cncf.io/reports/cncf-annual-survey-2021/), проведенному [Фондом облачных вычислений] (https://cncf.io/?utm_content =встроенное-упоминание) (CNCF):

• 96% организаций сейчас используют или оценивают Kubernetes.

• 5,6 миллиона разработчиков используют Kubernetes, что составляет около трети всего мира.

Теперь, из этого огромного числа внедрений, как вы думаете, сколько из них должным образом защищают Kubernetes? Немного. Примечательно, что Kubernetes не предлагает «достаточно безопасных» настроек по умолчанию. Как указала Red Hat:

94 % опрошенных признались, что за последние 12 месяцев сталкивались с инцидентами, связанными с безопасностью сред Kubernetes и контейнеров.

Человеческие ошибки или неправильная конфигурация являются серьезной проблемой. Злоумышленники не хуже нас знают, что сейчас мы переходим на контейнеры и Kubernetes, и изменения происходят быстро. Как указывает АНБ, кластеры Kubernetes главной целью кибератак, в том числе:

• кража данных,

• кража вычислительной мощности (например, для криптомайнинга) и

• атаки типа «отказ в обслуживании».
  АНБ и CISA совместное объявление во время выпуска руководства по усилению защиты заявил:

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

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

Уязвимости  — «Наизнанку»

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

Вот список известных уязвимостей, найденных в K8S:

https://www.cvedetails.com/vulnerability-list/vendor_id-15867/product_id-34016/Kubernetes-Kubernetes.html

АНБ и CISA также обращают особое внимание на угрозы цепочки поставок, включая зависимости программного и аппаратного обеспечения, которые могут быть скомпрометированы в цепочке поставок до развертывания  — «даже малейшая ошибка может сломать систему».

Одним из ярких примеров является уязвимость Log4j, которая недавно привела к серьезному сбою. Log4j на самом деле является компонентом не K8S, а Java, который широко используется в приложениях. Как видите, в центре внимания находятся не только уязвимости самого K8S, но и все компоненты внутри кластера.

В Kubernetes нет ничего простого

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

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

Пользователь root (UID 0) является пользователем по умолчанию внутри контейнера. Если вы не укажете пользователя без полномочий root, контейнер будет работать от имени пользователя root. Так как большинство образов контейнеров в общедоступных репозиториях не меняют пользователя root, эта ситуация затягивается.

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

Рекомендации АНБ

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

• [ ] Сканирование на наличие уязвимостей или неправильных конфигураций в контейнерах и подах.

• [ ] Применять принципы наименьших привилегий в контейнерах и подах.

• [ ] Используйте строгую аутентификацию и авторизацию, чтобы ограничить доступ пользователей и уменьшить поверхность атаки.

• [ ] Используйте сегментацию сети, чтобы уменьшить уязвимость в случае взлома.

• [ ] Используйте брандмауэры, чтобы ограничить чрезмерный доступ к сети.

• [ ] Используйте шифрование для защиты конфиденциальности.

• [ ] Регулярно проверяйте все настройки Kubernetes и используйте сканирование уязвимостей для учета допустимых рисков безопасности.

• [ ] Наконец, собирайте и отслеживайте журналы аудита, чтобы предупреждать о потенциальной вредоносной активности.

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

Рекомендации по безопасности K8S

Помимо руководства по усилению безопасности NSA K8S, еще одним полезным ресурсом от NIST является [Руководство по безопасности контейнера приложений] (https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-190.pdf) или SP 800– 190. В этом документе описываются проблемы безопасности, связанные с контейнерами, и предлагаются соответствующие рекомендации.

0# Безопасность контейнеров

Реализация методов безопасности в конвейере CI/CD и во всем процессе сборки, хранения и развертывания образов контейнеров будет включать:

• надежное хранение образов контейнеров,

• сканирование уязвимостей для образов контейнеров и;

• управление/мониторинг безопасности среды выполнения контейнера.

Но если рассматривать только K8S, то нужно что-то более конкретное. В то же время руководство АНБ — отличная отправная точка. И если вы будете следовать руководству и построите свой кластер K8S, он будет достаточно честным и достаточно уверенным, чтобы запустить его в производство. Ниже приведены некоторые другие области, которые необходимо выделить.

1# Управление доступом на основе ролей (RBAC)

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

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

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

(Подробнее см. в официальной документации Kubernetes RBAC.)

2# API – это новая конечная точка

Несмотря на то, что я упоминал в пунктах № 1 и № 2, контроль доступа и безопасность транспорта API Kubernetes, конечная точка API Kubernetes — это еще одна область, с которой нам следует быть осторожными. Администраторы могут настроить конечную точку API кластера Kubernetes как часть частной или общедоступной подсети.

По умолчанию лучше настроить конечную точку Kubernetes API как частную конечную точку. Таким образом, мастер, недоступный из общедоступного Интернета, поскольку конечная точка API внутри плоскости управления имеет частный IP-адрес. Это важно для полностью частных кластеров, которые не имеют общедоступных IP-адресов или не предоставляют их. В результате не будет входящего/исходящего трафика в Интернет и из Интернета.

(Для получения дополнительной информации см. официальную [документацию] (https://kubernetes.io/docs/concepts/security/controlling-access/).)

3# Ключи шифрования (секреты Kubernetes)

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

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

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

Согласно официальному [документу] (https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/), мы также должны убедиться, что SSL/TLS применяется при обмене данными между :

• с сервера API на кублеты и

• пользователи и сервер API.

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

4# Безопасность ОС, Nods и Pods

Чтобы укрепить и обезопасить K8S, мы не можем игнорировать основы  — безопасность ОС, узлов и модулей. Во-первых, [узел] K8S (https://kubernetes.io/docs/concepts/architecture/nodes/) — это рабочий узел, работающий в ОС, которая может быть виртуальной или физической машиной. Службы, работающие на узел включает:

• время выполнения контейнера,

• кубелет и

• куб-прокси.

Чтобы сосредоточить внимание на K8S, Center for Internet Security (CIS) Benchmark Kubernetes является хорошо известным руководством по передовой практике. Все методы обеспечения безопасности на сервере, включая управление уязвимостями, защиту от вредоносных программ, EDR и управление исправлениями, должны быть реализованы на узле.

Помимо безопасности рабочей нагрузки существует риск безопасности внутренних коммуникаций. При необходимости рекомендуется настроить шлюз для доступа за пределы кластера. Доступ к сетевым портам на узлах должен управляться с помощью списков контроля доступа к сети. Также следует рассмотреть возможность ограничения доступа Secure Shell (SSH) к узлам.

С другой стороны, pod — это группа из одного или нескольких контейнеров, работающих на узлах. Итак, изначально нам нужно использовать [сетевые политики] (https://kubernetes.io/docs/concepts/services-networking/network-policies/) для управления связью для модулей внутри кластера. Для этого нам нужен сетевой плагин, реализующий сетевые политики, и для их использования может потребоваться сетевой драйвер, поддерживающий политики.

Сетевую безопасность на уровне пода можно усилить за счет комбинации сетевых политик и списка контроля доступа вплоть до уровня хоста. Кроме того, [контекст безопасности модуля] (https://kubernetes.io/docs/tasks/configure-pod-container/security-context/) K8S поддерживает сопоставление между настройками привилегий и контроля доступа для контейнеров и модулей. (Полный список контекстов безопасности см. в официальном руководстве #securitycontext.

Тем не менее, ядром безопасности модуля должны быть [политики безопасности модуля] (https://kubernetes.io/docs/concepts/policy/pod-security-policy/), которые позволяют пользователю контролировать свойства выполнения модулей во время выполнения. , т. е. возможности запуска контейнеров в качестве привилегированных контейнеров, использующих файловую систему хоста, сеть и порты.

Для получения дополнительной информации см. официальный документ политики безопасности Pod.

Заключительные слова

Ваша конечная цель безопасности — сделать так, чтобы хакерам было как можно сложнее получить доступ к вашим системам; безопасный K8S такой же. И даже если это произойдет, вы должны быть достаточно хороши, чтобы обнаружить аномальную активность и принять меры, чтобы предотвратить ее распространение.

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

Справка:

• https://www.cvedetails.com/product/34016/Kubernetes-Kubernetes.html

• https://www.nsa.gov/Press-Room/News-Highlights/Article/Article/2716980/nsa-cisa-release-kubernetes-hardening-guidance/

• https://kubernetes.io/blog/2016/08/security-best-practices-kubernetes-deployment/

Спасибо за чтение. Да пребудет с вами информационная безопасность🖖.