Управление доступом
Кратко:
- Надёжность Kubernetes зависит от уровней доступа к объектам и операциям над ними.
- Ролевая модель используется для разграничения доступа к объектам кластера.
- Квоты применяются для ограничения потребления ресурсов в облаке.
- Типичные роли в Kubernetes: администратор облака, сетевой администратор, специалист по безопасности, разработчик, DevOps/SRE, инструменты CI/CD.
- Роли для управления ресурсами внутри кластера и в Managed Kubernetes различаются.
- В Yandex Cloud используются роли для управления ресурсами и доступа к ним.
- Разделение рабочих и тестовых сред с помощью каталогов и настройка политик ролей и квот.
- Примеры ролей для DevOps/SRE, разработчика, кластера K8s и узлов K8s.
- Безопасность и продумывание ролевой матрицы для доступа к продуктивной и непродуктивной среде.
Управление доступом
Кластеры Kubernetes широко используются для решения самых разных задач. Поэтому надёжность — бесперебойная работа и защита данных — очень важны. Надёжность определяется уровнями доступа к объектам кластера и операциям над ними.
Для разграничения доступа используется ролевая модель. Подробно о ней рассказывается в курсе «Безопасность». А в этом уроке вы узнаете, как её можно применять для работы с кластером Kubernetes.
Ролевой доступ
Роль — это набор разрешений, описывающих допустимые операции с ресурсом. Вы предоставляете пользователю доступ к ресурсу, назначая ему роли. Пользователем может быть не только человек, но и команда, отдел или даже автоматизированные инструменты (например инструменты CI/CD).
Для ограничения потребления ресурсов в облаке применяются квоты. Квота — это количество ресурсов, которое пользователь может употребить.
Вот несколько типичных ролей при использовании кластера Kubernetes:
- администратор облака — даёт доступ в облако и выделяет квоты;
- сетевой администратор — организует и разграничивает доступ к ресурсам, но сам их не использует;
- специалист по безопасности — наблюдает за тем, что происходит, не потребляет ресурсов;
- разработчик — пишет код, создаёт пул-реквесты и, соответственно, новые образы контейнеров;
- DevOps/SRE — управляет кластером Kubernetes и реестром образов;
- Инструменты CI/CD — запускают приложения в рабочей среде. Именно от их имени часто потребляются основные ресурсы.
Для работы с кластером Kubernetes можно выделить две группы ролей:
- Роли для управления ресурсами внутри кластера.
- Роли в Managed Kubernetes, которые обеспечивают интеграцию кластера в облако.
Рассмотрим вторую группу.
Ролевая модель в Yandex Cloud
Как вы знаете, в Yandex.Cloud доступ к ресурсам контролирует сервис Yandex IAM (Identity and Access Management) и его система сервисных аккаунтов. В IAM есть роли и для Managed Kubernetes, и для Container Registry. С их помощью можно настроить поддержку описанной выше ролевой модели.
Примитивные роли
viewer, editor и admin можно выдавать на сервисы или ресурсы сервиса, и тогда их название строится по принципу сервис.роль или сервис.ресурс.роль. В Managed Kubernetes это выглядит так:
Идеология ролевой модели Yandex Cloud — чёткое разграничение публичных и непубличных ресурсов. Поэтому все роли, предоставляемые по умолчанию, не позволяют открывать публичный доступ к ресурсам. Чтобы пользователь мог создавать публичные ресурсы, необходимо осознанно предоставить ему дополнительные роли.
Как правило, для безопасной разработки и эксплуатации приложений поддерживаются как минимум две среды: рабочая (для пользователей) и среда разработки и тестирования. Можно разделить эти среды в облаке с помощью каталогов и настроить для каждого каталога свою политику ролей и квот. Любому пользователю для работы в каталоге понадобится роль
viewer.В документации Managed Kubernetes описаны все возможные роли. Ниже мы приведем несколько примеров того, как с помощью ролей Yandex Cloud предоставлять доступ пользователям в реальных задачах.
Роли для DevOps/SRE
Задача DevOps — обеспечить ресурсы для работы приложения и организовать регулярные обновления приложения. Посмотрим, какие роли для этого нужны.
Чтобы создавать кластеры Kubernetes, нужна роль
k8s.admin. Это роль по умолчанию, и поэтому (как мы уже говорили выше) она не даёт возможности открывать публичный доступ. Чтобы создать кластер с публичным доступом, потребуется дополнительная роль vpc.publicAdmin.Например, чтобы команда разработки случайно не создала публично доступный кластер, ограничьте её ролью
k8s.admin, а роль vpc.publicAdmin предоставьте только сотрудникам DevOps/SRE.Чтобы установить системные приложения в кластере, команде DevOps/SRE потребуется полный административный доступ. Это роль
k8s.cluster-api.cluster-admin.Чтобы подключить кластер к сети, нужна роль
vpc.user. Чтобы управлять сервисными аккаунтами кластера — iam.serviceAccounts.user.Чтобы обновлять приложение, нужна возможность помещать новый образ в реестр, создавать машины с помощью образа из реестра, а также удалять ненужные образы. Для управления образами в реестре подойдет роль
container-registry.admin.
Роли для разработчика
Разработчик будет создавать приложения в кластере, но добавлять и удалять узлы — нет, так как это сфера ответственности DevOps. С учётом этих ограничений разработчику подойдёт роль
k8s.cluster-api.editor.Каждое изменение приложения создаёт новый образ — разработчику нужна роль
container-registry.images.pusher, чтобы добавлять образы в реестр. Но эту роль следует выдавать только на каталог для разработки, а не на продуктив.Также разработчику будет полезно отслеживать работу кластера в целом, не вмешиваясь в его работу. Для этого подойдёт
k8s.viewer.
Роли для кластера K8s
Роль
k8s.cluster.agent позволяет создавать в кластере любые объекты, кроме публичных балансировщиков и публичных IP-адресов для нод. Также при создании кластера проверяются полномочия сервисного аккаунта, и эта роль позволит создать кластер без доступа в интернет.Если же системному администратору потребуется предоставлять публичные доступы (доступ кластера в интернет и возможность создавать группы узлов с публичными адресами), ему нужно дать дополнительные роли
vpc.publicAdmin или load-balancer.admin.Роли для узлов K8s
Если вы работаете с Yandex Container Registry, для скачивания образов потребуется роль
container-registry.images.puller. Если Container Registry не используется, эта роль не нужна.Итоги и рекомендации
- Разворачивая кластеры Kubernetes, не забывайте о безопасности и продумывайте ролевую матрицу для доступа к продуктивной и непродуктивной среде.
- Используйте возможности Yandex IAM.
- Осознанно предоставляйте пользователям дополнительные роли для создания публичных ресурсов.
Поздравляем, вы завершили тему «Managed Kubernetes»
Мы завершили обзор Yandex Managed Kubernetes. Вы познакомились с устройством кластера, общими принципами балансировки нагрузки внутри кластера, автоматического масштабирования и мониторинга.
Раньше мы разобрали преимущества контейнеров, и теперь вы знаете, как автоматизировать управление контейнерами средствами Kubernetes. Благодаря интеграции с другими сервисами Yandex Cloud сервис Managed Kubernetes снимает часть головной боли с администраторов и упрощает использование облачных ресурсов.
Обратите внимание: чтобы не расходовать зря средства на балансе в облаке — удалите кластер Kubernetes, с которым вы работали на предыдущих уроках.