Files
proxmox/docs/04-configuration/PHOENIX_SITE24X7_API_KEYS.md
defiQUG c05aa50e27
Some checks failed
Deploy to Phoenix / deploy (push) Has been cancelled
Phoenix Deploy API: alert webhook, .env.example, Site24x7 and E2E docs
- PHOENIX_ALERT_WEBHOOK_URL: POST on alerts when firing
- .env.example: PROXMOX_*, PROMETHEUS_*, webhooks, partner keys
- PHOENIX_SITE24X7_API_KEYS.md: how to issue API keys for Site24x7
- PHOENIX_E2E_PORTAL_API_RAILING.md: E2E test steps and references

Made-with: Cursor
2026-03-11 13:00:53 -07:00

2.0 KiB
Raw Blame History

Site24x7 API Keys for Phoenix API

Purpose: Issue Phoenix API keys for Site24x7 (and similar) users so they can call /api/v1/* (Infra, VE, Health) with X-API-Key or Authorization: Bearer <key>.

Prerequisites

  • API key store is in place (Sankofa API: api_keys table + migration 026).
  • Users or service accounts exist in Gitea (e.g. Site24x7 team in Sankofa_Phoenix org).

Steps

  1. Create API key in Sankofa API

    • Use GraphQL mutation createApiKey (or future admin REST endpoint) with:
      • name: e.g. Site24x7-monitor
      • permissions: ["read"] for read-only (Infra, VE, Health); ["read","write"] if VM lifecycle is allowed.
    • Or insert into api_keys (key_hash = SHA256 of the secret key, key_prefix = first 12 chars).
    • Return the plain key once to the operator; store only the hash.
  2. Assign tenant (optional)

    • If the key should be tenant-scoped, set tenant_id on the api_keys row so /api/v1/tenants/me/* returns that tenants data.
  3. Configure Site24x7

    • In Site24x7 monitor config, set:
      • URL: https://api.sankofa.nexus/api/v1/health/summary (or your Phoenix API base).
      • Header: X-API-Key: <key> or Authorization: Bearer <key>.
  4. Phoenix Deploy API (direct)
    If Site24x7 hits phoenix-deploy-api directly (not via Sankofa API), add the same key to PHOENIX_PARTNER_KEYS in phoenix-deploy-api .env.

Gitea team → API keys

For each Gitea user in the Site24x7 team who needs API access:

  • Ensure the user exists in Sankofa (Keycloak/users table) if using JWT; or create an API key bound to a service user and share the key securely.
  • Prefer one key per service (e.g. one key for Site24x7) rather than per user, unless each user has a distinct integration.

References