Автор: Эндрю Мартин (ControlPlane)nС момента создания проекта безопасность Kubernetes продвинулась далеко вперед, но в ней и сейчас можно найти некоторые подводные камни. Начиная с control plane, продолжая рабочими нагрузкам и безопасностью сети, и заканчивая прогнозом безопасности в будущем, ниже приведены советы, которые при возникновении угрозы способствуют укреплению кластеров и помогут им стать более устойчивыми.nnПлан статьи:n
- Control Plane (CP)n
- TLS повсеместно.
- Используйте RBAC с включенными минимальными привилегиями, отключите АВАС и промониторьте логи
- Необходимо прибегнуть к сторонней аутентификации API сервера
- Отделите кластер etcd и защитите его с помощью брандмауэра
- Для ключей шифрования осуществляйте чередование
- Рабочие нагрузкиn
- Применяйте функций обеспечения безопасности Linux и PodSecurityPolicies
- Проведите статический анализ для YAML
- Запустите контейнеры в качестве пользователя без root полномочий
- Применяйте Network Policies
- Просканируйте образы и после запустите IDS
- Чего ждать в будущемn
- Запускайте Service Mesh
- Заключение
Control Plane (CP)
CP является мозговым центром Kubernetes. В нем содержится информация относительно всякого пода, контейнера, что работают в кластере, кроме того он способен планировать новые поды (включая контейнеры, имеющие корневой доступ к родительскому узлу) и считывать абсолютно все хранящиеся в рамках кластера секреты.nnЭтому ценному компоненту нужно обеспечить протекцию от непредвиденной утечки и мошенничества: при обращении к нему, при бездействии и во время его передачи по сети.n
Повсеместный TLS
TLS нужно активизировать для каждого из поддерживающих его компонентов – с целью предотвращения перехвата трафика, проверки идентичности сервера и (для взаимного TLS) проверки личности клиента.nnСтоит отметить, что часть компонентов и способов установки могут активизировать локальные порты для HTTP, зная это, администраторам следует изучить параметры каждого из компонентов для определения потенциально незащищенного трафика.nnЛукас Колдстрим создал диаграмму, которая указывает, где оптимально следует применять TLS, а именно: на самом мастере между каждым из его компонентов, а также между Kubelet и API сервером. Работа «Kubernetes The Hard Way» автора Келси Хайтауэр, который уже считается классикой, вместе с документацией модели безопасности etcd предоставляют подробные руководства.nnАвтомасштабирование узлов Kubernetes было исторически затруднено, так как во время подключения к мастеру для каждого отдельного узла запрашивается ключ TLS, и в базовых образах хранить секреты крайне нежелательно. При помощи Kubelet TLS bootstrapping обновленный Kubelet может формировать запрос на подпись сертификата для генерации сертификатов в процессе загрузки.n
Используйте RBAC с включенными минимальными привилегиями
Отключите АВАС (управление доступом на основе атрибутов) и проводите мониторинг логовnПрименением RBAC (управление доступом на основе ролей) обеспечивается гранулированное управление политиками доступа пользователей к ресурсам, например, к пространству имен.nnВ Kubernetes систему ABAC заменили на RBAC с выпуска 1.6 и её необходимо деактивировать на сервере API. Альтернативой является использование RBAC:nИли используйте указанный флаг для GKE:Можно найти много успешных применений политик RBAC для кластерных служб, и кроме этого — документация. Не останавливайтесь на достигнутом — гранулированные политики RBAC могут быть получены посредством audit2rba из логов audit.nnНекорректные или же чрезмерно разрешающие политики RBAC являются угрозой для безопасности, если дойдет до скомпрометированности пода. Поддержание низких привилегий, непрерывный аудит и совершенствование правил RBAC следует рассматривать как элемент «гигиены долга кодинга», и эта «гигиена» должна встраиваться командами в их жизненный цикл разработки.nnAudit Logging (версия 1.10) обеспечивает оптимизируемое API логирование для рабочих нагрузок (к примеру, запрос — ответ), и на уровне метаданных. Можно настроить уровни логирования согласно политики безопасности вашей компании — GKE предлагает рациональные изначальные значения для новичков.nnПри запросах чтения, например, get, list и watch, в аудит логах будет сохраняться лишь объект запроса, а объект ответа — нет. При запросах, включающих личные данные, такие как Secret и ConfigMap, будут экспортироваться лишь метаданные. Для всех прочих запросов в аудит логах будут сохраняться объекты и запроса, и ответа.nnИмейте в виду: хранение данных логов внутри кластера представляет риск для безопасности при компрометации. Такие логи, как и все иные уязвимые к безопасности, должны транспортироваться за пределы кластера, чтобы предотвратить опасные последствия на случай вмешательства.n
Необходимо использовать стороннюю аутентификацию API сервера
Централизация проверки подлинности и авторизации в компании (Single Sign On) выручает в таких неизбежных моментах, как принятие на работу сотрудников, также их уход из компании; она обеспечивает консистентные права доступа.nnОбъединение Kubernetes с внешними поставщиками аутентификации (такими как Google, Github) гарантирует идентификацию удаленной платформы (с протекцией типа двухфакторной аутентификации), при этом админам больше не придется переконфигурировывать сервера API в Kubernetes при добавлении пользователей или их удалении.nnDex — это провайдер OpenID Connect Identity и OAuth версии 2.0 с подключаемыми разъемами. В компании Pusher продвинулась еще больше, предлагая настраиваемый инструментарий, и множество других помощники для иных случаев использования.n
Отделите кластер etcd и защитите его с помощью брандмауэра
Etcd содержит данные о состоянии и секретах. Это один из самых важных компонентов Kubernetes. Исходя из этого, его следует защищать отдельно от другой части кластера.nПолучить доступ к записи на etcd API сервера эквивалентно тому, чтобы получить права root для всего кластер. Фактически, элементарный доступ для чтения можно довольно легко использовать для расширения привилегий.nnПланировщик от фреймворка Kubernetes будет искать определения тех подов в etcd, которые не имеют узла. После этого для планирования он посылает найденные им поды на доступный kubelet. Проверка отправленных подов выполняется перед их записью в etcd сервером API, таким образом, мошенники, записывающие данные непосредственно в etcd, имеют возможность обойти многие инструменты безопасности, к примеру PodSecurityPolicies.nnEtcd следует настраивать с серверными и клиентскими TLS сертификатами и производить деплой на выделенных узлах. Чтобы предотвратить хищение частных ключей с рабочих узлов и их использование, API сервер кластера следует ограничить брандмауэром.n
Для ключей шифрования осуществляйте чередование
Оптимальная методика обеспечения безопасности состоит в том, чтобы периодически чередовать ключи шифрования и сертификаты, чтобы сузить «спектр поражения» при ситуации, когда ключ находится под угрозой.nnKubernetes будет чередовать часть сертификатов автоматически (в том числе, серверные и клиентские сертификаты kubelet), при этом будут создаваться новые CSR после истечения полномочий действующих.nnВ то же время чередование симметричных ключей шифрования, которые используются сервером API для шифрования значений etcd, не выполняется автоматически — их необходимо ротировать вручную. Для этого требуется мастер-доступ, по этой причине управляемые сервисы (такие, как GKE или AKS) уводят эту проблему от оператора.n
Рабочие нагрузки
Кластер в состоянии работать безопасно даже при поддержании минимальной защиты на уровне Сontrol Planel . Но, также как и судно, которое перевозит груз, являющийся потенциально опасным, следует защищать и контейнеры судна, чтобы в случае внезапной аварийной ситуации либо пробоины сохранить ценный груз.nnТоже самое относится и к рабочим нагрузкам (такими как Pods, Deployments, Jobs, Sets) в Kubernetes — несмотря на то, что в их безопасности можно не сомневаться во время развертывания, если они находятся в интернете, то неизбежно остается риск того, что впоследствии ими могут воспользоваться. Усиление конфигурации среды выполнения рабочих нагрузок при условии их активации с предоставленными минимальными привилегиями помогут снизить этот риск.n
Применяйте функций обеспечения безопасности Linux и PodSecurityPolicies
В ядре Linux имеется ряд расширений безопасности, которые перекрывают друг друга, например, такие как сapabilities, AppArmor, SELinux и seccomp-bpf, и они могут быть сконфигурированы таким образом, чтобы присваивать приложениям минимальные привилегии.nnТакие инструменты, как bane, могут помочь в создании профилей AppArmor, а инструмент docker-slim – в создании профилей seccomp, однако необходимо быть бдительными — потребуется использование полного набора тестов для полной проверки кода приложения. Это необходимо для обнаружения скрытых “побочных эффектов” от применения данных политик.nnС целью регулирования разнообразных директив безопасности Kubernetes, включая директивы для использования расширений безопасности, могут быть применены PodSecurityPolicies. С помощью PodSecurityPolicies могут быть обеспечены минимальные требования к подам, которым они должны соответствовать, для того, чтобы находиться на сервере API, в частности это профили безопасности, флаг привилегированности, а также совместное использование сети хоста, процессов или пространства имен IPC.nnДанные директивы являются очень важными, поскольку с их помощью контейнеризированные процессы не выходят за изолированные пределы, и довольно универсальная модель PodSecurityPolicy Тима Олклера может быть настроен для вашего варианта использования.n
Проводите статический анализ для YAML
В тех случаях, когда PodSecurityPolicies отказывает в доступе к серверу API, тогда статический анализ может быть задействован в рабочем процессе разработки при моделировании установленных требований компании или ее расположенности к риску.nnКонфиденциальную информацию не стоит хранить в YAML ресурсах вроде подов (к примеру, Pods, Deployments, Sets и другие), а конфиденциальные конфигурационные карты и секреты должны быть зашифрованы с помощью таких инструментов, как vault с оператором CoreOS, git-crypt, sealed secrets или же с помощью KMS-провайдера.nnВ качестве базы для обеспечения гарантий безопасности в ходе активации может быть использован статический анализ конфигурации YAML. С помощью kubesec формируются прогнозы рисков, которым могут подвергнуться ресурсы. И kubetest является фреймворком для модульной проверки Kubernetes конфигураций. Эти инструменты применяют подход, заключающийся в перенесении тестирования и верификации на первичные стадии жизненного цикла разработки. Этот метод называется shift left.nnПроведение проверки безопасности на таких ранних стадиях дает оперативную обратную связь о коде, а также о конфигурации, которая в свою очередь может быть отклонена более поздней проверкой (ручной либо автоматической), и кроме того, может значительно упростить процесс внедрения дальнейших практик по безопасности.n
Запустите контейнеры в качестве пользователя без root полномочий
Запущенные в качестве пользователя с root полномочиями контейнеры часто имеют гораздо больше разрешений, чем требуется для их рабочей нагрузки, что может помочь злоумышленнику добиться большего, если произойдет компрометация.nnКонтейнеры все еще полагаются на признанную модель безопасности Unix под названием DAC — все является файлом, и разрешения предоставляются пользователям либо же группам.nnВ Kubernetes не включены пространства имен пользователей. Таким образом, таблицы ID пользователей в самих контейнерах отображаются на таблицы пользователей хоста, а результатом активизации каких-либо процессов с корневыми правами доступа внутри контейнера становится их активация с корневыми правами уже на хосте. Хотя у нас есть многоуровневые механизмы защиты, предназначенные для предотвращения выхода контейнера за пределы, по-прежнему не рекомендуется осуществлять запускать внутри контейнера от имени root.nnДостаточно часто образы контейнеров используют пользователя с корневыми правами с целью активации PID 1 – таким образом, в случае возникновения компрометации, взломщик получает корневые права доступа в контейнере, и любые ошибки конфигурации будет намного легче использовать.nnРазработчики Bitnami осуществили сложную задачу по перемещению их образов контейнеров на пользователей без корневых прав (впрочем, OpenShift требует этого автоматически). Таким образом может значительно упроститься процесс перемещения на образы контейнеров без корневых прав.nnДанные фрагмент кода PodSecurityPolicy препятствует активации процессов с корневыми правами внутри контейнера, а также эскалацию до корневых прав:nТе контейнеры, у которых отсутствуют корневые полномочия, не могут привязываться к привилегированным портам, то есть до 1024 (регулируется возможностями ядра CAP_NET_BIND_SERVICE), тем не менее, используя Services можно уклониться от этого ограничения.nnВ этом случае фиктивное приложение MyApp привязано к порту 8443 в контейнере, но служба предоставляет его на 443, перенаправляя запрос на targetPort:Рабочие нагрузки нужно будет запускать от имени пользователя, не имеющего корневых полномочий, пока пространства имён для пользователей используются, или пока текущие наработки активации контейнеров, не имеющих корневых полномочий, не будут входить в состав рабочих сред контейнеров.n
Применяйте Network Policies
Kubernetes не ограничивает трафик между подами автоматически; это можно изменить с помощью сетевой политики (Network Policy).nТрадиционные службы ограничиваются брандмауэрами, которые используют статический IP-адрес, а также диапазоны портов для сервисов. Так как данные IP крайне нечасто изменяются, они обычно служили формой идентификации.nnКонтейнеры очень редко имеют статические IP-адреса — те быстрого выходят из строя и снова создаются, в качестве альтернативы для них используется протокол обнаружения сервисов (service discovery). Это делает настройку и тестирование функционирования брандмауэров более трудоемким.nnИсходя и того, что Kubernetes сохраняет в etcd все необходимые данные о состоянии системы, он может настроить динамическую брандмауэрную защиту, если она поддерживается сетевым плагином CNI. Такие плагины, как Calico, Kube-Router, Romana, Cilium, Weave Net поддерживают сетевые политики.nСледует отметить, что эти политики работают таким образом, что если отсутствует podSelector, это принимается автоматически как все возможные значения (принцип fail-closed):Вот пример сетевой политики, которая запрещает все egress, за исключением UDP 53 (DNS), что тоже не допускает входящие подключения к приложению. Сетевые политики имеют статус stateful, таким образом отклики на исходящие запросы еще доходят до приложения.nnСетевые политики Kubernetes не могут применяться к DNS именам. Это связано с тем, что DNS поддерживает метод Round robin — распределения нагрузки на множество IP-адресов и динамические ответы, зависимые от IP, которое обращается. Таким образом, сетевые политики используются только для фиксированных IP-адресов либо podSelector — для динамических IP-адресов Kubernetes.nnСначала рекомендуется запретить весь трафик для пространства имен и затем постепенного добавлять маршруты, позволяющие приложению пройти приемочное тестирование. Этот процесс может оказаться довольно сложным и трудоемким, ввиду этого Control Plane разработали netassert. Это инструмент, предназначенный для проверки сетевой безопасности рабочих процессов DevSecOps с очень распараллеленным nmap.nnAPI с метаданными cloud провайдера является константным источником эскалации (как демонстрирует bug bounty компании Shopify), исходя из этого специальное тестирование, которое подтверждает блокировку API в сети контейнеров, поспособствует предотвращению конфигурационных сбоев.n
Просканируйте образы и после запустите IDS
Веб-серверы представляют собой стартовую площадку для осуществления взломов сетей, к которым эти веб-серверы прикреплены: сканируйте файлы, которые установлены в образах. Такая проверка помогает убедиться в том, что нет никаких распространенных уязвимостей, которые взломщик захочет использовать, чтобы получить удалённый доступ к контейнеру. Если вдруг такое произойдет, то система обнаружения вторжений IDC зафиксирует это.nnВ Kubernetes поды допускаются в кластер после определенного комплекса контролирующих тестов, которые применяются как к подам, так и к иным ресурсам (например, Deployments). При этом каждый отдельный под проверяется на допуск или изменяется его содержимое, и теперь они также поддерживают backend вебхуки.nnСредства сканирования образов контейнеров могут использовать эти вебхуки, проводя проверку образов перед тем, как они будут развернуты в кластере. Те из образов, которые не прошли проверку, могут отклоняться.nnОсуществление такого сканирования образов контейнеров на наличие распространенных уязвимостей поможет значительно сократить период времени, в течение которого взломщик сможет использовать раскрытый CVE. Такие бесплатные инструменты как Clair от компании CoreOS, а также Micro Scanner от компании Aqua, могут быть использованы с целью недопущения развертывания образов, имеющих критические уязвимости.nnИнструменты по типу Grafeas могут хранить метаданные всех образов, что позволяет осуществлять непрерывные проверки на соответствие и наличие уязвимостей. Это достигается при помощи использования уникальной подписи для контейнера, то есть контентно-адресуемого хэша. Осуществление сканирования образа контейнера с этим хэшем аналогично сканированию образов, развернутых в рабочей среде, и может выполняться непрерывно без потребности в доступе к рабочей среде.nnВсегда есть риск неизвестных уязвимостей нулевого дня, именно по этой причине в Kubernetes должны быть развернуты такие инструменты обнаружения вторжений, как Twistlock , Aqua, Sysdig Secure. C помощью IDC выявляется подозрительное поведение внутри контейнера и система приостанавливает либо даже уничтожает его — Falco от Sysdig — это движок правил с открытым исходным кодом и точка входа в эту экосистему.n
Чего ждать в будущем
По-видимому, следующим прогрессивным этапом безопасности в Эволюции Сloud Native станет service mesh, но стоит учитывать, что его принятие может занять некоторое время: для этой миграции необходимо перемещение в mesh-инфраструктуру сложности приложений, а компаниям еще предстоит понять эту передовую практику.n
Запускайте Service Mesh
Программное обеспечение Service Mesh представляет собой сеть константных зашифрованных соединений, которые созданы между sidecar (подключёнными сбоку) высокопроизводительными прокси-серверами наподобие Envoy или Linkerd. Service Mesh обеспечивает такие функции как управление трафиком, мониторинг, политики — и все эти процессы осуществляются без необходимости внесения изменений в микросервисы.nnУже Linkerd имел возможность переносить код безопасности, а также сетевой код из микросервисов в общий набор библиотек, испытанных в»битвах». А после выхода Istio от Google, IBM и Lyft появилась возможность альтернативы в данном пространстве. Istio вместе с SPIFFE для криптографической идентичности подов, а также большим числом других функций, может значительно оптимизировать развертывание сетевой безопасности нового поколения.nnДля сетей с нулевым доверием отсутствует обязательная необходимость в традиционном брандмауэре, ровно как в сетевых политиках Kubernetes, так как любые взаимодействия осуществляются через mutual TLS, что помимо гарантирования защиты обмена данными, подтверждает идентичность соответствующих сервисов.nnПринятие концепций безопасности Cloud Native, и соответственно отказ от привычных проверенных сетевых подходов окажется непростым для тех пользователей, которые имеют традиционные подходы по части безопасности. Мы это прекрасно осознаем. Работа автора Эвана Гилмана из SPIFFE под названием «Zero Trust Networking» очень рекомендована для погружения в этот мир прогресса.nnСейчас выпущен проект Istio 0.8 LTS, и он стремительно близится к выпуску 1.0. Подобно модели Kubernetes происходит версионирование по части стабильности: стабильное ядро с отдельными API, для которых определяются альфа или бета статусы, используя пространства имён. Стоит ожидать, что в ближайшие несколько месяцев будет происходить масштабное распространение проекта Istio.n
Заключение
Приложения Cloud Native обладают лучше гранулированным комплексом легковесных примитивов безопасности, предназначенных для защиты рабочих нагрузок, защиты инфраструктуры. Силу и адаптируемость этих инструментов можно считать в одно и тоже время как благом так и бедствием ввиду того факта, что при недостаточной автоматизации стало еще легче выявлять небезопасные рабочие нагрузки, что упрощает выход за рамки контейнера или изоляционной модели.nnСейчас доступно невиданное ранее количество инструментов для обеспечения безопасности, но необходимо быть осторожными при их применении, чтобы уменьшить возможности взломов, а также некорректных конфигураций.nnОднако безопасности не стать первоочерёдной, если она будет замедлять скорость компании в предоставлении возможностей. Применение к цепочке поставок программного обеспечения принципов непрерывной поставки (Continuous Delivery) позволит компании достичь соответствия требованиям, аудита на постоянной основе и усиленного регулирования, при этом не оказывая влияния на практические результаты деятельности компании.nnОперативная итерация в отношении безопасности осуществляется проще всего при условии наличия всеобъемлющего набора тестов. Это достигается с помощью Continuous Security (непрерывной безопасности). Это хорошая альтернатива тестам на проникновение, которые задаются определённым временем, с постоянной валидацией в pipeline. При этом есть четкое представление о масштабах вторжения, риски всегда ясны и могут быть урегулированы.nnЭто принцип работы ControlPlane: если мы можем помочь запустить Continuous Security, провести обучение по безопасности и эксплуатации Kubernetes или совместно внедрить безопасную cloud native evolution для Вас, пожалуйста, свяжитесь с нами.n
Мы поможем принять меры по усилению ИТ безопасности сайта или сервера и закрыть уязвимости ИТ инфраструктуры. Обращайтесь за профессиональной помощью и консультацией.