Рекомендации по безопасности Kubernetes: подробное руководство

Введение

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

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

Узлы предоставляют ЦП, память, хранилище и сетевые ресурсы, на которых мастер Kubernetes может размещать POD микросервисов. Узлы содержат различные компоненты, такие как Kubelet, Kube-Proxy и среду выполнения контейнера, которые помогают Kubernetes запускать и отслеживать рабочие нагрузки приложений.

Рекомендации по безопасности Kubernetes: модель 4C

При построении стратегии глубокоэшелонированной защиты необходимо предусмотреть многочисленные барьеры безопасности в различных областях; облачная безопасность работает аналогично и предлагает использовать тот же подход. Методы безопасности Cloud Native Systems разделены на четыре разных уровня, которые называются «моделью безопасности 4C»: облако, кластер, контейнер, код. Работа со всеми этими уровнями обеспечивает комплексную защиту от разработки до развертывания. Лучшие практики для Kubernetes также можно разделить на эти четыре категории облачного подхода.

Облако

Облачный уровень относится к серверной инфраструктуре. Настройка сервера у вашего любимого поставщика облачных услуг включает в себя различные службы (CSP). В то время как CSP несут основную ответственность за защиту таких услуг (например, операционной системы, управления платформой и конфигурации сети), клиенты по-прежнему несут ответственность за мониторинг и защиту своих данных.

Запретить доступ к серверу KubeAPI

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

В идеале для соединений с сервером API, внутренней связи в плоскости управления и связи между плоскостью управления и Kubelet следует использовать только соединения TLS. Это можно сделать, предоставив сертификат TLS и файл закрытого ключа TLS на сервер API с помощью параметра командной строки сервера kube-API. 

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

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

Шифрование и брандмауэр

«Секреты» в Kubernetes — это объекты, используемые для хранения конфиденциальной информации о пользователях, такой как пароли, ключи, токены и многие другие типы информации. Они ограничивают используемую поверхность атаки. Кроме того, они обеспечивают гибкость жизненного цикла модулей, позволяя им получать доступ к конфиденциальным данным. Секреты — это объекты с именами (максимальная длина: 1 МБ), которые хранятся в файлах tmpfs на узлах и защищены паролем.

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

Для правильной работы Kubernetes организация должна включить брандмауэры и открыть некоторые порты. Например, определенные порты должны быть открыты в первичной конфигурации. К ним относятся 6443, 2379-2380, 10250, 8472 и многие другие. Кроме того, на рабочих узлах должны быть открыты несколько портов, включая порты 10250, 10255 и 8472.

Внедрение TLS между компонентами кластера

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

Защитить узлы

Те, кто отвечает за работу ваших контейнерных приложений, называются узлами. Из-за этого важно обеспечить узлы безопасной средой. Например, один сервер, выступающий в качестве главного и рабочего узла для кластера, может протестировать Kubernetes в тестовой среде. Хотя для конкретных приложений может потребоваться более трех, в большинстве из них используется как минимум три: один для главных компонентов, один для рабочих узлов и один для администрирования kubelet.

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

Изолируйте кластер и API с помощью правильных конфигураций

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

Контейнеры, модули, узлы и кластеры — это лишь некоторые из уровней изоляции, доступных в Kubernetes. Благодаря использованию DNS для каждого кластера кластеры могут обеспечить большую сетевую изоляцию. Можно запустить модуль с отдельным идентификатором и получить доступ к ресурсам, требуемым модулями, если используется набор узлов. Использование правил брандмауэра может обеспечить изоляцию в модулях. Поды обеспечивают изоляцию с помощью сетевой политики, определяя, каким подам разрешено взаимодействовать друг с другом. Изоляция рабочих узлов имеет жизненно важное значение, поскольку она помогает предотвратить обмен данными между пространствами имен, а также если администратор желает ограничить развертывание модуля определенной группой узлов.

Серверы API не должны быть доступны из общедоступного Интернета или многих источников, поскольку это увеличивает поверхность атаки и вероятность компрометации. Однако с помощью правил контроля доступа на основе правил, чередования ключей, предоставляемых пользователям, и ограничения доступа из IP-подсетей можно ограничить риск.

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

Кластер

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

Использование секретов Kubernetes для учетных данных приложения

Как упоминалось ранее, секрет — это объект, содержащий конфиденциальные данные, такие как пароль или токен, которые можно использовать для аутентификации учетной записи. Важно знать, где и как хранятся и доступны конфиденциальные данные, такие как пароли и ключи. Модуль не может читать секреты, но это не отменяет важности сохранения секретности в отдельном месте. В противном случае к секрету может получить доступ любой, у кого есть копия образа. Те приложения, которые обрабатывают несколько процессов и доступны для широкой публики, особенно уязвимы. Секреты не должны передаваться как переменные среды, а вместо этого должны монтироваться как тома только для чтения в ваших контейнерах.

kubectl создать секретный универсальный dev-secret –from-literal=’username=my-application’ –from-literal=’password=anything123′

Применить наименьшие привилегии при доступе 

Источник

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

Авторизация RBAC использует группу API rbac.authorization.k8s.io для принятия решений об авторизации, что позволяет изменять политики на лету. Для активации RBAC требуется установить флаг авторизации в список, разделенный запятыми, который содержит RBAC, а затем перезапустить сервер API.

Рассмотрим следующую иллюстрацию. Как роль в пространстве имен «по умолчанию», он предоставляет модули только для чтения.

Используйте контроллеры доступа и сетевую политику

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

Контроллеры доступа могут улучшить безопасность, потребовав подходящего базового уровня безопасности для всего пространства имен или кластера компьютеров. В этом отношении встроенный контроллер доступа PodSecurityPolicy, вероятно, является наиболее ярким примером; его можно использовать, чтобы предотвратить работу контейнеров с правами root или гарантировать, что корневая файловая система контейнера постоянно смонтирована только для чтения, среди прочего. Также доступен контроллер веб-перехватчика, который позволяет извлекать изображения исключительно из определенных реестров, известных организации, и ограничивает доступ к незнакомым реестрам изображений. Контроллеры веб-перехватчиков также могут отклонять развертывания, не соответствующие стандартам безопасности. 

Контейнер

Механизмы выполнения контейнера необходимы для запуска контейнера в кластерной среде. Docker, безусловно, является наиболее распространенной средой выполнения контейнеров (CRE) для использования с Kubernetes. Кроме того, он уже содержит множество образов, которые разработчики могут использовать для настройки всего, от серверов Linux до серверов Nginx.

Используйте проверенные изображения с правильными тегами

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

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

Вы также можете установить процесс сканирования изображения на CI; сканирование образа — это процесс, при котором содержимое образа контейнера и процесс сборки проверяются на наличие уязвимостей, CVE или неправильных практик. Поскольку он включается в конвейер CI/CD, он может предотвратить попадание уязвимостей в реестр. Кроме того, он защитит реестр от любых уязвимостей, вызванных сторонними образами, используемыми в конвейере.

Вполне возможно, что образ, который вы сканируете, не имеет тех же зависимостей или библиотек, что и образ, который вы развертываете в своем кластере Kubernetes. Если это так, вам нужно будет сканировать снова. Кроме того, при использовании тегов, таких как «последний» или «промежуточный», может быть трудно определить, действительны ли самые последние результаты сканирования из-за тегов.

Использование изменяемых тегов может привести к тому, что контейнеры будут содержать разные версии одного и того же изображения из одного и того же изображения при использовании тегов. В дополнение к проблемам безопасности, выявленным в результатах сканирования, это может привести к проблемам, которые трудно устранить. Поэтому по возможности используйте неизменяемые теги, такие как nginx:deploy-082022, чтобы определить, было ли развернуто приложение и какой образ использовался.

Ограничение привилегий приложений

Источник

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

Изучите такие задачи, как установка программных пакетов, запуск служб, создание пользователей и другие подобные действия. Для разработчиков приложений это создает несколько проблем. Кроме того, при запуске приложений на виртуальной машине не следует запускать их от имени пользователя root, чтобы избежать угроз безопасности. Точно так же это верно и в случае с контейнерами.

Если кто-то получит доступ к контейнеру, пользователь root получит доступ и выполнит что-либо на базовом хосте, как если бы они вошли в систему как пользователь root. Риск этого включает в себя:

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

Код

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

Сканировать на наличие уязвимостей

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

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

Что такое безопасность Kubernetes?

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

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

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

Важность безопасности Kubernetes

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

Если кто-то скомпрометирует установку Kubernetes, это может привести к компрометации большого количества узлов, на которых могут работать разные микросервисы. Таким образом, это представляет угрозу для организации и может повлиять на ее повседневную деятельность. Например, существует два хорошо известных типа CVE, один из которых — CVE-2022-0185 (целочисленное недополнение). Этот CVE, обнаруженный Уильямом Лю и Джейми Хилл-Дэниелом в 2022 году, показывает, как злоумышленник может использовать несвязанную функцию записи для изменения памяти ядра и доступа к любым другим процессам, работающим на этом узле. 

Внедрение лучших практик безопасности Kubernetes

Обновления безопасности для среды

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

Контекст безопасности

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

Управление ресурсами

Каждому поду доступно несколько типов ресурсов, включая ЦП и память, необходимые для выполнения контейнеров. Итак, чтобы объявить под, мы должны сначала указать, сколько ресурсов мы хотим выделить каждому контейнеру. Указывается запрос ресурсов для контейнера в модуле, и Kube-Scheduler использует эту информацию, чтобы определить, на каком узле следует разместить модуль, чтобы наилучшим образом использовать ресурсы. После своего планирования контейнер не сможет потреблять какие-либо ресурсы сверх тех, которые были выделены ему системой. Вы должны сначала посмотреть, как обрабатываются запросы, прежде чем назначать ресурсы контейнерам. Только после завершения наблюдения вы можете предоставить ресурсы, необходимые для контейнеров.

Сдвиг влево

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

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

Платформы безопасности Kubernetes: обзор

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

Тест CIS предоставляет различные методы и управление конфигурацией, с помощью которых мы можем усилить безопасность и конфигурацию кластера Kubernetes. В соответствии с названием MITRE ATT&CK предоставляет различные варианты или сценарии, с помощью которых злоумышленник может атаковать среду и воспользоваться ими. Он также определяет различные методы, с помощью которых мы можем исправлять уязвимости или проблемы с конфигурацией, необходимые для защиты всей среды. Вы можете использовать PCI-DSS для среды Kubernetes для реализации конфигураций, связанных с соответствием, которые необходимы для среды — это обычно используется в целях финтеха. Существует множество различных фреймворков, которые вы можете использовать для выполнения множества задач.

Вывод

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

Статья является переводом www.armosec.io