Памятка по безопасности Kubernetes¶

Кубернетес

Kubernetes — это механизм оркестрации контейнеров с открытым исходным кодом для автоматизации развертывания, масштабирования и управления контейнерными приложениями. Проект с открытым исходным кодом поддерживается Cloud Native Computing Foundation (CNCF).

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

Компоненты плоскости управления

Компоненты плоскости управления принимают глобальные решения о кластере, а также обнаруживают события кластера и реагируют на них. Он состоит из таких компонентов, как kube-apiserver, etcd, kube-scheduler, kube-controller-manager и cloud-controller-manager.

Компоненты узла

Компоненты узла запускаются на каждом узле, поддерживая работающие модули и обеспечивая среду выполнения Kubernetes. Он состоит из таких компонентов, как kubelet, kube-proxy и среды выполнения контейнера.

Эта памятка представляет собой отправную точку для защиты кластера Kubernetes. Он делится на следующие категории:

• Защита хостов Kubernetes
• Защита компонентов Kubernetes
• Рекомендации по безопасности Kubernetes: этап сборки
• Рекомендации по безопасности Kubernetes: этап развертывания
• Рекомендации по безопасности Kubernetes: фаза выполнения

Защита хостов Kubernetes

Существует несколько вариантов развертывания Kubernetes: на «голом железе», локально и в общедоступном облаке (собственная сборка Kubernetes на виртуальных машинах ИЛИ использование управляемой службы). Kubernetes был разработан, чтобы быть легко переносимым, и клиенты могут легко переключаться между этими установками, перенося свои рабочие нагрузки.

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

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

Версия Kubernetes

Отследить все потенциальные векторы атак стало невозможно. Этот факт прискорбен, поскольку нет ничего более важного, чем быть в курсе потенциальных угроз. Лучшая защита — убедиться, что вы используете последнюю доступную версию Kubernetes.

Проект Kubernetes поддерживает выпускные ветки для последних трех второстепенных выпусков и выполняет резервное копирование применимых исправлений, включая исправления безопасности, для этих трех выпускных веток, в зависимости от серьезности и осуществимости. Выпуски исправлений регулярно вырезаются из этих веток, а при необходимости добавляются дополнительные срочные выпуски. Поэтому всегда рекомендуется обновлять кластер Kubernetes до последней доступной стабильной версии. Для получения дополнительной информации рекомендуется обратиться к политике перекоса версий https://kubernetes.io/docs/setup/release/version-skew-policy/ .

Существует несколько методов, таких как последовательные обновления и миграция пула узлов, которые позволяют выполнить обновление с минимальными перерывами и простоями.

Защита компонентов Kubernetes

Контролируйте сетевой доступ к конфиденциальным портам

Кластеры Kubernetes обычно прослушивают ряд четко определенных и отличительных портов, что упрощает идентификацию кластеров и их атаку. Следовательно, настоятельно рекомендуется настроить аутентификацию и авторизацию в кластере и узлах кластера.

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

Главный узел (узлы):

Рабочие узлы:

Ограничьте прямой доступ к узлам Kubernetes

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

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

Управление доступом к Kubernetes API

Платформа Kubernetes управляется с помощью запросов API и поэтому является первой линией защиты от злоумышленников. Контроль за тем, кто имеет доступ и какие действия им разрешено выполнять, является главной задачей. Для получения дополнительной информации обратитесь к документации по адресу https://kubernetes.io/docs/reference/access-authn-authz/controlling-access/ .

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

Связь в кластере между службами должна осуществляться с использованием TLS, по умолчанию шифрующего весь трафик. Это, однако, часто упускают из виду, считая, что кластер безопасен и нет необходимости обеспечивать шифрование при передаче внутри кластера.

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

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

Чтобы узнать больше об использовании TLS в кластере Kubernetes, обратитесь к документации по адресу https://kubernetes.io/blog/2018/07/18/11-ways-not-to-get-hacked/#1-tls-everywhere . .

API-аутентификация

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

• Аутентификация со статическим файлом токена использует маркеры открытого текста, хранящиеся в CSV-файле на узлах сервера API. Изменение учетных данных в этом файле требует перезапуска сервера API.
• Клиентские сертификаты X509 также доступны, однако они не подходят для производственного использования, поскольку Kubernetes не поддерживает отзыв сертификатов , что означает, что учетные данные пользователя не могут быть изменены или отозваны без смены ключа корневого центра сертификации и повторной выдачи всех сертификатов кластера.
• Токены учетных записей служб также доступны для аутентификации. Их основное предназначение — разрешить рабочим нагрузкам, работающим в кластере, проходить аутентификацию на сервере API, однако их также можно использовать для аутентификации пользователей.

Рекомендуемый подход для больших или производственных кластеров заключается в использовании внешнего метода аутентификации:

• OpenID Connect Connect (OIDC) позволяет внедрить аутентификацию, использовать недолговечные токены и использовать централизованные группы для авторизации.
• Управляемые дистрибутивы Kubernetes, такие как GKE, EKS и AKS, поддерживают аутентификацию с использованием учетных данных от соответствующих поставщиков IAM.
• Kubernetes Impersonation можно использовать как с управляемыми облачными кластерами, так и с локальными кластерами для внешней аутентификации без необходимости доступа к параметрам конфигурации сервера API.

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

Для получения дополнительной информации обратитесь к справочному документу по аутентификации Kubernetes по адресу https://kubernetes.io/docs/reference/access-authn-authz/authentication .

Авторизация API — реализация управления доступом на основе ролей¶

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

Kubernetes авторизует запросы API с помощью сервера API. Он оценивает все атрибуты запроса по всем политикам и разрешает или отклоняет запрос. Для продолжения все части запроса API должны быть разрешены какой-либо политикой. Это означает, что разрешения запрещены по умолчанию.

Управление доступом на основе ролей (RBAC) — это метод регулирования доступа к компьютерным или сетевым ресурсам на основе ролей отдельных пользователей в вашей организации.

Kubernetes поставляет интегрированный компонент управления доступом на основе ролей (RBAC), который сопоставляет входящего пользователя или группу с набором разрешений, связанных с ролями. Эти разрешения объединяют глаголы (получить, создать, удалить) с ресурсами (модулями, службами, узлами) и могут быть ограничены пространством имен или кластером. Предоставляется набор готовых ролей, которые предлагают разумное разделение ответственности по умолчанию в зависимости от того, какие действия клиент может захотеть выполнить. Рекомендуется использовать авторизаторы Node и RBAC вместе в сочетании с подключаемым модулем допуска NodeRestriction.

Авторизация RBAC использует группу API rbac.authorization.k8s.io для принятия решений об авторизации, что позволяет динамически настраивать политики через API Kubernetes. Чтобы включить RBAC, запустите сервер API с флагом –authorization-mode, установленным в список, разделенный запятыми, который включает RBAC; Например:

kube-apiserver --authorization-mode=Example,RBAC --other-options --more-options

Подробные примеры использования RBAC см. в документации Kubernetes по адресу https://kubernetes.io/docs/reference/access-authn-authz/rbac .

Ограничить доступ к etcd

etcd — критически важный компонент Kubernetes, хранящий информацию о состоянии и секретах, и его следует защищать иначе, чем остальную часть вашего кластера. Доступ на запись к etcd сервера API эквивалентен получению root прав на весь кластер, и даже доступ на чтение можно использовать для довольно легкого повышения привилегий.

Планировщик Kubernetes будет искать в etcd определения pod, у которых нет узла. Затем он отправляет найденные модули в доступный kubelet для планирования. Проверка отправленных модулей выполняется сервером API до того, как он запишет их в etcd, поэтому злоумышленники, записывающие напрямую в etcd, могут обойти многие механизмы безопасности, например PodSecurityPolicies.

Администраторы всегда должны использовать надежные учетные данные от серверов API к своему серверу etcd, такие как взаимная аутентификация через клиентские сертификаты TLS, и часто рекомендуется изолировать серверы etcd за брандмауэром, к которому могут получить доступ только серверы API.

Осторожность

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

Управление доступом к Kubelet

Kubelets предоставляет конечные точки HTTPS, которые предоставляют мощный контроль над узлом и контейнерами. По умолчанию Kubelets разрешают неавторизованный доступ к этому API. Рабочие кластеры должны поддерживать аутентификацию и авторизацию Kubelet.

Для получения дополнительной информации см. документацию по аутентификации/авторизации Kubelet по адресу https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet-authentication-authorization .

Защита панели управления Kubernetes

Панель инструментов Kubernetes — это веб-приложение для управления вашим кластером. Он не является частью самого кластера Kubernetes, его должны установить владельцы кластера. Таким образом, существует множество руководств о том, как это сделать. К сожалению, большинство из них создают учетную запись службы с очень высокими привилегиями. Это привело к тому, что Tesla и некоторые другие компании были взломаны с помощью такой плохо настроенной приборной панели K8s. (Ссылка: облачные ресурсы Tesla взломаны для запуска вредоносных программ для майнинга криптовалюты — https://arstechnica.com/information-technology/2018/02/tesla-cloud-resources-are-hacked-to-run-cryptocurrency-mining-malware / )

Чтобы предотвратить атаки через личный кабинет, следует придерживаться нескольких советов:

• Не раскрывайте панель инструментов без дополнительной аутентификации для общественности. Нет необходимости получать доступ к такому мощному инструменту из-за пределов вашей локальной сети.
• Включите RBAC, чтобы вы могли ограничить учетную запись службы, которую использует панель мониторинга.
• Не предоставляйте сервисной учетной записи панели мониторинга высокие привилегии
• Предоставьте разрешения каждому пользователю, чтобы каждый пользователь мог видеть только то, что он должен видеть.
• Если вы используете сетевые политики, вы можете блокировать запросы к дашборду даже от внутренних подов (это не повлияет на туннель прокси через kubectl proxy)
• До версии 1.8 на приборной панели была учетная запись службы с полными привилегиями, поэтому проверьте, не осталось ли привязки роли для cluster-admin.
• Разверните панель управления с помощью обратного прокси-сервера с проверкой подлинности и включенной многофакторной проверкой подлинности. Это можно сделать либо с помощью встроенного OIDC id_tokens, либо с помощью олицетворения Kubernetes. Это позволяет вам использовать панель мониторинга с учетными данными пользователя вместо использования привилегированного файла ServiceAccount. Этот метод можно использовать как в локальных, так и в управляемых облачных кластерах.

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

Защита контейнеров и Kubernetes начинается на этапе сборки с защиты образов контейнеров. Две основные вещи, которые нужно сделать здесь, — это создать безопасные образы и просканировать эти образы на наличие любых известных уязвимостей.

Образ контейнера — это неизменяемый, легкий, автономный исполняемый пакет программного обеспечения, который включает в себя все необходимое для запуска приложения: код, среду выполнения, системные инструменты, системные библиотеки и настройки [ https://www.docker.com/resources/what- контейнер ]. Образ использует ядро ​​операционной системы, присутствующее на хост-компьютере.

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

Убедитесь, что в вашей среде используются только авторизованные образы

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

Реестр контейнеров и использование сканера изображений для выявления известных уязвимостей

Реестр контейнеров — это центральный репозиторий образов контейнеров. В зависимости от потребностей мы можем использовать общедоступные репозитории или частный репозиторий в качестве реестра контейнеров. Используйте частные реестры для хранения утвержденных изображений — убедитесь, что вы отправляете только утвержденные изображения в эти реестры. Уже одно это уменьшает количество потенциальных изображений, попадающих в ваш конвейер, до доли сотен тысяч общедоступных изображений.

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

Многие репозитории исходного кода предоставляют возможности сканирования (например, Github , GitLab ), а многие инструменты CI предлагают интеграцию со сканерами уязвимостей с открытым исходным кодом, такими как Trivy или Grype .

В Kubernetes ведется работа над плагинами авторизации изображений, которые позволят предотвратить отправку неавторизованных изображений. Для получения дополнительной информации обратитесь к PR https://github.com/kubernetes/kubernetes/pull/27129 .

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

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

Ограничение того, что находится в вашем контейнере среды выполнения, только тем, что необходимо для вашего приложения, является передовой практикой, используемой Google и другими технологическими гигантами, которые используют контейнеры в производстве в течение многих лет. Это улучшает отношение сигнала к шуму сканеров (например, CVE) и снижает нагрузку по установлению происхождения до того, что вам нужно.

Образы без дистрибутива

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

Дополнительные сведения об образах ditroless см. на странице https://github.com/GoogleContainerTools/distroless .

Скретч-изображение

Пустой образ, идеально подходящий для статически скомпилированных языков, таких как Go. Поскольку изображение пусто – поверхность атаки действительно минимальна – только ваш код!

Для получения дополнительной информации см. https://hub.docker.com/_/scratch.

Используйте последние изображения/убедитесь, что изображения обновлены

Убедитесь, что ваши образы (и любые сторонние инструменты, которые вы включаете) обновлены и используют последние версии их компонентов.

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

Инфраструктура Kubernetes должна быть надежно настроена до развертывания рабочих нагрузок. С точки зрения безопасности вам в первую очередь необходимо иметь представление о том, что вы развертываете и как. Затем вы можете выявлять нарушения политики безопасности и реагировать на них. Как минимум, вам нужно знать:

• Что развертывается — включая информацию об используемом образе, например о компонентах или уязвимостях, а также о модулях, которые будут развернуты.
• Где он будет развернут — какие кластеры, пространства имен и узлы
• Как он развернут — работает ли он привилегированно, с какими другими развертываниями он может взаимодействовать, применяемый контекст безопасности модуля, если таковой имеется.
• К чему он может получить доступ, включая секреты, тома и другие компоненты инфраструктуры, такие как API хоста или оркестратора.
• Является ли он совместимым — соответствует ли он вашим политикам и требованиям безопасности

Используйте пространства имен Kubernetes для правильной изоляции ресурсов Kubernetes.

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

Установка пространства имен для запроса

Чтобы установить пространство имен для текущего запроса, используйте флаг –namespace. Обратитесь к следующим примерам:

kubectl run nginx --image=nginx --namespace=<insert-namespace-name-here>
kubectl get pods --namespace=<insert-namespace-name-here>

Настройка предпочтения пространства имен

Вы можете навсегда сохранить пространство имен для всех последующих команд kubectl в этом контексте.

kubectl config set-context --current --namespace=<insert-namespace-name-here>

Подтвердите его с помощью следующей команды.

kubectl config view --minify | grep namespace:

Узнайте больше о пространствах имен на странице https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces .

Создание политик для управления происхождением изображений с помощью ImagePolicyWebhook.

Предотвращение использования неутвержденных изображений с контроллером доступа ImagePolicyWebhook для отклонения модулей, которые используют неутвержденные изображения, в том числе:

• Изображения, которые не сканировались в последнее время
• Изображения, использующие базовое изображение, которое явно не разрешено
• Образы из незащищенных реестров Узнайте больше о веб-перехватчике по адресу https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#imagepolicywebhook .

Внедрение непрерывного сканирования уязвимостей безопасности¶

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

Проекты с открытым исходным кодом, такие как ThreatMapper, могут помочь в выявлении и приоритизации уязвимостей.

Регулярно применяйте обновления безопасности к вашей среде

В случае обнаружения уязвимостей в запущенных контейнерах рекомендуется всегда обновлять исходный образ и повторно развертывать контейнеры.

ПРИМЕЧАНИЕ

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

Example: apt-update  

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

Оценить привилегии, используемые контейнерами

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

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

• Не запускайте процессы приложений от имени root.
• Не разрешать повышение привилегий.
• Используйте корневую файловую систему только для чтения.
• Использовать монтирование файловой системы по умолчанию (замаскированное) /proc
• Не используйте сеть хоста или пространство процесса — использование «hostNetwork: true» приведет к игнорированию NetworkPolicies, поскольку Pod будет использовать свою сеть хоста.
• Отбросьте неиспользуемые и ненужные возможности Linux.
• Используйте параметры SELinux для более точного управления процессом.
• Дайте каждому приложению собственную учетную запись службы Kubernetes.
• Не подключайте учетные данные служебной учетной записи в контейнер, если ему не требуется доступ к API Kubernetes.

Дополнительные сведения о политиках безопасности Pod см. в документации по адресу https://kubernetes.io/docs/concepts/policy/pod-security-policy/ .

Примените контекст безопасности к своим модулям и контейнерам

Контекст безопасности — это свойство, определенное в yaml развертывания. Он управляет параметрами безопасности, которые будут назначены поду/контейнеру/тому. Эти элементы управления могут устранить целые классы атак, которые зависят от привилегированного доступа. Например, корневые файловые системы, доступные только для чтения, могут предотвратить любую атаку, которая зависит от установки программного обеспечения или записи в файловую систему.

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

Вот пример определения пода с параметрами контекста безопасности:

apiVersion: v1  
kind: Pod  
metadata:  
  name: hello-world  
spec:  
  containers:  
  # specification of the pod’s containers  
  # ...
  # ...
  # Security Context
  securityContext:  
    readOnlyRootFilesystem: true  
    runAsNonRoot: true

Для получения дополнительной информации о контексте безопасности для модулей см. документацию по адресу https://kubernetes.io/docs/tasks/configure-pod-container/security-context .

Внедрение сервисной сетки

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

Наблюдаемость

Service Mesh предоставляет метрики трассировки и телеметрии, которые упрощают понимание вашей системы и быстро определяют причины любых проблем.

Безопасность

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

• mTLS и почему это важно Обеспечить безопасность микросервисов сложно. Существует множество инструментов для обеспечения безопасности микросервисов, но сервисная сетка является наиболее элегантным решением для шифрования сетевого трафика в сети. Сервисная сетка обеспечивает защиту с помощью взаимного TLS (mTLS) шифрования трафика между вашими сервисами. Сетка может автоматически шифровать и расшифровывать запросы и ответы, снимая эту нагрузку с разработчика приложения. Это также может повысить производительность за счет приоритизации повторного использования существующих постоянных подключений, уменьшая потребность в дорогостоящем создании новых. С помощью Service Mesh вы можете защитить сетевой трафик, а также обеспечить надежную аутентификацию и авторизацию на основе удостоверений для каждой микрослужбы. Мы видим в этом большую ценность для корпоративных компаний.
• Сетка Ingress & Egress Control Service добавляет уровень безопасности, который позволяет отслеживать и устранять компрометирующий трафик, когда он входит в сетку. Istio интегрируется с Kubernetes в качестве входного контроллера и обеспечивает балансировку нагрузки для входящего трафика. Это позволяет добавить уровень безопасности по периметру с помощью правил входа. Управление выходом позволяет вам видеть и управлять внешними службами, а также контролировать, как ваши службы взаимодействуют с ними.

Оперативный контроль

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

RBAC

Надежная система управления доступом на основе ролей (RBAC), возможно, является одним из наиболее важных требований в крупных инженерных организациях, поскольку даже самую безопасную систему могут легко обойти чрезмерно привилегированные пользователи или сотрудники. Ограничение привилегированных пользователей минимальными привилегиями, необходимыми для выполнения должностных обязанностей, обеспечение того, чтобы доступ к системам был установлен на «запретить всем» по умолчанию, и обеспечение наличия надлежащей документации с подробным описанием ролей и обязанностей — одна из наиболее важных проблем безопасности на предприятии.

Недостатки

Наряду со многими преимуществами, Service mesh также имеет ряд проблем, некоторые из которых перечислены ниже:

• Добавленная сложность: внедрение прокси-серверов, дополнительных компонентов и других компонентов в и без того сложную среду резко увеличивает сложность разработки и эксплуатации.
• Требуемый опыт: добавление сервисной сетки, такой как Istio, поверх оркестратора, такого как Kubernetes, часто требует от операторов быть экспертами в обеих технологиях.
• Медлительность: сервисные сетки — это инвазивная и сложная технология, которая может значительно замедлить архитектуру.
• Принятие платформы: инвазивность сервисных сеток вынуждает как разработчиков, так и операторов приспосабливаться к платформе с строгим самоуправлением и соответствовать ее правилам.

Внедрение Open Policy Agent (OPA) для централизованного управления политиками

OPA — это проект, запущенный в 2016 году и направленный на унификацию применения политик в различных технологиях и системах. Его можно использовать для применения политик на их платформах (например, в кластерах Kubernetes). Когда дело доходит до политик безопасности Kubernetes, RBAC и Pod, они обеспечивают детальный контроль над кластером. Но опять же, это будет применяться только к кластеру, но не за его пределами. Вот где в игру вступает Open Policy Agent (OPA). OPA был введен для создания унифицированного метода применения политики безопасности в стеке.

OPA — это универсальный инструмент для применения политик, не зависящий от домена. Его можно интегрировать с API, демоном SSH Linux, хранилищем объектов, таким как CEPH, и т. д. Разработчики OPA намеренно избегали основывать его на каком-либо другом проекте. Соответственно, запрос политики и решение не соответствуют определенному формату. То есть вы можете использовать любые действительные данные JSON в качестве атрибутов запроса, если они предоставляют необходимые данные. Точно так же решение о политике, поступающее от OPA, также может быть любым допустимым JSON-данным. Вы выбираете, что будет на входе, а что на выходе. Например, вы можете выбрать, чтобы OPA возвращал объект JSON True или False, число, строку или даже сложный объект данных. В настоящее время OPA является частью CNCF в качестве инкубационного проекта.

Наиболее распространенные варианты использования OPA:

• Авторизация приложений

OPA позволяет сократить время выхода на рынок, предоставляя предварительно подготовленную технологию авторизации, поэтому вам не нужно разрабатывать ее с нуля. Он использует декларативный язык политики, предназначенный для написания и применения правил, таких как «Алиса может писать в этот репозиторий» или «Боб может обновлять эту учетную запись». Он поставляется с богатым набором инструментов, которые помогают разработчикам интегрировать эти политики в свои приложения и даже позволяют конечным пользователям приложения также вносить изменения в политику для своих арендаторов.

Если у вас есть собственные решения для авторизации приложений, вы можете не захотеть вырывать их для замены в OPA. По крайней мере, пока. Но если вы собираетесь декомпозировать эти монолитные приложения и перейти к микросервисам для масштабирования и повышения эффективности разработчиков, вам понадобится распределенная система авторизации, и OPA — это ответ.

• Контроль доступа Kubernetes

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

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

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

• Авторизация сервисной сетки

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

Ограничение использования ресурсов в кластере

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

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

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

Ниже приведен пример определения квоты ресурсов пространства имен, которая ограничивает количество модулей в пространстве имен до 4, ограничивая их запросы ЦП от 1 до 2 и запросы памяти от 1 ГБ до 2 ГБ.

вычислительные ресурсы.yaml:

apiVersion: v1  
kind: ResourceQuota  
metadata:  
  name: compute-resources  
spec:  
  hard:  
    pods: "4"  
    requests.cpu: "1"  
    requests.memory: 1Gi  
    limits.cpu: "2"  
    limits.memory: 2Gi

Назначьте квоту ресурсов пространству имен:

kubectl create -f ./compute-resources.yaml --namespace=myspace

Дополнительные сведения о настройке квот ресурсов см. в документации Kubernetes по адресу https://kubernetes.io/docs/concepts/policy/resource-quotas/ .

Используйте сетевые политики Kubernetes для управления трафиком между модулями и кластерами.

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

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

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

Пользователи Google Cloud Platform могут воспользоваться автоматическими правилами брандмауэра, предотвращающими взаимодействие между кластерами. Аналогичную реализацию можно развернуть локально с помощью сетевых брандмауэров или решений SDN. В этой области группа Kubernetes Network SIG ведет работу, которая значительно улучшит политики связи между модулями. Новый API сетевой политики должен учитывать необходимость создания правил брандмауэра для модулей, ограничивая доступ к сети, который может иметь контейнер.

Ниже приведен пример сетевой политики, которая контролирует сеть для «внутренних» модулей, разрешая входящий доступ к сети только из «интерфейсных» модулей:

POST /apis/net.alpha.kubernetes.io/v1alpha1/namespaces/tenant-a/networkpolicys  
{  
  "kind": "NetworkPolicy",
  "metadata": {
    "name": "pol1"
  },
  "spec": {
    "allowIncoming": {
      "from": [{
        "pods": { "segment": "frontend" }
      }],
      "toPorts": [{
        "port": 80,
        "protocol": "TCP"
      }]
    },
    "podSelector": {
      "segment": "backend"
    }
  }
}

Дополнительные сведения о настройке сетевых политик см. в документации Kubernetes по адресу https://kubernetes.io/docs/concepts/services-networking/network-policies .

Защита данных

Храни секреты как секреты

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

Шифровать секреты в состоянии покоя

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

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

Kubernetes поддерживает шифрование в состоянии покоя — функция, представленная в версии 1.7, и бета-версия версии 1, начиная с версии 1.13. Это зашифрует секретные ресурсы в etcd, не позволяя сторонам, получившим доступ к вашим резервным копиям etcd, просматривать содержимое этих секретов. Хотя эта функция в настоящее время находится в стадии бета-тестирования, она предлагает дополнительный уровень защиты, когда резервные копии не зашифрованы или злоумышленник получает доступ для чтения к etcd.

Альтернативы секретным ресурсам Kubernetes

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

Для получения дополнительной информации о секретах и ​​их альтернативах обратитесь к документации по адресу https://kubernetes.io/docs/concepts/configuration/secret/ .

Нахождение раскрытых секретов

Инструменты с открытым исходным кодом, такие как SecretScanner и ThreatMapper, могут сканировать файловые системы контейнеров на наличие конфиденциальных ресурсов, таких как токены API, пароли и ключи. Такие ресурсы будут доступны любому пользователю, имеющему доступ к незашифрованной файловой системе контейнера, будь то во время сборки, в состоянии покоя в реестре или в резервной копии или во время работы.

Проверьте секретный материал, присутствующий на контейнере, на соответствие принципу «наименьших привилегий» и оцените риск, связанный с компрометацией.

Рекомендации по безопасности Kubernetes: фаза выполнения

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

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

Во-первых, вы должны отслеживать наиболее важные для безопасности действия контейнера, в том числе:

• Процессная активность
• Сетевые коммуникации между контейнерными сервисами
• Сетевые коммуникации между контейнерными службами и внешними клиентами и серверами

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

Используйте политики безопасности Pod, чтобы предотвратить использование рискованных контейнеров/Pod.

PodSecurityPolicy — это ресурсы на уровне кластера, доступные в Kubernetes (через kubectl), которые настоятельно рекомендуется использовать. Для его использования необходимо включить контроллер допуска PodSecurityPolicy. Учитывая характер контроллеров доступа, вы должны авторизовать хотя бы одну политику, иначе в кластере не будет разрешено создание модулей.

Политики безопасности Pod охватывают несколько критических случаев использования безопасности, в том числе:

• Предотвращение запуска контейнеров с привилегированным флагом — этот тип контейнера будет иметь большинство возможностей, доступных базовому хосту. Этот флаг также перезаписывает любые правила, которые вы установили с помощью CAP DROP или CAP ADD.
• Предотвращение совместного использования пространства имен хоста PID/IPC, сети и портов — этот шаг обеспечивает надлежащую изоляцию между контейнерами Docker и базовым хостом.
• Ограничение использования типов томов — например, тома каталога hostPath с возможностью записи позволяют контейнерам записывать в файловую систему таким образом, который позволяет им перемещаться по файловой системе хоста за пределами pathPrefix, поэтому необходимо использовать readOnly: true
• Наложение ограничений на использование файловой системы хоста
• Обеспечение только чтения для корневой файловой системы через ReadOnlyRootFilesystem
• Предотвращение повышения привилегий до привилегий root
• Отклонение контейнеров с привилегиями root
• Ограничение возможностей Linux до минимума в соответствии с принципами наименьших привилегий.

Дополнительные сведения о политиках безопасности Pod см. в документации по адресу https://kubernetes.io/docs/concepts/policy/pod-security-policy/ .

Безопасность контейнера во время выполнения

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

• Оболочка запускается внутри контейнера
• Контейнер монтирует конфиденциальный путь от хоста, например /proc
• В работающем контейнере, таком как /etc/shadow, неожиданно читается конфиденциальный файл.
• Установлено исходящее сетевое соединение
• Доступны инструменты с открытым исходным кодом, такие как Falco от Sysdig, чтобы помочь операторам начать работу с защитой среды выполнения контейнера, предоставляя большое количество готовых обнаружений, а также гибкость для создания настраиваемых правил.

Контейнерная песочница

Средам выполнения контейнеров обычно разрешается делать прямые вызовы к ядру хоста, после чего ядро ​​взаимодействует с оборудованием и устройствами, чтобы ответить на запрос. Cgroups и namespaces существуют, чтобы дать контейнерам определенную степень изоляции, но неподвижное ядро ​​​​представляет собой большую поверхность атаки. Часто в мультитенантных и ненадежных кластерах требуется дополнительный уровень песочницы, чтобы гарантировать отсутствие взлома контейнера и эксплойтов ядра. Ниже мы рассмотрим несколько технологий OSS, которые помогают еще больше изолировать запущенные контейнеры от ядра хоста:

• Kata Containers: Kata Containers — это проект OSS, в котором используются урезанные виртуальные машины, чтобы свести к минимуму использование ресурсов и максимизировать производительность, чтобы в конечном итоге еще больше изолировать контейнеры.
• gVisor: gVisor легче, чем виртуальная машина (даже урезанная). gVisor — это собственное независимое ядро, написанное на Go, которое находится между контейнером и ядром хоста. Сильная песочница. gVisor поддерживает ~70% системных вызовов Linux из контейнера, но использует ТОЛЬКО около 20 системных вызовов к ядру хоста.
• Firecracker: сверхлегкая виртуальная машина Firecracker, работающая в пользовательском пространстве. Заблокировано политиками seccomp, cgroup и namespace, поэтому системные вызовы очень ограничены. Firecracker создан с учетом требований безопасности, но может не поддерживать все развертывания Kubernetes или среды выполнения контейнеров.

Предотвращение загрузки контейнерами нежелательных модулей ядра

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

Чтобы предотвратить автоматическую загрузку определенных модулей, вы можете удалить их с узла или добавить правила для их блокировки. В большинстве дистрибутивов Linux это можно сделать, создав такой файл, как /etc/modprobe.d/kubernetes-blacklist.conf, с таким содержимым:

# DCCP is unlikely to be needed, has had multiple serious
# vulnerabilities, and is not well-maintained.
blacklist dccp

# SCTP is not used in most Kubernetes clusters, and has also had
# vulnerabilities in the past.
blacklist sctp

Чтобы заблокировать загрузку модулей в более широком смысле, вы можете использовать модуль безопасности Linux (например, SELinux), чтобы полностью запретить разрешение module_request для контейнеров, не позволяя ядру загружать модули для контейнеров ни при каких обстоятельствах. (Поды по-прежнему смогут использовать модули, загруженные вручную, или модули, загруженные ядром от имени какого-либо более привилегированного процесса.

Сравнивайте и анализируйте различные действия во время выполнения в модулях одних и тех же развертываний.

Контейнерные приложения реплицируются для обеспечения высокой доступности, отказоустойчивости или масштабируемости. Реплики должны вести себя почти одинаково; реплики со значительными отклонениями от других требуют дальнейшего изучения. Интегрируйте свой инструмент безопасности Kubernetes с другими внешними системами (электронная почта, PagerDuty, Slack, Google Cloud Security Command Center, SIEM [информация о безопасности и управление событиями] и т. д.) и используйте метки развертывания или аннотации, чтобы предупредить команду, ответственную за данное приложение, когда обнаружена потенциальная угроза. Поставщики коммерческих средств безопасности Kubernetes должны поддерживать широкий спектр интеграций с внешними инструментами.

Мониторинг сетевого трафика для ограничения ненужного или небезопасного обмена данными

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

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

С этим могут помочь проекты с открытым исходным кодом, такие как https://github.com/kinvolk/inspektor-gadget или https://github.com/deepfence/PacketStreamer , а коммерческие решения для обеспечения безопасности обеспечивают разную степень анализа сетевого трафика контейнеров.

В случае нарушения масштабируйте подозрительные модули до нуля

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

Часто меняйте учетные данные инфраструктуры

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

Получение предупреждений об обновлениях безопасности и сообщения об уязвимостях

Присоединяйтесь к группе kubernetes-announce (< https://kubernetes.io/docs/reference/issues-security/security/ ), чтобы получать электронные письма об объявлениях о безопасности. См. страницу отчетов о безопасности ( https://kubernetes.io/docs/reference/issues-security/security ) для получения дополнительной информации о том, как сообщать об уязвимостях.

логирование

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

Включить ведение журнала аудита

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

Убедитесь, что журналы отслеживают аномальные или нежелательные вызовы API, особенно любые ошибки авторизации (эти записи журнала будут иметь статус «Запрещено»). Сбои авторизации могут означать, что злоумышленник пытается злоупотребить украденными учетными данными.

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

ЖУРНАЛЫ АУДИТА

Журналы аудита могут быть полезны для соблюдения требований, поскольку они должны помочь вам ответить на вопросы о том, что произошло, кто что сделал и когда. Kubernetes обеспечивает гибкий аудит запросов kube-apiserver на основе политик. Это поможет вам отслеживать все действия в хронологическом порядке.

Вот пример журнала аудита:

{
  "kind":"Event",
  "apiVersion":"audit.k8s.io/v1beta1",
  "metadata":{ "creationTimestamp":"2019-08-22T12:00:00Z" },
  "level":"Metadata",
  "timestamp":"2019-08-22T12:00:00Z",
  "auditID":"23bc44ds-2452-242g-fsf2-4242fe3ggfes",
  "stage":"RequestReceived",
  "requestURI":"/api/v1/namespaces/default/persistentvolumeclaims",
  "verb":"list",
  "user": {
    "username":"user@example.org",
    "groups":[ "system:authenticated" ]
  },
  "sourceIPs":[ "172.12.56.1" ],
  "objectRef": {
    "resource":"persistentvolumeclaims",
    "namespace":"default",
    "apiVersion":"v1"
  },
  "requestReceivedTimestamp":"2019-08-22T12:00:00Z",
  "stageTimestamp":"2019-08-22T12:00:00Z"
}

Определение политик аудита

Политика аудита определяет правила о том, какие события следует регистрировать и какие данные они должны включать. Структура объекта политики аудита определяется в группе API audit.k8s.io. Когда событие обрабатывается, оно сравнивается со списком правил по порядку. Первое правило сопоставления устанавливает «уровень аудита» события.

Известны следующие уровни аудита:

• Нет — не регистрировать события, соответствующие этому правилу.
• Метаданные — метаданные запроса журнала (запрашивающий пользователь, отметка времени, ресурс, команда и т. д.), но не тело запроса или ответа.
• Запрос — регистрирует метаданные события и тело запроса, но не тело ответа. Это не относится к запросам, не связанным с ресурсами.
• RequestResponse — регистрирует метаданные событий, тела запросов и ответов. Это не относится к запросам, не связанным с ресурсами.

Вы можете передать файл с политикой в ​​kube-apiserver с помощью флага –audit-policy-file. Если флаг опущен, никакие события не регистрируются. Обратите внимание, что поле правил должно быть предоставлено в файле политики аудита. Политика без (0) правил считается незаконной.

Понимание ведения журнала

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

ВЕДЕНИЕ ЖУРНАЛА КОНТЕЙНЕРА

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

• Самый простой способ протоколирования контейнеров — запись в стандартный поток вывода (stdout) и стандартный поток ошибок (stderr).

Манифест выглядит следующим образом.

apiVersion: v1
kind: Pod
metadata:
name: example
spec:
containers:
  - name: example
image: busybox
args: [/bin/sh, -c, 'while true; do echo $(date); sleep 1; done']

Чтобы применить манифест, запустите:

kubectl apply -f example.yaml

Чтобы просмотреть журналы для этого контейнера, запустите:

kubectl log <container-name> command.

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

Манифест пода выглядит следующим образом:

apiVersion: v1
kind: Pod
metadata:
  name: example
spec:
  containers:
  - name: example
    image: busybox
    args:
    - /bin/sh
    - -c
    - >
      while true;
      do
        echo "$(date)\n" >> /var/log/example.log;
        sleep 1;
      done
    volumeMounts:
    - name: varlog
      mountPath: /var/log
  - name: sidecar
    image: busybox
    args: [/bin/sh, -c, 'tail -f /var/log/example.log']
    volumeMounts:
    - name: varlog
      mountPath: /var/log
  volumes:
  - name: varlog
    emptyDir: {}

ВЕДЕНИЕ ЖУРНАЛА УЗЛА

Когда контейнер, работающий в Kubernetes, записывает свои журналы в потоки stdout или stderr, механизм контейнера передает их драйверу ведения журналов, настроенному в Kubernetes.

В большинстве случаев эти журналы будут находиться в каталоге /var/log/containers на вашем хосте. Docker поддерживает несколько драйверов ведения журналов, но, к сожалению, конфигурация драйверов не поддерживается через API Kubernetes.

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

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

journalctl -u

ВЕДЕНИЕ ЖУРНАЛА КЛАСТЕРА

На уровне самого кластера Kubernetes существует длинный список компонентов кластера, которые можно регистрировать, а также дополнительные типы данных, которые можно использовать (события, журналы аудита). Вместе эти разные типы данных могут дать вам представление о том, как Kubernetes работает как система.

Некоторые из этих компонентов работают в контейнере, а некоторые — на уровне операционной системы (в большинстве случаев это служба systemd). Службы systemd записывают в журнал, а компоненты, работающие в контейнерах, записывают журналы в каталог /var/log, если механизм контейнера не настроен для потоковой передачи журналов по-другому.

События

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

Следующая команда возвращает все события в определенном пространстве имен:

kubectl get events -n <namespace>

NAMESPACE LAST SEEN TYPE   REASON OBJECT MESSAGE
kube-system  8m22s  Normal   Scheduled            pod/metrics-server-66dbbb67db-lh865                                       Successfully assigned kube-system/metrics-server-66dbbb67db-lh865 to aks-agentpool-42213468-1
kube-system     8m14s               Normal    Pulling                   pod/metrics-server-66dbbb67db-lh865                                       Pulling image "aksrepos.azurecr.io/mirror/metrics-server-amd64:v0.2.1"
kube-system     7m58s               Normal    Pulled                    pod/metrics-server-66dbbb67db-lh865                                       Successfully pulled image "aksrepos.azurecr.io/mirror/metrics-server-amd64:v0.2.1"
kube-system     7m57s               Normal     Created                   pod/metrics-server-66dbbb67db-lh865                                       Created container metrics-server
kube-system     7m57s               Normal    Started                   pod/metrics-server-66dbbb67db-lh865                                       Started container metrics-server
kube-system     8m23s               Normal    SuccessfulCreate          replicaset/metrics-server-66dbbb67db             Created pod: metrics-server-66dbbb67db-lh865

Следующая команда покажет последние события для этого конкретного ресурса Kubernetes:

kubectl describe pod <pod-name>

Events:
  Type    Reason     Age   From                               Message
  ----    ------     ----  ----                               -------
  Normal  Scheduled  14m   default-scheduler                  Successfully assigned kube-system/coredns-7b54b5b97c-dpll7 to aks-agentpool-42213468-1
  Normal  Pulled     13m   kubelet, aks-agentpool-42213468-1  Container image "aksrepos.azurecr.io/mirror/coredns:1.3.1" already present on machine
  Normal  Created    13m   kubelet, aks-agentpool-42213468-1  Created container coredns
  Normal  Started    13m   kubelet, aks-agentpool-42213468-1  Started container coredns

Последние мысли

Внедряйте средства безопасности на ранних этапах жизненного цикла контейнера

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

Используйте встроенные в Kubernetes элементы управления безопасностью, чтобы снизить операционный риск.

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

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

В разросшихся средах Kubernetes ручная сортировка инцидентов безопасности и нарушений политик занимает много времени.

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

Статья является переводом cheatsheetseries.owasp.org