yandex-cloud-install.sh — что делает скрипт

Yandex Cloud Read-only Идемпотентно

yandex-cloud-install.sh — bash-скрипт, который автоматизирует подключение Yandex Cloud к OpsMan AI. Один запуск создаёт всё необходимое (бакет, два сервисных аккаунта, ключи, роли) и отправляет credentials обратно в платформу через защищённый callback.

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

TL;DR

Свойство	Значение
Запускает sudo?	Нет
Трогает прод-ресурсы?	Нет — только создаёт новые SA и бакет
Удаляет что-либо?	Нет
Какие роли выдаёт?	Только viewer / monitoring.viewer / billing.accounts.viewer / storage.editor (на специально созданный каталог-бакет)
Какие ключи создаёт?	1 статический S3-ключ + 1 авторизованный JSON-ключ
Куда отправляются credentials?	https://api.opsman.ai/api/v2/cloud/helm/callback (только если задан TOKEN)
Что сохраняется локально?	finops-radar-credentials.txt в текущей директории
Можно ли запустить идемпотентно?	Да — повторный запуск не пересоздаст уже существующие SA / бакет

Источник скрипта

Начиная с 2026-04, у скрипта две региональных версии на новом домене files.opsman.ai:

• Россия (ru): https://files.opsman.ai/yandex-ru-cloud-install.sh
• Казахстан (kz): https://files.opsman.ai/yandex-kz-cloud-install.sh

Обе одинаковы по структуре и шагам, разница — в endpoint’ах, с которыми работают (S3 storage.yandexcloud.kz vs storage.yandexcloud.net, IAM iam.api.yandexcloud.kz vs iam.api.cloud.yandex.net). Размер каждого — ~15 KB, ~630 строк. Хостятся на инфраструктуре OpsMan AI.

Скачать без выполнения, чтобы прочитать самому (пример для RU, для KZ — замените yandex-ru- на yandex-kz-):

curl -sSL https://files.opsman.ai/yandex-ru-cloud-install.sh -o yandex-ru-cloud-install.sh
less yandex-ru-cloud-install.sh        # читаем
sha256sum yandex-ru-cloud-install.sh   # фиксируем хеш
TOKEN=... CLUSTER=... bash yandex-ru-cloud-install.sh   # запускаем после проверки

Что требуется заранее

Зависимость	Зачем
yc CLI	Все операции с Yandex Cloud (создание SA, бакета, выдача ролей)
jq	Разбор JSON-ответов от yc и Billing API
curl	HTTP-запросы к Billing API и callback в OpsMan AI
Активный профиль yc	yc config get cloud-id и yc config get folder-id должны возвращать значения

Текущий пользователь Yandex Cloud должен иметь:

• права editor или admin на каталог (для создания SA, бакета);
• роль billing.accounts.admin или billing.accounts.owner на платёжный аккаунт.

Если права на billing нет, скрипт не упадёт — он сделает всё, что может, но Шаг 8 (выдача billing.accounts.viewer сервисному аккаунту) завершится с warning’ом, и эту роль придётся выдать вручную через UI.

Параметры

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

Переменная	Default	Что управляет
TOKEN	(пусто)	Одноразовый токен из UI OpsMan AI. Без него callback пропускается.
CLUSTER	(пусто)	Идентификатор кластера в OpsMan AI. Передаётся в callback.
BUCKET_NAME	finops-billing-export	Имя бакета для биллинг-экспорта.
BILLING_PREFIX	billing/	Папка внутри бакета.
SA_BUCKET_NAME	finops-bucket-admin	Имя SA, который читает/пишет бакет.
SA_API_NAME	finops-api-viewer	Имя SA для API-доступа (мониторинг + billing).

Cloud ID, Folder ID и Billing Account ID не задаются вручную — берутся из активного профиля yc и из Billing API.

Запуск в dry-run-режиме

Если хотите посмотреть, что произойдёт, без отправки callback — запустите без TOKEN:

# для Казахстана замените yandex-ru- на yandex-kz-
curl -sSL https://files.opsman.ai/yandex-ru-cloud-install.sh | bash

Скрипт выполнит все шаги в Yandex Cloud, сохранит credentials в finops-radar-credentials.txt, но не отправит их в OpsMan AI. Вы сможете потом ввести их вручную в UI.

Что делает по шагам

0. Preflight: проверка прав

CURRENT_USER_ID=$(yc iam whoami --format json | tr -d '"')
billing_api GET "/billingAccounts/${BILLING_ACCOUNT_ID}:listAccessBindings"

Скрипт сразу определяет, есть ли у текущего пользователя роль billing.accounts.admin. Если нет — печатает предупреждение и продолжает (Шаг 8 выдаст warning).

Выводится таблица:

┌──────────────────────────────────────────────┬────────────┐
│ Область                                       │   Доступ   │
├──────────────────────────────────────────────┼────────────┤
│ Биллинг (billing.accounts.admin)              │   ✓ есть   │
└──────────────────────────────────────────────┴────────────┘

1. Создание бакета

yc storage bucket create \
    --name "$BUCKET_NAME" \
    --folder-id "$FOLDER_ID" \
    --default-storage-class STANDARD \
    --max-size 107374182400  # 100 GB

Создаётся бакет с лимитом 100 GB. Если бакет с таким именем уже существует в каталоге — шаг пропускается (yc storage bucket get).

Внутри бакета создаётся placeholder-объект billing/.keep — папка-маркер для биллинг-экспорта.

2. Настройка экспорта биллинга — ручной шаг

log_warn "Регулярный экспорт биллинга не может быть настроен автоматически."
log_warn "Публичный API для этой операции отсутствует (только UI)."
open "https://center.yandex.cloud/billing/accounts/${BILLING_ACCOUNT_ID}/exports"

У Yandex Cloud Billing нет публичного API (ни REST, ни gRPC) для управления экспортом — это подтверждено protobuf-схемами cloudapi. Поэтому скрипт открывает страницу в браузере и подсказывает, какие поля заполнить:

• Бакет: ${BUCKET_NAME}
• Папка: ${BILLING_PREFIX}
• Тип: Поресурсная
• Язык: English

Это единственный ручной шаг во всём процессе.

3. SA для бакета: finops-bucket-admin

SA_BUCKET_ID=$(yc iam service-account create \
    --name "$SA_BUCKET_NAME" \
    --description "OpsMan FinOps: full access to billing export bucket" \
    --folder-id "$FOLDER_ID" \
    --format json | jq -r '.id')

Идемпотентно: если SA с таким именем существует — берётся его ID и шаг пропускается.

4. Роль storage.editor на каталог

yc resource-manager folder add-access-binding \
    --id "$FOLDER_ID" \
    --role "storage.editor" \
    --subject "serviceAccount:$SA_BUCKET_ID"

Почему storage.editor на каталог, а не ACL на бакет

Документация Yandex Cloud прямо требует: «Не настраивайте политику доступа для бакета» биллинг-экспорта. Если поставить ACL на бакет, внутренний билинг-робот теряет доступ → ошибка bucket_permission_denied и экспорт перестаёт работать.

Поэтому права выдаются через IAM на каталог — этого достаточно, чтобы SA читал и писал именно этот бакет.

5. Статический S3-ключ для finops-bucket-admin

yc iam access-key create \
    --service-account-id "$SA_BUCKET_ID" \
    --description "OpsMan FinOps: S3 static key" \
    --format json

Возвращает пару access_key_id + secret. Эти credentials платформа будет использовать для скачивания биллинг-файлов из бакета по протоколу S3.

6. SA для API: finops-api-viewer

Аналогично шагу 3 — отдельный SA только с read-доступом для inventory ресурсов и billing-метрик.

7. Роль viewer на облако

yc resource-manager cloud add-access-binding \
    --id "$CLOUD_ID" \
    --role "viewer" \
    --subject "serviceAccount:$SA_API_ID"

Read-доступ ко всем ресурсам всех каталогов в облаке. Не даёт права на изменение или удаление.

8. Роль billing.accounts.viewer на платёжный аккаунт

billing_api POST "/billingAccounts/${BILLING_ACCOUNT_ID}:updateAccessBindings" "$payload"

Через Billing REST API (в yc CLI этой команды нет). Нужна для чтения метаданных платёжного аккаунта и проверки активности экспорта.

Если на этом шаге PermissionDenied — скрипт продолжит работу, но эту роль придётся выдать вручную: Yandex Cloud Console → Billing → ваш аккаунт → Доступ → Назначить роль → billing.accounts.viewer → SA finops-api-viewer.

9. Авторизованный JSON-ключ для finops-api-viewer

yc iam key create \
    --service-account-id "$SA_API_ID" \
    --description "OpsMan FinOps: authorized key" \
    --output finops-api-key.json

JSON с приватным RSA-ключом. Платформа использует его для генерации IAM-токенов и обращения к Compute / Monitoring / Billing API от имени SA.

10. Сводка credentials локально

В текущей директории создаётся finops-radar-credentials.txt:

[Общие параметры]
Cloud ID:               b1g...
Folder ID:              b1g...
Billing Account ID:     dn2...

[Бакет для биллинга]
Bucket Name:            finops-billing-export
Bucket Prefix:          billing/

[Сервисный аккаунт: доступ к бакету]
SA Name:                finops-bucket-admin
SA ID:                  ...
Static Access Key ID:   ...
Static Secret Key:      ...

[Сервисный аккаунт: API]
SA Name:                finops-api-viewer
SA ID:                  ...
Authorized Key File:    /path/to/finops-api-key.json

[Авторизованный ключ (JSON)]
{ ... приватный ключ ... }

Этот файл содержит приватный ключ

finops-radar-credentials.txt и finops-api-key.json — секретные. Храните их в защищённом месте (vault, encrypted backup) или удалите после успешного callback’а — у платформы они уже будут.

11. Callback в OpsMan AI

curl -X POST "https://api.opsman.ai/api/v2/cloud/helm/callback" \
    -H "Content-Type: application/json" \
    -d '{
        "bucket_name":          "...",
        "bucket_prefix":        "...",
        "cluster":              "<CLUSTER>",
        "region":               "ru",
        "key_id":               "...",
        "private_key":          "...",
        "public_key":           "...",
        "sa_id":                "...",
        "sa_name":              "...",
        "static_access_key_id": "...",
        "static_secret_key":    "...",
        "status":               "ok",
        "token":                "<TOKEN>"
    }'

Один POST-запрос на endpoint OpsMan AI. Передаются:

• идентификаторы бакета и папки;
• cluster (из переменной CLUSTER) — чтобы платформа поняла, какой именно подключаемый кластер вы оформляете;
• region — ru или kz. В ru-варианте скрипта шлётся "ru", в kz-варианте — "kz". Бэкенд сохраняет его в clouds.region и на его основе определяет валюту (RUB / KZT) и endpoints (storage.yandexcloud.net / .kz, IAM и т.д.);
• два набора ключей: статический S3 (для скачивания биллинг-файлов) и авторизованный JSON (для API-вызовов);
• token — одноразовый токен из UI, доказывающий, что callback легитимный.

Без TOKEN callback пропускается с warning’ом.

Что отправляется наружу

Только один HTTP-запрос наружу — на api.opsman.ai (TLS). В нём:

• credentials созданных вами SA;
• идентификаторы вашего облака, каталога и бакета;
• одноразовый token для проверки.

НЕ отправляется: содержимое ваших ресурсов, IP-адреса, имена пользователей, метрики, биллинг-данные. Платформа получит к ним доступ позже сама — через выданные API-ключи.

Что скрипт не делает

• Не запускает sudo, не модифицирует /etc, /usr, /var.
• Не запускает фоновых демонов, cron-задач, services.
• Не выдаёт editor или admin ни одному сервисному аккаунту.
• Не удаляет существующие ресурсы.
• Не модифицирует существующие SA, бакеты, ACL.
• Не отправляет телеметрию третьим сторонам — только один callback на api.opsman.ai.
• Не сохраняет ничего в $HOME помимо файлов finops-radar-credentials.txt и finops-api-key.json в текущей директории запуска.

Что получаете в итоге

В Yandex Cloud:

Folder (ваш существующий)
├── Bucket: finops-billing-export
│   └── billing/.keep              # placeholder для биллинг-экспорта
├── SA: finops-bucket-admin        # storage.editor на каталог
│   └── Static access key (S3)
├── SA: finops-api-viewer          # viewer на облако + billing.accounts.viewer
│   └── Authorized key (JSON)
└── (включённый вами вручную) Billing Export → bucket

Локально в директории запуска:

finops-radar-credentials.txt       # сводка всех параметров
finops-api-key.json                # JSON-ключ SA (приватный)

В OpsMan AI: подключенный кластер со статусом active через 5 минут после callback’а.

Откат / удаление

Полная очистка всех созданных скриптом ресурсов:

# 1. Удалить SA (вместе с ними удаляются все их ключи)
yc iam service-account delete --name finops-bucket-admin
yc iam service-account delete --name finops-api-viewer

# 2. Удалить бакет (предварительно очистить от объектов)
yc storage bucket delete --name finops-billing-export

# 3. Отключить биллинг-экспорт в UI Yandex Cloud Console
#    Billing → Экспорт → удалить созданный экспорт

# 4. Удалить локальные credentials
rm -f finops-radar-credentials.txt finops-api-key.json

Роли удалятся автоматически вместе с SA (привязки умирают вместе с subject’ом).

Troubleshooting

PermissionDenied на Шаге 8

Текущий пользователь не имеет billing.accounts.admin. Скрипт продолжит работу — выдайте billing.accounts.viewer сервисному аккаунту finops-api-viewer вручную через Yandex Cloud Console → Billing → Доступ.

«cloud-id не задан в профиле yc»

yc config set cloud-id <ваш-cloud-id>
yc config set folder-id <ваш-folder-id>

Скрипт упал в середине — что делать?

Запустите ещё раз. Все шаги идемпотентны: уже созданные SA и бакет будут переиспользованы, скрипт продолжит с того места, где остановился. Единственное исключение — статический S3-ключ всегда создаётся новый; старый можно удалить через yc iam access-key delete.

Хочу запустить без отправки credentials в OpsMan AI

Запустите без переменной TOKEN. Скрипт выполнит все шаги в Yandex Cloud, сохранит credentials в finops-radar-credentials.txt, и пропустит callback. Дальше можно ввести параметры вручную в UI OpsMan AI (Подключение в консоли).

Бакет создаётся, а биллинг-файлы не появляются

Проверьте, что Шаг 2 (включение экспорта биллинга в UI) выполнен. Это единственный шаг, который скрипт не может сделать сам — у Yandex Cloud Billing нет публичного API для управления экспортом. Первый файл появится в бакете в течение 24 часов после включения экспорта.