Могут ли несколько команд использовать один и тот же кластер Kubernetes?
Можно ли безопасно запускать ненадежные рабочие нагрузки от ненадежных пользователей?
Поддерживает ли Kubernetes мультиарендность?
В этой статье рассмотрим проблемы запуска кластера с несколькими арендаторами.
Мультиарендность можно разделить на:
Фундаментом для совместного использования кластера арендаторами является пространство имен.
Пространства имен группируют ресурсы логически. То есть они не предлагают никаких механизмов безопасности и не гарантируют, что все ресурсы развернуты на одном узле.
Поды в пространстве имен по-прежнему могут взаимодействовать со всеми другими подами в кластере, делать запросы к API и использовать столько ресурсов, сколько захотят.
Из коробки любой пользователь может получить доступ к любому пространству имен.
Как изменить это?
С помощью RBAC вы можете ограничить действия пользователей и приложений с пространством имен и внутри него.
Чаще всего предоставляются определенные разрешения ограниченным пользователям.
С помощью Quotas и LimitRanges вы можете ограничить ресурсы, а также память, ЦП и т.д., которые может использовать определенное пространство имен.
Это отличная идея, если вы хотите ограничить действия арендатора, у которого есть свое пространство имен.
По умолчанию все поды могут взаимодействовать с любыми подами в Kubernetes.
Это не очень хорошо для мультитенантности, но вы можете исправить это с помощью сетевых политик — NetworkPolicies.
Сетевые политики похожи на правила брандмауэра и позволяют разделять исходящий и входящий трафик.
Отлично, теперь пространство имен безопасно?
Не спешите.
Пока что RBAC, NetworkPolicies, Quotas и т. д., дали вам только фундамент для мультиарендности, но этого недостаточно.
Kubernetes имеет несколько общих компонентов.
Хороший пример — контроллер Ingress. Обычно он разворачивается один раз на каждый кластер.
Если вы отправляете Ingress-манифест тем же путем, перезаписывается и работает только один.
Лучше развернуть контроллер для каждого пространства имен.
Еще одна интересная задача — CoreDNS.
Что делать, если один из арендаторов злоупотребляет DNS?
Остальная часть кластера тоже пострадает.
Вы можете ограничить запросы с помощью дополнительного плагина https://github.com/coredns/policy.
Та же проблема относится и к серверу Kubernetes API.
Kubernetes не знает об арендаторе, и если API получает слишком много запросов, то он будет блокировать их для всех.
Я не знаю, есть ли обходной путь для этого!
Предполагаю, что вам удастся разобраться с общими ресурсами, но есть еще проблема с kubelet и рабочими нагрузками.
Как объясняет Филипп Богартс в этой статье, арендатор может взять на себя управление узлами в кластере, просто злоупотребляя проверками на живучесть.
Исправление не тривиальное.
Вы можете использовать линтер как часть CI/CD-процесса или использовать контроллеры допуска для проверки безопасности ресурсов, отправленных в кластер.
Вот библиотека или правила для Open Policy Agent.
У вас также есть контейнеры, которые предлагают более слабый механизм изоляции, чем виртуальные машины.
В этом видео Льюис Денхэм-Пэрри показывает, как избавиться от контейнера.
Как это исправить?
Вы можете использовать контейнерную песочницу, такую как gVisor, легкие виртуальные машины в качестве контейнеров (Kata containers, firecracker + containerd) или полные виртуальные машины (virtlet как CRI).
Надеюсь, вы поняли, что сложность в том, трудно установить жесткие границы для отдельных сетей, рабочих нагрузок и контроллеров в Kubernetes.
Вот почему не рекомендуется предоставлять жесткую мультитенантность в Kubernetes.
Если вам нужна жесткая мультитенантность, советуем вместо этого использовать несколько кластеров или инструмент «Cluster-as-a-Service».
Если вы можете позволить себе более слабую модель с несколькими арендаторами в обмен на простоту и удобство, вы можете выкатить свои RBAC, Quotas и другие правила.
Но есть несколько инструментов, которые возьмут на себя эти проблемы:
habr.com
Можно ли безопасно запускать ненадежные рабочие нагрузки от ненадежных пользователей?
Поддерживает ли Kubernetes мультиарендность?
В этой статье рассмотрим проблемы запуска кластера с несколькими арендаторами.
Мультиарендность можно разделить на:
- Мягкая мультиарендность. Когда вы доверяете своим арендаторам. Например, когда вы делите кластер с командами из одной компании.
- Жесткая мультиарендность. Когда вы не доверяете арендаторам.
Фундаментом для совместного использования кластера арендаторами является пространство имен.
Пространства имен группируют ресурсы логически. То есть они не предлагают никаких механизмов безопасности и не гарантируют, что все ресурсы развернуты на одном узле.
Поды в пространстве имен по-прежнему могут взаимодействовать со всеми другими подами в кластере, делать запросы к API и использовать столько ресурсов, сколько захотят.
Из коробки любой пользователь может получить доступ к любому пространству имен.
Как изменить это?
С помощью RBAC вы можете ограничить действия пользователей и приложений с пространством имен и внутри него.
Чаще всего предоставляются определенные разрешения ограниченным пользователям.
С помощью Quotas и LimitRanges вы можете ограничить ресурсы, а также память, ЦП и т.д., которые может использовать определенное пространство имен.
Это отличная идея, если вы хотите ограничить действия арендатора, у которого есть свое пространство имен.
По умолчанию все поды могут взаимодействовать с любыми подами в Kubernetes.
Это не очень хорошо для мультитенантности, но вы можете исправить это с помощью сетевых политик — NetworkPolicies.
Сетевые политики похожи на правила брандмауэра и позволяют разделять исходящий и входящий трафик.
Отлично, теперь пространство имен безопасно?
Не спешите.
Пока что RBAC, NetworkPolicies, Quotas и т. д., дали вам только фундамент для мультиарендности, но этого недостаточно.
Kubernetes имеет несколько общих компонентов.
Хороший пример — контроллер Ingress. Обычно он разворачивается один раз на каждый кластер.
Если вы отправляете Ingress-манифест тем же путем, перезаписывается и работает только один.
Лучше развернуть контроллер для каждого пространства имен.
Еще одна интересная задача — CoreDNS.
Что делать, если один из арендаторов злоупотребляет DNS?
Остальная часть кластера тоже пострадает.
Вы можете ограничить запросы с помощью дополнительного плагина https://github.com/coredns/policy.
Та же проблема относится и к серверу Kubernetes API.
Kubernetes не знает об арендаторе, и если API получает слишком много запросов, то он будет блокировать их для всех.
Я не знаю, есть ли обходной путь для этого!
Предполагаю, что вам удастся разобраться с общими ресурсами, но есть еще проблема с kubelet и рабочими нагрузками.
Как объясняет Филипп Богартс в этой статье, арендатор может взять на себя управление узлами в кластере, просто злоупотребляя проверками на живучесть.
Исправление не тривиальное.
Вы можете использовать линтер как часть CI/CD-процесса или использовать контроллеры допуска для проверки безопасности ресурсов, отправленных в кластер.
Вот библиотека или правила для Open Policy Agent.
У вас также есть контейнеры, которые предлагают более слабый механизм изоляции, чем виртуальные машины.
В этом видео Льюис Денхэм-Пэрри показывает, как избавиться от контейнера.
Как это исправить?
Вы можете использовать контейнерную песочницу, такую как gVisor, легкие виртуальные машины в качестве контейнеров (Kata containers, firecracker + containerd) или полные виртуальные машины (virtlet как CRI).
Надеюсь, вы поняли, что сложность в том, трудно установить жесткие границы для отдельных сетей, рабочих нагрузок и контроллеров в Kubernetes.
Вот почему не рекомендуется предоставлять жесткую мультитенантность в Kubernetes.
Если вам нужна жесткая мультитенантность, советуем вместо этого использовать несколько кластеров или инструмент «Cluster-as-a-Service».
Если вы можете позволить себе более слабую модель с несколькими арендаторами в обмен на простоту и удобство, вы можете выкатить свои RBAC, Quotas и другие правила.
Но есть несколько инструментов, которые возьмут на себя эти проблемы:
Мультиарендность в Kubernetes
Могут ли несколько команд использовать один и тот же кластер Kubernetes? Можно ли безопасно запускать ненадежные рабочие нагрузки от ненадежных пользователей? Поддерживает ли Kubernetes...
habr.com