Главная/Рецепты (Cookbook)/Администрируйте платформенные credentials ENУКРРУС API-справочник (ReDoc) ↗

Администрируйте платформенные credentials

Как названный оператор на сервисной плоскости, сохраните платформенный fallback и перечислите credentials по уровням.

Место оператора: Internal Admin API с admin-scoped токеном и меткой X-Admin-Actor, создающий платформенный ключ, на который проваливаются все.

Цель

Создать платформенный default-credential, атрибутированный названному оператору, затем увидеть credentials разных уровней владения в одном списке.

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

  • Сервисный токен со scope provider-credentials.admin: export ADMIN_TOKEN=... (Service Plane Tokens).

Шаги

1. Прочитайте каталог со схемами

Вызовите GET /internal/v1/admin/providers. Ожидаемый 200: каждый провайдер с credential_schema инлайн — форма создания рендерится прямо из этого (Provider Schemas).

2. Создайте платформенный credential — с явным владельцем

Вызовите POST /internal/v1/admin/credentials. Админ-плоскость называет владельца в теле; platform не принимает owner_id:

curl -s -X POST "$CREDS_BASE/internal/v1/admin/credentials" \
  -H "Authorization: Bearer $ADMIN_TOKEN" \
  -H "X-Admin-Actor: panel:olha" \
  -H "Content-Type: application/json" \
  -d '{
    "provider_code": "'$CODE'",
    "owner_type": "platform",
    "name": "Shared fallback",
    "credentials": {"api_key": "sk-platform-0123456789"},
    "make_default": true
  }'

Ожидаемый 201: owner_type: "platform", owner_id: null, is_default: true, маскированный секрет. Несогласованные координаты владельца — platform с owner_id либо user/organization без него — были бы 400.

3. Один список, каждый уровень

Вызовите GET /internal/v1/admin/credentials без фильтров, затем суженный:

all_records = httpx.get(f"{CREDS_BASE}/internal/v1/admin/credentials",
                        headers=admin_headers).json()
platform_only = httpx.get(f"{CREDS_BASE}/internal/v1/admin/credentials",
                          params={"owner_type": "platform"}, headers=admin_headers).json()

Ожидаемо: нефильтрованный список смешивает записи user, organization и platform (только маски); owner_type=platform сужает до fallback-ключей.

4. Атрибуция настоящая

Создание из шага 2 легло в audit-ленту с actor_id = "service:<client_id>!panel:olha" — отфильтруйте по нему в сценарии 09. Анонимный вызов (без X-Admin-Actor) здесь сработал бы — в отличие от reveal — но панель всегда отправляет метку: пооператорские бюджеты и читаемая лента стоят одного заголовка.

Проверено тестом test_s07_administer_platform_credentials.