Поделитесь org-credential

Менеджер сохраняет один ключ на всю организацию; обычному участнику отказано, но статус он всё же видит.

Один вендорский ключ на всю команду: сохранён один раз менеджером организации, отдаётся resolve каждому участнику, как запись невидим для не-менеджеров.

Цель

Как менеджер организации, сохранить её default-credential; как обычный участник, получить 403 на инвентаре, но правдивый credential-status.

Действующие лица

Оба токена должны нести один и тот же org_id (User Plane Tokens).

Шаги

1. Ольга сохраняет общий ключ

Вызовите POST /v1/org-credentials — та же форма тела, что у личного создания; владелец берётся из org_id токена:

curl -s -X POST "$CREDS_BASE/v1/org-credentials" \
  -H "Authorization: Bearer $OLHA_TOKEN" -H "Content-Type: application/json" \
  -d '{
    "provider_code": "'$CODE'",
    "name": "Team key",
    "credentials": {"api_key": "sk-org-0123456789abcdef"},
    "make_default": true
  }'

Ожидаемый 201: owner_type: "organization", owner_id = UUID организации, is_default: true, маска вместо секрета.

2. Ольга видит его в инвентаре организации

GET /v1/org-credentials → ожидаемый 200 с записью. Менеджер другой организации увидел бы пустой список — изоляция идёт по owner_id.

3. Марку отказано в инвентаре

Тот же списочный вызов с токеном Марка:

curl -s "$CREDS_BASE/v1/org-credentials" -H "Authorization: Bearer $MARKO_TOKEN"

Ожидаемый 403 FORBIDDEN — member не входит в список менеджеров (JWT_ORG_MANAGER_ROLES). Чтения гейтятся ровно так же, как записи: секретный инвентарь организации — дело менеджеров.

4. Марко всё же узнаёт то, что ему нужно

Марко вызывает credential-status для провайдера. Ожидаемый 200 с "organization_credentials_configured": true и — при условии, что у Марка нет личного ключа — "effective_credential_source": "organization": его переводы будут работать на командном ключе, который он не может инспектировать.

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