Прочитайте audit-стрічку

Відфільтруйте незмінний потік подій до біографії одного credential і дій одного оператора.

Усе, що робили попередні сценарії, лишило події. Цей сценарій читає їх назад так, як це робило б розслідування: за credential, за актором, за типом, за часом.

Мета

Реконструювати історію одного credential та ізолювати дії одного оператора audit-фільтрами.

Передумови

Адмінський вхід: токен provider_admin на /v1/admin/audit-events або admin-scoped сервісний токен на /internal/v1/admin/audit-events — стрічка та сама.
Активність із попередніх сценаріїв (створення, ротація, reveal).

Кроки

1. Біографія одного credential

curl -s "$CREDS_BASE/internal/v1/admin/audit-events?credential_id=$CRED_ID" \
  -H "Authorization: Bearer $ADMIN_TOKEN" -H "X-Admin-Actor: panel:olha"

Очікуване 200, найновіші перші: credential.created, далі credential.updated (метадані перелічують імена змінених полів — напр. ["credentials"] після ротації), credential.default_changed і так далі. Жодних значень секретів ніде в metadata.

2. Дії одного оператора

Відфільтруйте за атрибутованим актором:

events = httpx.get(
    f"{CREDS_BASE}/internal/v1/admin/audit-events",
    params={"actor_id": f"service:{CLIENT_ID}!panel:olha"},
    headers=admin_headers,
).json()
assert all(e["actor_id"].endswith("panel:olha") for e in events["items"])

Очікувано: рівно ті виклики, що зроблені під тією міткою X-Admin-Actor — атрибуція зі сценарію 07 окупається.

3. Історія resolve

Відфільтруйте event_type=credential.resolved (та її сестру credential.resolve_failed). Очікувано: одна подія на кожен resolve, з credential_source, target_user_id і вашим correlation_id — ниткою, що зв'язує запит runtime-а з цією стрічкою.

4. Обмежте часом

Додайте from/to (RFC 3339). Очікувано: лише події всередині вікна. Пам'ятайте про політику ретенції: стрічка тримає ~10 днів (за замовчуванням), а credential.revealed — виняток; експортуйте нижче за течією те, що мусите тримати довше.

Перевірено тестом test_s09_read_the_audit_trail.