N.B.

• Если желаете перейти сразу к делу, то пропускайте эту главу и переходите сразу к разбору (Руководство по безопасности Kubernetes от NSA),

• Если хотите узнать в двух словах о чем доклад, читайте ниже:

Введение

NSA в соавторстве с еще несколькими организациями подготовила доклад (Kubernetes Hardening Guide) на 59 страниц на тему: Гайд по улучшению безопасности в Kubernetes.

Доклад подготовлен в соавторстве с:

• National Security Agency (NSA) 

• Cybersecurity Directorate 

• Endpoint Security 

• Cybersecurity and Infrastructure Security Agency (CISA)

Интересный момент, в марте 2022 года NSA обновило (первая версия этого гайды была опубликована в 3 августа 2021 и даже в блоге k8s имеется обзор на этот доклад) этот гайд основываясь на фидбеке партнеров и комьюнити. 

Сегодня мы с вами разберем основные моменты обновленной версии этого гида в мир безопасности Kubernetes.

Почему это может быть важно ?

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

Кроме того k8s старается иметь модульную структуру и для полноценной работы ванильного k8s недостаточно. Необходимо добавлять различные ingress, metrics, logging, etc… Как следствия потенциальная поверхность атаки увеличивается. Поэтому важно закрывать уже известные проблемы или потенциально известные вопросы поверхности атаки.

Почему это может быть интересно ?

Это все конечно важно, но почему именно эта заметка может быть мне интересно ?

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

   

2. Доклад содержит действительно дельные советы, про некоторые моменты я узнал впервые.

3. Это не одностороннее мнение NSA о безопасности, этот доклад был написан в соавторстве с другими организациями. Кроме того авторы доклада прислушиваются к мнениям других экспертов (много ли где подобные госструктуры прислушиваются к комьюнити?) из этой области и добавляют изменения в свой доклад.

Немного про NSA

> Из wiki:

NSA Cybersecurity (Агентство Национальной Безопасности USA) - подразделение Министерства обороны США, входящее в состав Разведывательного сообщества США на правах независимого разведывательного органа, занимается радиоэлектронной, научной и технической разведкой, киберразведкой, военной контрразведкой, защитой электронных коммуникационных сетей госучреждений США.

> Еще из интересного:

По числу военнослужащих и вольнонаёмных сотрудников и по размеру бюджета является крупнейшим в США разведывательным ведомством.

Вы наверно удивитесь, но в госучреждениях США также используется оркестратор Kubernetes, поэтому имеет место вопрос безопасности  Kuberenetes.

Давайте уже перейдем к делу и узнаем, что нам рекомендует NSA для достижения максимальной секьюрности в k8s.

Руководство по безопасности Kubernetes от NSA

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

Все руководство разделено на части ниже:

• Безопасность Pod’в.

• Разделение сети на сегменты и улучшение сетевых политик.

• Аутентификация/Авторизация.
  Аутентификация - процесс подтверждения, что этот человек именно тот, за кого себя выдает.
  Авторизация - процесс принятия решения о том, что именно этой аутентифицированной персоне разрешается делать.

• Аудит логов и обнаружение проблем на базе логов.

Кроме этого множество различных примеров и пояснений.

Безопасность Pod’ов

В этом разделе никакого rocket scince как мне кажется, за исключением нескольких моментов про работу с токенами, на которую просто нечасто обращают внимания.

• Non-root: Не используйте юзера с супер-правами (root, etc ...) для работы внутри POD’а.

• Immutable FS:  Не предоставляйте дополнительную возможность изменять файловую систему внутри контейнера. Это полезно, когда кто-то уже проник в ваш контейнер и пытается добавить в ваш контейнер вредоносные инструменты.

Building secure container images: Знай, какие образы используешь в проде.

Если используешь образы построенные на других образах, обязательно сканируй на наличие уязвимостей корневых образов. Лучший вариант конечно использовать свои образы from scratch, тем самым максимально уменьшая радиус атаки.

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

• docker scan nginx

  

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

• Pod Security Admission: Используйте дополнительные политики безопасности, которые приходят на смену PSP (deprecated с версии 1.21, будет удален из ванильного k8s начиная с 1.25).
  В KEP перечислены основные причины, из-за которых пришлось отказаться от PodSecurityPolicy. Об этом также писали в блоге Kubernetes.

• Pod service account tokens: Не всегда контейнерам нужен доступ до стандартного service account, который создается при первичной установке k8s. Суть такова, что стоит максимально ограничить зону работы SA(service account), которые должны выполнять различные задачи. Снова уменьшаем радиус атаки, уменьшаем количество прав.

• Container environments: Различные платформы предоставляют различные типы контейнеризации. Тут обращается внимание, что в большинстве своем контейнеризация не предоставляет должной изоляции как со стороны ресурсов, так и со стороны изоляции доступа, хотя существуют исключения. Знайте свой Container Runtime.

С POD’ми закончили, идем на следующий уровень абстракции.

Разделение сети на сегменты и другие улучшения

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

По умолчанию ресурсы никак не ограничены и доступны между собой, так у любого POD’а есть доступ к любом секрету в любом namespace'е или к любой ноде.

Ключевые моменты касаются 3-х вещей:

• Используйте сетевые политики и брандмауэры для разделения и изоляции ресурсов.

• Защитите свою main (control plane) ноду от неавторизованного доступа.

• Шифруйте трафик внутри кластера, в особенности чувствительную информацию, такую как secrets. По умолчанию трафик внутри кластера не зашифрован.

Namespaces

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

Network policies

Каждый POD получает свой уникальный IP в рамках клаcтера. В  Kuebrenetes имеется возможность настроить правила для получения различных пулов адресов для различных подов и на базе этого создавать дальнейшие политики.
Важно отметить, что различная функциональность зависит от Container Network Interface (CNI).

Resource policies

Для каждого namespace можно определить значения для LimitRanges, ResourceQuotas и ограничения идентификатора процесса и другие. 

Control plane

Если у вас не PaaS, то стоит подумать об обеспечении безопасности вашего командного пункта - control-plane.

1. Настройте шифрование TLS.

2. Настройте надежные методы аутентификации.

3. Отключите доступ к Интернету (или ограничьте) и ненужным или ненадежным сетям.

4. Используйте политики RBAC для ограничения доступа.

5. Защитите хранилище данных etcd с помощью политик аутентификации и RBAC.

6. Защитите файлы kubeconfig от неконтролируемых изменений.

ETCD

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

Etcd может быть запущен на отдельной ноде, что позволяет брандмауэру ограничивать доступ только к API системам k8s.

Kubeconfig Files

Файлы kubeconfig содержат конфиденциальную информацию о кластерах, пользователях,  пространствах имен(namespaces) и механизмах аутентификации.  Поэтому стоит защитить эти файлы от изменений и предоставить доступ только необходимым сервисам.

Worker node

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

Encryption

Рекомендуется шифровать весь трафик внутри кластера, использовать версию TLS 1.2 или TLS 1.3. В более низких версиях имеются критические уязвимости.

Secrets

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

Аутентификация/Авторизация

Authentication

Kubernetes имеет два типа пользователей:

• Учетные записи служб (Service Accounts).

• Обычные учетные записи пользователей (Users).

Service Accounts обрабатывают запросы API от имени модулей. Аутентификация обычно автоматически управляется Kubernetes через ServiceAccount Admission Controller, это работает на базе токенов. 

Для обычных юзеров k8s из коробки ничего не может предложить для аутентификации, поэтому стоит переложить эту работу на плечи 3-rd party сервисов.

Role-based access control

RBAC в ванильном Kubernetes работает из коробки по умолчанию. Эта политика позволяет гранулировать доступ между различными ролями к конкретным ресурсам.

Стоит обратить внимание, что существует 2 типа разграничений:

• Roles - Определение правил доступа внутри одного namespace.

• ClusterRole - это разграничение не учитывает namespace’ы.

Аудит логов и обнаружение проблем на базе логов

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

Основные моменты, на которые необходимо обратить внимание:

• Ведите мониторинг работы кластера, это поможет вовремя анализировать проблемы производительности и находить bottlenecks (проблемные места)

• Ведите логирование на всех уровнях вашей инфрастурктуры (нода, pod, приложение и т.д.)

  • API request history (история доступа к API).

  • Performance metrics (Логирование производительности).

  • Etc ..

• Интегрируйте существующие средства сетевой безопасности для агрегированного сканирования, мониторинга, оповещений и анализа.

• Настройте fault-tolerant policies(политики отказоустойчивости), чтобы предотвратить потерю логов в случае проблем на ноде.

• Включите стандартные политики аудита kuberneetes. По умолчанию они отключены.
  Эти политики помогут понять:

  • Что произошло?

  • Когда это произошло?

  • Etc ….

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

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

Дополнительно, что не вошло в NSA гайд

Существуют внешние утилиты по анализу вашего кластера. На один из таких крайне рекомендую обратить внимание, CIS Benchmarking (The Center for Internet Security - CIS). На самом деле это только набор правил и политик, которые рекомендуется к использованию. Инженеры народ ленивый, но умный, поэтому уже  есть готовые операторы, которые сканируют ваш кластер на предмет удовлетворения k8s политик созданных под крылом CIS.

Например, kube-bench достаточно популярный инструмент-анализатор от Aquasecurity.

Вот так может выглядеть результат сканирования k8s кластера на предмет безопасности:

Заключение

Вот мы и рассмотрели основные моменты рекомендаций NSA. Это руководство дало представление, на что стоит обратить внимание в контексте безопасности по мнению Агентства Национальной Безопасности USA.

Оказывается National Security Agency это не только про шпионов и армию USA. 

Ведь можно что-то продуктивное и полезное создавать, а не только запрещать и вот это всё…

В докладе рассматриваются не только сами рекомендации, но и так же уделено место для вводной части и устройства Kubernetes cluster ecosystem. Кроме этого рассматриваются связи компонентов и поясняется почему важно применять ту или иную практику. Графическая часть доклада позволяет наглядно понять связи между компонентами и сделать правильные умозаключения.

В целом доклад добротно сделан, если вы только ступаете на ступеньку безопасности k8s экосистемы, то однозначно рекомендую к прочтению.

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

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

P.P.S: Если имеются какие-либо пожелания по улучшению\изменению контента или любые другие предложения, то всегда рад расширить свою сеть контактов в Linkedin.com/in/kazakovk или https://github.com/kksudo.

Статья подготовлена в преддверии старта курса "DevOps практики и инструменты".

• Узнать о курсе подробнее