.webp)
.webp)
Kubernetes стал незаменимым инструментом для оркестровки, масштабирования, автоматического развертывания и управления контейнеризованными приложениями.
А если проще, Kubernetes – это система, которая обеспечивает совместную работу различных приложений на разных компьютерах.
Следует отметить, что эта система, как правило, работает именно с контейнеризованными приложениями, такими как образы Docker. Строго говоря, это тип виртуализации, при котором приложения запускаются в изолированных пользовательских пространствах, которые называются контейнерами.
Проблемы безопасности контейнеров
То, как приложение будет работать и взаимодействовать с другими приложениями и внешним миром, определяет пользователь. А все, что предполагает вмешательство человека, подвержено появлению дефектов и ошибок.
Серьезность ошибки напрямую зависит от навыка человека, который управляет контейнерами. Иногда даже самая несерьезная ошибка может сломать всю систему. Один из самых ярких примеров – уязвимость в Java под названием Log4j, которая совсем недавно привела к серьезному сбою по всей сети Интернет.
Как правило, программное обеспечение/приложение не защищено от злоумышленников на 100%, это просто невозможно. Но нельзя ошибочно полагать, что наличие утечек и уязвимостей – это нормально, и надеяться на то, что их никто не обнаружит.
Искать уязвимости безопасности и дефекты нужно всегда. Кроме того, по мере возможности их необходимо устранять.
Дефекты могут сделать кластер или контейнер уязвимыми, а это, в свою очередь, может позволить неавторизованным лицам воспользоваться ими в своих целях. А учитывая тот факт, что популярность Kubernetes только растет, нам необходимо более серьезно подумать о том, как оценить его действенность и решить проблемы безопасности конвейеров.
Дабы вы смогли лучше организовать защиту ваших конфигураций и программ Kubernetes, давайте рассмотрим несколько распространенных уязвимостей, а также изучим рекомендации по обеспечению безопасности Kubernetes.
Необходимость выбора конфигурации
Если вы только начали знакомиться с Kubernetes, но при этом пытаетесь развернуть проект самостоятельно, вам может быть сложно разобраться в правилах конфигурации безопасности. Это происходит потому, что Kubernetes в таких случаях, к сожалению, не предоставляет правил конфигурации по умолчанию, которых было бы достаточно для обеспечения безопасности.
Несмотря на то, что конфигурация безопасности не так важна на начальных этапах, позже, когда вы перейдете к более поздним этапам развертывания в производственной среде, она станет критичной.
Аналогичная проблема существует и с тем, как взаимодействуют друг с другом модули. Эти права на «общение» определяются сетевыми политиками, но по умолчанию такие политики не имеют отношения к модулям. И снова, это, то, что вам придется настроить самостоятельно.
Для решения этой проблемы есть простой обходной путь – обеспечить ролевое управление доступом (RBAC - Role-Based Access Control) для того, чтобы понимать, кто имеет доступ к API и какие права доступа у них есть.
Для того, чтобы повысить безопасность по части считывания объектов и уровня привилегий, вы можете воспользоваться такими атрибутами, как allowPrivilegeEscalation и readOnly.
Следующая политика демонстрирует, какие уровни полномочий есть у пользователя «bob»:
{
"apiVersion": "abac.authorization.kubernetes.io/v1beta1",
"kind": "Policy",
"spec": {
"user": "bob",
"namespace": "projectCaribou",
"resource": "pods",
"readonly": true
}
}В данном случае пользователь «bob» может только считывать объекты из пространства имен «projectCaribou».
Если бы запрос имел тип «write» или «update», то действие было бы отклонено.
Вредоносный код в образах Docker
Так как Kubernetes зачастую работает с контейнеризованными приложениями, как правило, с образами Docker, чаще всего злоумышленники проникают в кластер или узел, получая доступ из этого самого контейнеризованного приложения.
Конечно, существует большое количество решений для предотвращения различных типов атак, но для того, чтобы предотвратить DoS-атаки, вы всегда можете просто ограничить использования ресурсов памяти.
Это можно сделать, настроив Ingress-контроллер. Этот контроллер будет ограничивать количество запросов за определенный период времени, например, он поставить ограничение на 10 запросов в секунду или 1000 запросов в минуту.
Реализовать такой подход можно, ограничив количество запросов на IP-адрес клиента или ограничив запросы на уровне узла службы.
Или же вы можете определить список для контроля доступа, чтобы запросы могли отправлять только определённые выбранные вами IP-адреса. В таком случае вы гарантируете, что никакой трафик анонимных запросов не перегрузит сервер, а также, что сервер будет обрабатывать трафик/запросы только из надежных источников.
Кроме того, вы можете сканировать приложения перед тем, как его развертывать. Это также является отличной практикой для обнаружения и немедленного устранения вредоносного кода.
Кластер безопасен, а передача данных – нет
В большинстве случаев приоритет отдается именно безопасности кластера, так как именно он управляет приложениями. Но есть одна вещь, о которой многие забывают – по умолчанию нет никаких мер безопасности и шифрования передачи данных.
Это довольно распространенная проблема, и, если вы будете ее игнорировать, то злоумышленники смогут получить несанкционированный доступ к вашей системе. Это значит, что обеспечивать взаимодействие служб в кластере должен протокол TLS (протокол защиты транспортного уровня).
Сетевые технологии развиваются, и это привело к появлению таких продуктов, как LinkerD, которые могут поддерживать протокол TLS по умолчанию. Кроме того, они предоставляют дополнительную телеметрическую информацию о взаимодействии служб.
Аналогичный принцип применяется и к «etcd», где хранится состояние кластера. Если вы оставите эту базу данных незащищенной, то она может стать привлекательной целью для злоумышленников, так как в случае удачной атаки злоумышленник сможет захватить весь кластер. Даже если у них будет доступ только для чтения, они смогут злоупотребить им, чтобы повысить свои привилегии.
Контроль времени выполнения
Даже если вы успешно справитесь с уязвимостями, связанными с политикой и конфигурацией, на вашем пути могут появится дополнительные препятствия во время выполнения. Один из примеров уязвимости, связанной с безопасностью во время выполнения, является взломанный контейнер, в котором запускаются различные вредоносные процессы.
Конечно, майнинг криптовалют стал довольно популярной целью для злоумышленников, которые пытаются вмешаться в настройки контейнера, но они могут выполнять и другие вредоносные действия, например, они могут сканировать сетевые порты для того, чтобы получить доступ к нужным ресурсам из скомпрометированного контейнера.
Для того, чтобы справиться с проблемами, возникающими во время выполнения, вы можете постоянно отслеживать активность выполнения критических с точки зрения безопасности контейнеров, например, активность процессов и передачу данных по сети.
Кроме того, настоятельно рекомендуется учитывать информацию о времени сборки и развертывания для того, чтобы вы могли сравнить наблюдаемую и ожидаемую активность во время выполнения. Таким образом, обнаружить любое нестандартное поведение будет намного проще.
Несоответствие стандартам
Соблюдать стандарты безопасности, нормативные требования и нормы, а также внутренние правила организации в облачных системах может быть не так просто.
Самая распространенная причина несоблюдения требований – игнорирование аспекта безопасности в процессе внедрения контейнера.
Лучший способ устранить такие уязвимости – принять все необходимые меры безопасности еще на ранних этапах жизненного цикла контейнера. Также неплохой практикой для сокращения накладных расходов считается автоматизация всех необходимых проверок (насколько это возможно).
Заключение
Безопасность – важный компонент контейнерных технологий, и это то, что обязательно нужно учитывать и внедрять при работе с Kubernetes.
Все-таки ваша конечная цель должна заключаться в том, чтобы помешать злоумышленникам получить доступ к вашим системам. А если им все-таки удастся это сделать, инфраструктура должна быть настолько хорошей, чтобы обнаружить аномальную активность и предотвратить ее распространение.
Как говорит Рори МакКьюн – главный эксперт по безопасности в NCC Group:
«Kubernetes – сложная система, и при ее настройке очень легко допустить ошибку».
Уязвимости контейнеров и Kubernetes в целом могут привести к серьезным негативным последствиям, если, конечно, вы не исправите их вовремя.
