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

Администрирование интеграции с Яндекс Облаком

Что вы сделаете

Вы настроите и будете сопровождать подключение ИИ Студии к Яндекс Облаку так, чтобы модель могла безопасно анализировать инфраструктуру и расходы, но не получала произвольных полномочий на изменение ресурсов.


1. Архитектура доступа

В продуктовом профиле модель не получает ключ Яндекс Облака напрямую.

Схема:

пользователь
ИИ Студия
шлюз НайсСофт
серверная политика
IAM Яндекс Облака
разрешённые API/сервисы

Авторизованный ключ и IAM-токен остаются на серверной стороне.


2. Что подготовить

Понадобятся:

  • отдельная служебная учётная запись;
  • авторизованный JSON-ключ;
  • идентификатор рабочего каталога;
  • понимание, к какому облаку относится каталог;
  • минимальные роли;
  • при FinOps — доступ к платёжному аккаунту;
  • при Yandex AI — роль на отдельном каталоге AI Studio.

3. Служебная учётная запись

Не используйте личную учётную запись сотрудника.

Хорошее правило:

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

Название должно позволять понять назначение.

Например:

nicesoft-ai-studio-reader

Буквальное имя выбирает ваша организация.


4. Авторизованный ключ

Ключ содержит закрытую криптографическую часть.

Правила:

  • создавайте на служебной учётной записи;
  • скачивайте один раз;
  • загружайте через административный интерфейс Студии;
  • не пересылайте в мессенджере;
  • не храните в Git;
  • не вставляйте в чат;
  • после ротации удаляйте старый ключ в Яндекс Облаке.

5. Рабочий каталог

Рабочий каталог определяет область инфраструктурного анализа.

Администратор задаёт Folder ID.

Cloud определяется из каталога и используется для проверки согласованности области.

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


6. Быстрый базовый доступ

Для первичной диагностики можно использовать ограниченную роль чтения на нужном каталоге, если это соответствует политике организации.

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

Причина:

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


7. Object Storage

Будьте особенно осторожны с бакетами.

Право просмотра конфигурации и право чтения содержимого объектов — не одно и то же.

Если Студии нужны только метаданные инфраструктуры, не выдавайте чтение содержимого бакетов без отдельной причины.


8. FinOps

Права Billing назначаются на платёжный аккаунт, а не на рабочий каталог.

Для детализации используйте минимальную роль просмотра платёжных данных, принятую в текущей документации Яндекс Облака.

Разделяйте:

инфраструктурная область
платёжная область

9. Yandex AI

Yandex AI Studio использует отдельную логическую область.

Роль ai.languageModels.user должна быть назначена на правильный каталог AI Studio либо наследоваться на него.

Не пытайтесь лечить ошибку AI Studio изменением Working Folder, если проблема относится к каталогу служебной учётной записи.


10. Подключение

  1. Откройте «Интеграция с Яндекс Облаком».
  2. Загрузите авторизованный ключ.
  3. Убедитесь, что ключ принят сервером.
  4. Укажите рабочий Folder ID.
  5. Запустите проверку.
  6. Дождитесь определения Cloud.
  7. Проверьте инфраструктурные сервисы.
  8. При необходимости проверьте Billing.
  9. При необходимости проверьте Yandex AI.

11. Диагностика

Используйте:

./nicesoft.sh yc-doctor

Чтение результата идёт сверху вниз.

Сначала учётные данные

Пример логики:

IAM auth available: YES

означает, что шлюз способен получить учётные данные.

Затем привязка

Наличие ключа не означает, что рабочий каталог уже выбран.

Затем конкретный сервис

Только после успешной аутентификации и области диагностируйте Compute, VPC, Billing или Yandex AI.


12. 401

Обычно проверяйте:

  • ключ;
  • отзыв ключа;
  • системное время;
  • сетевой доступ к IAM;
  • TLS;
  • формат файла.

13. 403

Это чаще всего права.

Алгоритм:

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

Не выдавайте полный admin без анализа.


14. 404

Проверьте:

  • идентификатор;
  • каталог;
  • облако;
  • регион;
  • удалён ли объект;
  • доступен ли ресурс этой служебной учётной записи.

Иногда ресурс с отсутствующим правом может выглядеть как «не найден» в зависимости от сервиса.


15. 429

Означает ограничение частоты или квоты.

Для Billing особенно важно использовать кэш и компактные агрегаты вместо постоянной полной детализации.

Не делайте цикл «повторять каждые 100 мс».

Используйте:

  • кэш;
  • экспоненциальную задержку;
  • запрос детализации только по необходимости.

16. Проверка режима только чтения

После подключения обязательно сделайте отрицательный тест.

Безопасный вариант:

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

Не тестируйте удаление на производственном объекте.


17. FinOps после подключения

Проверьте последовательно:

  1. обзор текущего периода;
  2. cost;
  3. credits;
  4. expense;
  5. сравнение с предыдущим периодом;
  6. детализацию по сервису;
  7. детализацию по SKU;
  8. ресурс, если атрибуция доступна;
  9. бюджет;
  10. рекомендации только на основе полученных данных.

18. Кэш FinOps

Кэш нужен не только для скорости.

Он:

  • снижает нагрузку на API Billing;
  • уменьшает объём данных, попадающих в контекст модели;
  • делает ответы повторяемее;
  • позволяет отделить «данные» от «интерпретации».

Не отключайте кэш ради ощущения «всегда свежо», не оценив лимиты API.


19. Ротация ключа

  1. Создайте новый ключ.
  2. Не удаляйте старый сразу.
  3. Загрузите новый в Студию.
  4. Проверьте yc-doctor.
  5. Проверьте инфраструктуру.
  6. Проверьте Billing.
  7. Проверьте Yandex AI.
  8. Удалите старый ключ в Яндекс Облаке.
  9. Удалите старую локальную копию.

20. Ревизия прав

Раз в квартал или по внутреннему регламенту:

  • выпишите роли служебной учётной записи;
  • удалите лишние;
  • проверьте уровни наследования;
  • проверьте доступ к бакетам;
  • проверьте Billing;
  • проверьте AI Studio;
  • повторите отрицательный тест изменения.

21. Что хранить в паспорте интеграции

Служебная учётная запись:
Рабочий Folder:
Cloud:
AI Studio Folder:
Billing Account:
Роли:
Дата последней ротации ключа:
Дата проверки yc-doctor:
Ответственный:

Не записывайте сам закрытый ключ в этот паспорт.


Что дальше

Полная пользовательская и техническая схема находится в разделе «Интеграция с Яндекс Облаком».