Создание пользовательского tenant'а

Создание пользовательского tenant’а

4. Создание пользовательского tenant’а и настройка доступа

Цели

На этом шаге вы создадите пользовательский tenant — пространство, в котором пользователи смогут развёртывать приложения и виртуальные машины. Вы также получите учётные данные tenant’а и войдёте как пользователь с доступом к этому tenant’у.

Предварительные требования

Перед началом:

Завершите предыдущие шаги руководства, чтобы получить работающий кластер Cozystack, в котором уже настроены хранилище, сеть и управляющий дашборд.
Убедитесь, что у вас есть доступ к дашборду, как описано на предыдущем шаге руководства.
Если вы используете OIDC, пользователи и роли уже должны быть настроены. Подробности о работе со встроенным OIDC-сервером см. в руководстве по OIDC.

Во время установки Kubernetes для Cozystack вы должны были получить административный файл kubeconfig для нового кластера. Держите его под рукой — позже он может пригодиться для диагностики. Однако для повседневной работы лучше создать отдельные пользовательские учётные данные.

Введение

Tenant’ы — это механизм изоляции в Cozystack. Они используются для разделения клиентов, команд или окружений. У каждого tenant’а есть собственный набор приложений и один или несколько вложенных Kubernetes-кластеров. Пользователи tenant’а имеют полный доступ к своим кластерам. При необходимости вы можете настроить квоты для каждого tenant’а, чтобы ограничить потребление ресурсов и избежать перерасхода.

Чтобы узнать о tenant’ах больше, прочитайте руководство Core Concepts.

Создание tenant’а

Tenant’ы создаются с помощью приложения Cozystack с именем Tenant. После установки в Cozystack уже существует встроенный tenant tenant-root. Этот корневой tenant зарезервирован для администраторов платформы и должен использоваться только для создания дочерних tenant’ов. Технически установить приложения в tenant-root можно, но для production-окружений это не рекомендуется.

Через дашборд

Откройте дашборд от имени пользователя tenant-root.
Убедитесь, что текущий контекст установлен в tenant-root. При необходимости переключите контекст и перезагрузите страницу.
Перейдите на вкладку Catalog.
Найдите приложение Tenant и откройте его.
Ознакомьтесь с документацией, затем нажмите кнопку Deploy, чтобы перейти к странице параметров.
Заполните поле name tenant’а. Это единственный параметр, который нельзя изменить позже.
(Необязательно) Заполните доменное имя в host. Это доменное имя уже должно существовать. Убедитесь, что пользователь tenant’а имеет достаточный контроль над доменом для настройки DNS-записей. Если оставить поле пустым, по умолчанию будет использован домен <name>.<cozystack-domain>.
Отметьте флажки для установки системных приложений: etcd, monitoring, ingress и seaweedfs. Пользователи tenant’а не смогут устанавливать или удалять эти приложения — это могут делать только администраторы. Параметр etcd требуется для вложенного Kubernetes. Выберите его до установки приложения Kubernetes в tenant’е. Отключайте его только если уверены, что tenant не будет использовать вложенный Kubernetes.
По умолчанию ресурсные квоты не задаются. Это означает отсутствие ограничений на использование ресурсов. При необходимости можно определить квоты, чтобы избежать их перерасхода.
Нажмите Deploy, чтобы установить приложение tenant’а в корневой tenant.

Через kubectl

Создайте манифест HelmRelease для tenant’а. В качестве отправной точки можно взять манифест, созданный через дашборд:

apiVersion: helm.toolkit.fluxcd.io/v2
kind: HelmRelease
metadata:
  name: tenant-team1
  namespace: tenant-root
spec:
  chart:
    spec:
      chart: tenant
      reconcileStrategy: Revision
      sourceRef:
        kind: HelmRepository
        name: cozystack-apps
        namespace: cozy-public
      version: 1.9.1
  interval: 0s
  values:
    etcd: true
    host: team1.example.org
    ingress: true
    monitoring: false
    resourceQuotas: {}
    seaweedfs: false

Примените манифест:

# Используйте kubeconfig корневого tenant'а
export KUBECONFIG=./kubeconfig-tenant-root

# Примените манифест
kubectl -n tenant-root apply -f hr-tenant-team1.yaml

Примечание об изоляции: Сетевые политики Cilium в Cozystack v1.0+ всегда изолируют соседние tenant’ы друг от друга — поля isolated больше нет ни в форме дашборда, ни в значениях HelmRelease. Pod’ы внутри namespace tenant’а также по умолчанию не могут обращаться к kube-apiserver, а при создании tenant’а с etcd: true ещё и к собственному etcd. Чтобы разрешить pod’у один из этих путей, добавьте ему метку policy.cozystack.io/allow-to-apiserver: "true" или policy.cozystack.io/allow-to-etcd: "true" соответственно. Полную таблицу и пример см. в примечаниях к обновлению: Tenant isolated flag removed.

Вы можете помогать пользователям tenant’ов с установкой баз данных или вложенных Kubernetes-кластеров. Администратор может переключать контекст в дашборде и получать доступ к любому tenant’у. Пользователи tenant’а, в свою очередь, могут работать только со своим tenant’ом и его дочерними tenant’ами.

Получение kubeconfig tenant’а

Пользователям tenant’а нужен файл kubeconfig для доступа к своему Kubernetes-кластеру. Способ его получения зависит от того, включён ли OIDC в вашей установке Cozystack.

Если OIDC включён

Вы можете получить kubeconfig напрямую из дашборда, как описано в руководстве по OIDC.

Если OIDC выключен

В этом случае администратору нужно получить токен service account из namespace tenant’а. Секрет с токеном имеет то же имя, что и tenant.

Чтобы получить токен для tenant’а с именем team1, выполните:

kubectl -n tenant-team1 get secret tenant-team1 -o json | jq -r '.data.token | @base64d'

Затем подставьте этот токен в шаблон kubeconfig и сохраните файл под именем kubeconfig-tenant-<name>.yaml.

Обязательно задайте namespace по умолчанию равным имени tenant’а. Многие GUI-клиенты будут показывать ошибки доступа, если namespace не указан явно.

Тот же токен можно использовать и для входа пользователя tenant’а в дашборд Cozystack, если OIDC отключён.

Получение kubeconfig вложенного Kubernetes

Как правило, администраторам не нужно получать kubeconfig для вложенных Kubernetes-кластеров. Такие кластеры устанавливаются самим пользователем tenant’а внутри его namespace. Пользователи tenant’а полностью контролируют свои вложенные Kubernetes-окружения.

Чтобы получить доступ к вложенному Kubernetes-кластеру, пользователь tenant’а может скачать kubeconfig прямо со страницы соответствующего приложения в дашборде.