Безопасность Kubernetes – это практики, инструменты и конфигурации, которые защищают кластеры и рабочие нагрузки Kubernetes от несанкционированного доступа, уязвимостей и угроз во время выполнения. Она предусматривает защиту всех компонентов среды Kubernetes, включая плоскость управления, рабочие узлы, поды, образы контейнеров, сети и хранилища.
Kubernetes создает уникальную поверхность атаки. Ее защита подразумевает контроль доступа к серверу API, применение политик аутентификации и авторизации, защиту данных во время передачи и хранения, а также мониторинг поведения системы для обнаружения аномалий.
Эффективная безопасность Kubernetes также требует защиты цепочки поставки ПО, обеспечения наименьших привилегий для всех пользователей и служб, а также внедрения механизмов защиты при выполнении. Поскольку Kubernetes управляет эфемерными, динамическими контейнерными средами, стратегии безопасности должны быть непрерывными и адаптивными, включая этапы сборки, развертывания и продакшна. Это означает глубокую интеграцию безопасности в пайплайны CI/CD, непрерывное сканирование рабочих нагрузок и автоматизацию применения политик в инфраструктуре.
Почему безопасность Kubernetes так важна?
Последние данные подчеркивают острую потребность в принятии надежных мер безопасности Kubernetes:
- Задержки развертывания из-за проблем безопасности. 67% организаций отложили или замедлили развертывание приложений из-за проблем безопасности в своих средах Kubernetes.
- Воздействие инцидентов безопасности на бизнес. 46% опрошенных организаций понесли потери доходов или клиентов из-за инцидентов безопасности контейнеров и Kubernetes.
- Распространены инциденты безопасности. 58% организаций сообщили, что за последний год сталкивались с инцидентами безопасности, связанными с контейнерами или Kubernetes, причем почти треть из них сталкивалась с несколькими инцидентами.
- Повышенный риск раскрытия. 37% респондентов признали, что им пришлось отложить обновление безопасности или исправления из-за ограниченности ресурсов, что сделало кластеры уязвимыми к известным угрозам.
- Неверная конфигурация как основной риск. Неправильная конфигурация остается основной причиной инцидентов безопасности Kubernetes, о чем указали более половины респондентов, подчеркивая важность надлежащего управления конфигурацией и соблюдения политик.
Эти статистические данные подчеркивают необходимость комплексных стратегий безопасности в средах Kubernetes для предотвращения перебоев в работе, финансовых потерь и ущерба репутации.
Риск безопасности Kubernetes и пайплайн DevOps
Другой способ более конкретно рассмотреть безопасность Kubernetes с точки зрения разработчика – это рассмотреть ее на трех отдельных этапах пайплайна DevOps:
- Создание образа контейнера во время сборки
- Настройка инфраструктуры Kubernetes при развертывании
- Защита сетевой связи в процессе продакшна
Риски безопасности Kubernetes на этапе сборки
Безопасность Kubernetes начинается на этапе сборки при написании кода, который становится образом контейнера. Хотя Kubernetes не обязательно участвует в процессе сборки и упаковки, безопасная среда начинается с оценки рисков, связанных с любым разворачивающимся кодом. Здесь важны лучшие практики безопасности приложений и тестирования, а любые усилия, направленные на shift left в безопасности, принесут дивиденды, позволив избежать будущих проблем при развертывании и продакшне.
На этом этапе необходимо убедиться, что образ контейнера актуален, не содержит уязвимостей безопасности и соответствует лицензионным политикам компании. Контейнеры создаются послойно и часто не имеют канонического списка компонентов с открытым исходным кодом, включенных в окончательную сборку образа контейнера. Чтобы исправить эту проблему, нужно сканировать контейнеры, чтобы определить, какие библиотеки с открытым исходным кодом используются в приложении, охватывающем проверку всех зависимостей, добавленных через менеджера пакетов, такой как Maven или npm.
Выявляя и идентифицируя все используемые компоненты с открытым исходным кодом, есть возможность выявить все известные уязвимости, определить, какие образы подвергаются риску в случае обнаружения новых уязвимостей, и отслеживать лицензии, связанные с конкретными библиотеками. Отслеживание соблюдения лицензионных требований может не представлять риска безопасности, но может иметь последствия. К примеру, раскрытие проприетарного кода, если использована несовместимая лицензия.
Первым шагом к обеспечению безопасности среды Kubernetes является регулярное сканирование базовых образов.
Риски безопасности Kubernetes при развертывании
При развертывании Kubernetes доступен мощный набор средств контроля защиты кластеров и их приложений. Настройка этих средств контроля требует глубоких знаний о Kubernetes, а также требований безопасности развертывания. Не следует использовать стандартные настройки! Это приведет только к ненужному (а возможно даже небрежному) раскрытию информации. Как минимум нужно ограничить объем разрешений пользователей, ограничить прямой доступ к узлам Kubernetes и создать сегментацию сети, чтобы контейнеры взаимодействовали только с теми контейнерами, с которыми они должны.
На этом этапе сканирование остается очень важным. Образы контейнеров должны быть собраны с использованием базовых безопасных образов. Необходимо ввести постоянное сканирование уязвимостей безопасности и регулярно применять обновления безопасности в среде. Сканирование не является однократным событием. Кроме того, при запуске контейнеров в среде Kubernetes следует использовать только образы из реестров находящихся в списках разрешенных образов.
Риски безопасности Kubernetes в продакшне
Безопасность приложений при выполнении значительно отличается от безопасности на этапе сборки. В частности, сетевая безопасность сложнее. Лучшие практики сетевой безопасности в Kubernetes выходят за пределы базовой сетевой инфраструктуры и используют контейнерный сетевой интерфейс (container network interface, CNI) для внедрения более надежного сетевого уровня, включающего поддержку многопользовательских сред, сетевые политики или и то и другое.
В многопользовательской сети каждое пространство имен в кластере Kubernetes получает частную адресованную подсеть и может получать доступ только к подам в других пространствах имен, специально открытых как службы. Open vSwitch – отличный пример сетевого уровня для Kubernetes, поддерживающего многопользовательскую работу.
Сетевые политики в большинстве сетевых слоев нового поколения доступны для развертывания через Kubernetes. Project Calico является примером широко используемого сетевого слоя, созданного с нуля для поддержки сетевых политик с контейнерами. Сетевые политики позволяют администраторам кластеров заранее определять списки контроля доступа к сети, которые контролируют, какие порты доступны и к каким службам можно получить доступ.
10 лучших практик безопасности Kubernetes
Вот самые лучшие практики, которые помогут улучшить состояние безопасности кластеров Kubernetes.
1. Сканирование изображений
Сканирование изображений необходимо для обнаружения уязвимостей в контейнерных изображениях перед их развертыванием в производственных средах. Современные контейнерные образы часто базируются на слоях программного обеспечения с открытым кодом, каждый из которых может содержать уязвимости. Такие платформы, как Mend, можно интегрировать в CI/CD-пайплайны для автоматического обнаружения известных CVE (Common Vulnerabilities and Exposures), устаревших пакетов, неправильных настроек и рискованных лицензий на программное обеспечение. Такое сканирование не должно быть одноразовой деятельностью, а должно быть частью процесса непрерывной интеграции и доставки, чтобы выявлять регрессии и вновь обнаруженные уязвимости.
Кроме рисков безопасности, сканирование образов может помочь обеспечить соблюдение политик, гарантируя, что в продакшн допускаются только образы, созданные на основе утвержденных базовых образов и известных компонентов. Подписи и аттестации образов контейнеров можно использовать для проверки целостности и происхождения образов, предотвращая попадание в кластер поддельных или ненадежных образов. Ведение списка компонентов программного обеспечения (SBOM) также обеспечивает прослеживаемость, помогая командам быстро оценивать и уменьшать риски, когда в зависимостях верхнего уровня обнаруживаются новые уязвимости.
2. Ввод контроля доступа на основе ролей (RBAC)
Контроль доступа на основе ролей (RBAC) – это функция Kubernetes, позволяющая администраторам определять, какие пользователи или службы могут получать доступ к каким ресурсам и каким образом. Присваивая пользователям роли на основе их обязанностей и привязывая эти роли к конкретным пространствам имен или ресурсов, уменьшается риск чрезмерных разрешений для учетных записей и минимизируется влияние скомпрометированных учетных данных. Стандартные роли, такие как cluster-admin, следует использовать с осторожностью, а разработчикам следует предоставлять минимальный доступ, необходимый для выполнения их задач.
Политики RBAC следует регулярно пересматривать, особенно после изменений в структуре команд, развертываниях или инцидентах безопасности. Такие инструменты, как rbac-lookup, rakkess и Kubernetes Policy Controller могут помочь визуализировать и проверить конфигурации RBAC. Сочетая RBAC с другими механизмами контроля доступа, такими как изоляция пространства имен и сетевые политики, организации могут построить стратегию глубокой защиты, которая значительно усилит их безопасность в Kubernetes.
3. Использование аутентификации сторонних разработчиков для API-сервера
Интеграция Kubernetes с внешним поставщиком идентификации (IdP) с помощью OpenID Connect (OIDC) позволяет централизовать проверку подлинности и улучшить управление пользователями. Это упрощает внедрение политик безопасности, таких как многофакторная проверка подлинности (MFA), единый вход (SSO) и отмена доступа пользователей. Популярные IdP, такие, как Okta, Auth0, Azure AD и Google Identity обеспечивают масштабируемое управление идентификацией, поддерживающей требования аудита и соответствия.
Использование сторонней аутентификации также устраняет необходимость непосредственного управления учетными данными пользователей в кластере, что уменьшает риск неправильного управления или распространения учетных данных. При правильной интеграции сервер API Kubernetes использует токены, выданные IdP, а политики RBAC могут применяться на основе членства в группе идентичности. Это упрощает согласование доступа к Kubernetes с корпоративными IT-стандартами и улучшает отслеживание действий пользователей с помощью централизованных журналов.
4. Защита etcd с помощью TLS и фаервола
База данных etcd является центральным хранилищем всех данных кластера, включая конфигурации, секретные и учетные данные. Несанкционированный доступ к etcd может привести к полной компрометации кластера. Чтобы защитить etcd, следует зашифровать коммуникацию с помощью TLS и включить аутентификацию клиентов с помощью сертификатов. Это гарантирует, что только доверенные компоненты могут взаимодействовать с хранилищем данных. Таким образом можно предотвратить атаки man-in-the-middle или утечки данных.
Кроме шифрования, etcd следует изолировать от сети с помощью фаерволов или групп безопасности, чтобы разрешить доступ только с сервера API Kubernetes. Следует избегать выставления etcd в публичных сетях или ненадежных сегментах. Также очень важно включить шифрование данных etcd в состоянии покоя и обеспечить регулярное создание и безопасное хранение зашифрованных резервных копий. Периодическое тестирование процесса восстановления также необходимо для обеспечения непрерывности бизнеса при повреждении или потере данных.
5. Изоляция узлов Kubernetes
Изоляция узлов помогает снизить радиус поражения в случае инцидента безопасности. Используя Kubernetes taints и tolerations, администраторы могут назначать конкретные рабочие перегрузки определенным группам узлов. Например, рабочие нагрузки, имеющие публичный доступ, можно планировать на узлах без доступа к внутренним базам данных или API, что минимизирует риски перекрестного заражения. Аналогично, чувствительные рабочие нагрузки, такие как платежные услуги, можно изолировать от общего назначения для повышения безопасности.
Облачные провайдеры предлагают такие механизмы, как подсети, VPC и группы безопасности, которые можно использовать для дальнейшей изоляции групп узлов. Они могут применять правила фаервола, предотвращающие несанкционированный доступ между различными классами узлов или между узлами и Интернетом. Внедрение изоляции узлов вместе с сегментацией сети и политиками сервисной сетки может обеспечить многоуровневую модель безопасности, устойчивую к разветвленным атакам и повышению привилегий.
6. Мониторинг сетевого трафика для ограничения коммуникаций
По умолчанию сеть Kubernetes позволяет всем подам взаимодействовать между собой, что создает ненужный риск в случае компрометации. Внедрение сетевых политик Kubernetes ограничивает коммуникацию между подами, службами и неймспейсами. Политики могут применяться с помощью плагинов CNI, таких как Calico, Cilium или Weave, которые позволяют администраторам определять четкие правила относительно того, какие службы могут взаимодействовать между собой.
Постоянный мониторинг сетевого трафика необходим для выявления неправильных настроек, потенциальных вторжений или аномального поведения. Такие инструменты, как Istio, Linkerd или коммерческие service mesh-решения, предлагают функции наблюдения, такие как отслеживание трафика, показатели задержки и регистрация доступа. Эти инструменты могут помочь точно настроить политики и быстро выявлять нарушения безопасности, что позволяет командам реагировать, прежде чем злоумышленники проникнут глубже в кластер.
7. Использование списка разрешенных процессов
Список разрешенных процессов ограничивает контейнеры только некоторыми, предварительно определенными программами или системными вызовами. Это ограничивает возможности злоумышленника касательно использования контейнера, даже если он скомпрометирован. Такие технологии, как AppArmor, Seccomp и SELinux позволяют администраторам определять эти ограничения в виде политик или профилей. К примеру, профиль Seccomp может блокировать использование определенных системных вызовов Linux, значительно уменьшая площадь атаки контейнера.
Обеспечение соблюдения требований на уровне процессов помогает предотвратить злоупотребление контейнерными средами для таких действий, как майнинг криптовалют, запуск обратных оболочек или повышение привилегий. В отличие от традиционных антивирусных программ или средств обнаружения конечных точек, эти механизмы на уровне ядра работают с минимальным влиянием на производительность и очень эффективны в средах с ограниченными ресурсами, таких как контейнеры.
8. Включение аудиторского журналирования
Аудиторское журналирование в Kubernetes регистрирует все взаимодействия с API-сервером, обеспечивая видимость того, кто получил доступ к каким ресурсам и какие действия были выполнены. Это имеет решающее значение для анализа инцидентов, реагирования на инциденты и соблюдения требований соответствия, таких как HIPAA или PCI DSS. Аудиторские журналы можно настроить так, чтобы они включали такие события, как чтение, запись или отказ в доступе, и фильтровать их по неймспейсам, ролям пользователей или типам ресурсов.
Журналы должны собираться и храниться в безопасной, централизованной системе. Это позволяет осуществлять корреляцию журналов, выявление угроз и долгосрочное архивирование. Регулярный просмотр журналов аудита может помочь выявить подозрительное поведение, такое как попытки повышения привилегий или несанкционированный доступ к конфиденциальным ресурсам, и является ключевым компонентом любой проактивной стратегии мониторинга безопасности.
9. Обновление версии Kubernetes
Каждая версия Kubernetes содержит исправление известных уязвимостей и улучшение функций безопасности. Использование устаревших версий подвергает кластер рискам, о которых знают злоумышленники и которые они активно используют. Kubernetes поддерживает быстрый цикл выпуска обновлений, и организации должны соблюдать структурированный процесс обновления, чтобы оставаться в курсе последних изменений, минимизируя время простоя и перебои в работе.
Перед обновлением всегда следует тестировать новые версии в тестовой среде, чтобы выявить проблемы совместимости с рабочими нагрузками или интеграциями сторонних разработчиков. Можно использовать такие инструменты, как kubeadm, или полагаться на управляемые службы, автоматизирующие часть процесса обновления. Быть в курсе последних изменений также означает следить за устаревшими API и изменениями стандартного поведения, которые могут повлиять на производительность или доступность приложений, если их не исправить.
10. Блокировка kubelet
Kubelet – это мощный компонент, управляющий операциями жизненного цикла пода на каждом узле. Он предоставляет REST API, который может использоваться злоумышленниками, если не обеспечить надлежащую защиту. По умолчанию kubelet разрешает доступ к конечным точкам /exec, /logs и /metrics, которые могут быть использованы для просмотра журналов или ввода команд в запущенные контейнеры. Выключение анонимного доступа и включение аутентификации и авторизации – это важнейшие первые шаги по блокированию kubelet.
Кроме того, следует ограничить доступ к API kubelet, привязав его к 127.0.0.1 или защитив фаерволом. Следует избегать использования флажков с чрезмерными разрешениями, таких как –read-only-port, и регулярно проверять конфигурации kubelet. Также рекомендуется включить настройки безопасности kubelet, такие, как –tls-cert-file, –authentication-token-webhook и –authorization-mode=Webhook, чтобы обеспечить проверку идентичности и контроль доступа для входящих запросов.
Улучшение безопасности Kubernetes с помощью Mend.io
Гарантия безопасности развернутых в Kubernetes приложений требует комплексного подхода, эффективно использующего безопасность контейнеров во всем цикле разработки программного обеспечения (SDLC). Интеграция Mend.io с Kubernetes обеспечивает видимость потенциальных рисков путем сканирования уязвимостей в образах контейнеров:
- Доступность контейнеров определяет, какие уязвимые файлы и методы вызываются при выполнении без необходимости использования агентов выполнения, что позволяет безопасно снизить приоритет более недоступных уязвимостей.
- Безопасность от разработки до развертывания обеспечивает защиту на протяжении всего цикла разработки программного обеспечения. Она начинается со сканирования статических образов в пайплайне и продолжается анализом поведения контейнеров на предмет риска безопасности во время выполнения.
- Обнаружение “секретов” идентифицирует открытые учетные данные, пароли, ключи и сертификаты в образе, удовлетворяя критическую потребность в защите конфиденциальных данных.
- Сканирование кластеров Kubernetes без труда сканирует все запущенные образы контейнеров в кластерах Kubernetes. Таким образом, облегчается поиск и маркировка контейнеров, которые активно используются и развернуты.
