А если проще, 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 в целом могут привести к серьезным негативным последствиям, если, конечно, вы не исправите их вовремя.