Ответственный подход к общению с API-сервером: Контроллеры допуска


Немного теории

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

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

Контроллеры допуска (AC) позволяют добавить дополнительные опции к работе Kubernetes для изменения или проверки объектов при выполнении запросов к API Kubernetes.

🖼️ Источник фото: Giant Swarm

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

Если контроллер отклоняет запрос, то весь запрос к серверу API отклоняется и конечному пользователю возвращается ошибка.

Чтобы активировать обсуждаемые контроллеры, необходимо указать их имена в виде списка при создании или обновлении кластера. После этого kube-apiserver будет запущен или перезапущен с опцией --enable-admission-plugins и установленными контроллерами доступа.

Передача контроллера, недоступного для текущей версии Kubernetes, вернет соответствующую ошибку.

Какими именно могут быть AC?

🔬 В рамках реализации

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

LimitRanger следит за тем, чтобы любые ограничения, перечисленные в объекте LimitRange в пространстве имен, не были нарушены входящими запросами. Используйте этот контроллер допуска для наложения таких ограничений, если вы используете объекты LimitRange в своей конфигурации Kubernetes. Применение стандартных запросов ресурсов к стручкам без каких-либо спецификаций также возможно с помощью этого AC.

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

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

Есть и динамические. Подробности см. ниже.

🔬 В области обработки запросов

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

⚙️ Первый тип — это проверяющий контроллер допуска ValidatingAdmissionWebhook, который проксирует запросы на подписанные веб-крючки. API Kubernetes регистрирует веб-крючки на основе типа ресурса и метода запроса. Каждый webhook выполняет определенную логику для проверки входящего ресурса и отвечает API вердиктом.

Если веб-крючок проверки отклоняет запрос, Kubernetes API возвращает пользователю HTTP-ответ о неудаче. В противном случае он продолжает следующий прием.

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

Крюки! Крючки повсюду!

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

Если ресурсы — это просто конечные точки API Kubernetes, то написание контроллера для ресурса — это просто причудливый способ привязать обработчик запроса к конечной точке API!

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

Можно динамически настраивать, какие ресурсы подпадают под действие вебхуков допуска, с помощью видов ValidatingWebhookConfiguration или MutatingWebhookConfiguration.

Оба доступны в версии API admissionregistration.k8s.io/v1.

$ kubectl api-versions | grep admiss
admissionregistration.k8s.io/v1
admissionregistration.k8s.io/v1beta1
Вход в полноэкранный режим Выход из полноэкранного режима

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

Для использования перед изменением объектов кластера, флаг сервера Kubernetes API --enable-admission-plugins принимает список плагинов AC через запятую. Например, следующая командная строка активирует плагины управления допуском LimitRanger и NamespaceLifecycle:

kube-apiserver --enable-admission-plugins=NamespaceLifecycle,LimitRanger
Войти в полноэкранный режим Выход из полноэкранного режима

⚠️ Примечание: Вам может потребоваться применить параметры по-разному в зависимости от того, как установлен ваш кластер Kubernetes и как запущен сервер API. Например, если Kubernetes развернут с помощью self-hosted Kubernetes, вам может потребоваться изменить файл манифеста для сервера API и/или файл systemd Unit, если сервер API установлен как служба systemd.

⚠️ Примечание: API вид admissionregistration.k8s.io/v1beta1 стал устаревшим в версии 1.22+.

Реализация провайдерами публичного облака

В этом случае все уже настроено за вас.

Чтобы узнать больше об использовании динамических контроллеров допуска с Amazon EKS, смотрите документацию Amazon EKS.

Azure AKS Policy, реализация OPA Gatekeeper от Microsoft, — еще одна интересная вещь. Привлекая AC webhooks, при возникновении проблем в конвейере контроля допуска он может блокировать многочисленные запросы к API-серверу.

Команда VMware Tanzu пошла по аналогичному пути в своей Tanzu Kubernetes Grid (TKG).

Конечно, сам OPA Gatekeeper — это отдельная и обширная тема, поэтому подробнее об этом в другой раз.

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

Будьте внимательны и следите за новостями!

Большое спасибо Леониду Сандлеру, Дугласу Макею @douglasmakey Mendez Molero, Луке 🐦 @LucaDiMaio11 Di Maio, Кристияну Митевски и В.Т. Чангу!

Оцените статью
devanswers.ru
Добавить комментарий