Перейти к содержанию

Облако и каталог: как устроен область доступа

Самая частая архитектурная ошибка при подключении Яндекс Облака — считать, что существует один-единственный folder_id, который одновременно определяет инфраструктуру, Billing и Yandex AI.

В ИИ Студии эти области разделены намеренно.

Что такое облако и каталог

В Яндекс Облаке ресурсы организованы иерархически.

Упрощённо:

Организация
    ↓
Cloud
    ↓
Folder A
Folder B
Folder C

Большинство инфраструктурных ресурсов создаются внутри конкретного каталог.

Роли, назначенные выше по иерархии, могут наследоваться вложенными ресурсами.

1. Рабочий каталог ИИ Студии

Рабочий каталог — это каталог, к которому ИИ Студия привязывает обычную пользовательскую область доступа только для чтения.

Пример:

Cloud: company-prod
Folder: web-prod

После привязка обычный пользователь должен анализировать ресурсы именно web-prod, а не произвольный соседний каталог.

Это защищает от ситуации, когда у служебная учётная запись технически есть более широкие права, чем нужно конкретной группе пользователей.

2. Зачем нужен привязка, если роли уже существуют

Роли отвечают на вопрос:

что служебная учётная запись вообще может читать в Яндекс Облаке?

Привязка отвечает на другой вопрос:

какую область ИИ Студия должна считать рабочей для пользователей этого экземпляра?

То есть сервер использует сразу два ограничения:

разрешения Yandex IAM
∩
область доступа ИИ Студии
=
фактически доступная область

Даже если IAM позволяет больше, NiceSoft Шлюз может сузить рабочий область доступа.

3. идентификатор облака

идентификатор облака идентифицирует облако, которому принадлежит каталог.

В текущем сценарии привязка основной обязательный ввод — идентификатор каталога; облако может быть определено и проверено сервером из этого каталога.

Если интерфейс показывает идентификатор облака отдельно, используйте его как контроль:

  • выбран правильный облако;
  • каталог действительно принадлежит ожидаемому облаку;
  • вы не скопировали ID из другой среды.

4. каталог AI Studio — отдельное понятие

Для моделей Yandex AI Studio нужен каталог, используемый для model URI и авторизации.

В текущей интеграции Студия определяет каталог AI Studio из самой служебной учётной записи и показывает его в Model Control Center.

Это может не совпадать с рабочим каталог.

Например:

home / AI Studio Folder: platform-services
рабочий каталог: production-app

Тогда:

  • инфраструктура читается из production-app;
  • роль ai.languageModels.user должна быть действительна для platform-services;
  • Yandex AI запросы используют каталог AI Studio;
  • обычному USER не разрешается подменить его произвольным ID из браузера.

5. платёжный аккаунт не является каталог

платёжный аккаунт — самостоятельный финансовый объект.

Он может обслуживать:

  • несколько облаков;
  • несколько каталог;
  • множество сервисов и ресурсов.

Поэтому роль viewer на каталог не даёт автоматически billing.accounts.viewer.

А роль billing.accounts.viewer не должна автоматически означать, что обычный пользователь Студии видит расходы всего аккаунта.

В текущем профиле USER financial usage серверно сужается до подключённого рабочего каталога.

6. Как выбрать рабочий каталог

Не выбирайте каталог «на глаз».

Шаг 1. Определите бизнес-область

Ответьте:

  • какой проект должны видеть сотрудники;
  • какие ресурсы относятся к этому проекту;
  • есть ли отдельные prod/test/dev каталоги;
  • должна ли одна установка Студии работать только с одним из них.

Шаг 2. Получите идентификатор каталога

Можно использовать консоль управления или CLI.

Пример CLI:

yc resource-manager folder list

Шаг 3. Сверьте облако

Убедитесь, что каталог находится в ожидаемом облаке.

Шаг 4. Назначьте служебная учётная запись только нужные права

Предпочтительно на каталог, а не на всё облако.

Шаг 5. Выполните привязка

В Студии:

Интеграция с YC → Подключение YC → идентификатор каталога → Проверить указанные ID и подключить.

7. Как проверить, что область доступа правильная

После подключения задайте вопрос:

Покажи ID и название текущего рабочего каталога и перечисли пять ресурсов из него.

Затем задайте контрольный вопрос о заведомо известном ресурсе из соседнего каталог:

Найди виртуальную машину <имя-ресурса-из-другого-folder>.

Если USER видит то, чего не должен видеть по продуктовой политике, остановите внедрение и проверьте область доступа/RBAC.

8. Как изменить рабочий каталог

Изменение рабочего каталога — это изменение границы доступа, а не косметической настройки.

Перед переключением:

  1. убедитесь, что служебная учётная запись имеет нужные права на новый каталог;
  2. проверьте, не изменится ли финансовый область доступа пользователей;
  3. предупредите владельцев помощников/плановых отчётов;
  4. проверьте, не завязаны ли сохранённые инструкции на старые имена ресурсов.

После переключения:

  1. выполните yc-doctor;
  2. запросите список ВМ;
  3. запросите сети;
  4. запросите IAM метаданные;
  5. проверьте FinOps;
  6. проверьте scheduled reports.

9. Один экземпляр Студии и несколько каталог

Текущий основной пользовательский сценарий строится вокруг одного подключённого рабочего каталога.

Если организация хочет разные изолированные области, безопасные варианты:

  • отдельные экземпляры Студии;
  • отдельные служебные аккаунты;
  • отдельные политики/группы, если такая конфигурация явно поддержана текущим release;
  • централизованный корпоративный слой, который осознанно агрегирует данные.

Не следует выдавать всем один служебная учётная запись с viewer на всю организацию только ради удобства.

10. Наследование ролей

Роль может быть назначена:

  • на организацию;
  • на облако;
  • на каталог;
  • на отдельный ресурс — если сервис это поддерживает.

Роль на более высоком уровне обычно действует на вложенные ресурсы.

Это значит, что служебная учётная запись может иметь доступ к каталогу даже если вы не видите отдельное назначение роли непосредственно на нём.

При расследовании 403 всегда проверяйте всю цепочку наследования.

11. Политики авторизации Яндекс Облака

Наличие роли не гарантирует, что операция будет разрешена, если на организации/облаке/каталоге действует дополнительная политика авторизации.

Поэтому ситуация:

роль есть
+
операция всё равно запрещена

может быть нормальным результатом корпоративной политики Яндекс Облако.

12. Типовые схемы

Простая компания

Cloud: company
Folder: production
домашний каталог служебной учётной записи: production
рабочий каталог: production
каталог AI Studio: production

Самая простая схема.

Platform team + application team

Cloud: company
Каталог: platform-services   ← домашний каталог служебной учётной записи / AI Studio
Каталог: app-production     ← рабочий каталог

Требует явного понимания двух каталог.

Несколько бизнес-проектов

Cloud: company
Folder: project-a
Folder: project-b
Folder: project-c

Не надо автоматически давать одному USER доступ ко всем трём только потому, что служебная учётная запись умеет их читать.

13. Диагностика область доступа

Проверяйте по уровням.

Учётные данные

IAM auth available: YES

Привязка

Folder configured: YES
Cloud configured: YES

Yandex IAM

Может ли служебная учётная запись выполнить нужный запрос API только для чтения?

NiceSoft RBAC

Разрешена ли эта capability пользователю?

Область доступа операции

Передал ли шлюз правильные каталог/облако headers?

Что дальше