Кластеры Kubernetes® широко используются для решения самых разных задач. Поэтому надёжность — бесперебойная работа и защита данных — очень важны. Надёжность определяется уровнями доступа к объектам кластера и операциям над ними.Для разграничения доступа используется ролевая модель. Подробно о ней рассказывается в курсе «Безопасность». А в этом уроке вы узнаете, как её можно применять для работы с кластером Kubernetes.
Ролевой доступ
Роль — это набор разрешений, описывающих допустимые операции с ресурсом. Вы предоставляете пользователю доступ к ресурсу, назначая ему роли. Пользователем может быть не только человек, но и команда, отдел или даже автоматизированные инструменты (например, инструменты CI/CD).Для ограничения потребления ресурсов в облаке применяются квоты.
Квота — это количество ресурсов, которое пользователь может употребить.Вот несколько типичных ролей при использовании кластера Kubernetes:
- администратор облака — даёт доступ в облако и выделяет квоты;
- сетевой администратор — организует и разграничивает доступ к ресурсам, но сам их не использует;
- специалист по безопасности — наблюдает за тем, что происходит, не потребляет ресурсов;
- разработчик — пишет код, создаёт pull-request’ы и, соответственно, новые образы контейнеров;
- DevOps/SRE — управляет кластером Kubernetes и реестром образов;
- Инструменты CI/CD — запускают приложения в рабочей среде. Именно от их имени часто потребляются основные ресурсы.
Для работы с кластером Kubernetes можно выделить две группы ролей: 1) роли для управления ресурсами внутри кластера и 2) роли в 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.
- Осознанно предоставляйте пользователям дополнительные роли для создания публичных ресурсов.
