practicum

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

Кластеры 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. С их помощью можно настроить поддержку описанной выше ролевой модели.Примитивные роли viewereditor и admin можно выдавать на сервисы или ресурсы сервиса, и тогда их название строится по принципу сервис.роль или сервис.ресурс.роль. В Managed Kubernetes это выглядит так:

image

Идеология модели сервисных аккаунтов 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.

image

Роли для разработчика

Разработчик будет создавать приложения в кластере, но добавлять и удалять узлы — нет, так как это сфера ответственности DevOps. С учётом этих ограничений разработчику подойдёт роль k8s.cluster-api.editor.Каждое изменение приложения создаёт новый образ — разработчику нужна роль container-registry.images.pusher, чтобы добавлять образы в реестр. Но эту роль следует выдавать только на каталог для разработки, а не на продуктив.

Также разработчику будет полезно отслеживать работу кластера в целом, не вмешиваясь в его работу. Для этого подойдёт k8s.viewer.

image

Роли для кластера K8s

Роль k8s.cluster.agent позволяет создавать в кластере любые объекты, кроме публичных балансировщиков и публичных IP для нод. Также при создании кластера проверяются полномочия сервисного аккаунта, и эта роль позволит создать кластер без доступа в интернет.

Если же системному администратору потребуется предоставлять публичные доступы (доступ кластера в интернет и возможность создавать группы узлов с публичными адресами), ему нужно дать дополнительные роли vpc.publicAdmin или load-balancer.admin.

Роли для узлов K8s

Если вы работаете с Yandex Container Registry, для скачивания образов потребуется роль container-registry.images.puller. Если Container Registry не используется, эта роль не нужна.

Итоги и рекомендации

  • Разворачивая кластеры Kubernetes, не забывайте о безопасности и продумывайте ролевую матрицу для доступа к продуктивной и непродуктивной среде.
  • Используйте возможности Yandex IAM.
  • Осознанно предоставляйте пользователям дополнительные роли для создания публичных ресурсов.
Previous Story

Отказоустойчивость Managed Kubernetes

Next Story

Принципы отказоустойчивости

Latest from Blog

Zabbix – Docker – Raspberry Pi

Для начала установим Portainer – веб-интерфейс для управления docker-контейнерами. Бесплатно, удобно, подойдет новичкам в docker. Установка

Сетевая папка/диск в Linux

x.x.x.x адрес шары /mnt/shara точка монтирования user пользователь с доступом к шаре 1234 пароль пользователя Для

Памятка SSH

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

0 £0.00