Authentication

InfraSage uses JWT-based authentication for human users and API key authentication for service-to-service communication.

---

JWT Authentication

JWTs are used by human users accessing the API or Admin UI.

Token Claims

{
  "sub": "alice@mycompany.com",
  "tenant_id": "acme-corp",
  "role": "admin",
  "exp": 1767225600,
  "iat": 1712750400
}

Token Lifetime

Environment	Default Expiry
Development	24 hours
Production	1 hour (with refresh token)

Using a JWT

curl http://localhost:8080/api/v1/anomalies \
  -H "Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..."

---

API Key Authentication

For programmatic access (ingestion agents, CI/CD, scripts). See API Keys for full management documentation.

curl -X POST http://localhost:8080/api/v1/telemetry \
  -H "X-API-Key: isage_ab1c2d3e4f5g6h7i8j9k0l" \
  ...

---

Production Security Checklist

Secrets Management

• Do not store API keys in environment files in production
• Use AWS Secrets Manager, HashiCorp Vault, or Kubernetes Secrets
• Rotate API keys quarterly
• Never log full API key values (InfraSage only logs the prefix)

Network Security

• Enable TLS on all public-facing endpoints
• Use internal service mesh (e.g., Istio) for service-to-service communication
• Restrict ClickHouse access to the InfraSage service network only
• Configure Kubernetes NetworkPolicies to prevent lateral movement

TLS Configuration

# Enable TLS on Ingestion Gateway
GATEWAY_TLS_CERT=/etc/ssl/certs/infrasage.crt
GATEWAY_TLS_KEY=/etc/ssl/private/infrasage.key
GATEWAY_TLS_ENABLED=true

# Enable TLS for ClickHouse connections
CLICKHOUSE_TLS_ENABLED=true
CLICKHOUSE_TLS_CA_CERT=/etc/ssl/certs/clickhouse-ca.crt

ClickHouse Security

# Change default credentials immediately
CLICKHOUSE_USER=infrasage
CLICKHOUSE_PASSWORD=STRONG_RANDOM_PASSWORD_HERE

# Enable access logging in ClickHouse config
# /etc/clickhouse-server/config.xml:
# <access_log>/var/log/clickhouse-server/access.log</access_log>

Container Security

InfraSage containers run with these security defaults:

• Non-root user (uid: 10001)
• Read-only filesystem (readOnlyRootFilesystem: true)
• No privilege escalation (allowPrivilegeEscalation: false)
• No privileged mode

---

Multi-Tenant Data Isolation

All ClickHouse queries in InfraSage are automatically scoped to the authenticated tenant's tenant_id. A tenant cannot construct a query that returns another tenant's data through any API endpoint.

The isolation is enforced at the application layer (not relying on ClickHouse row-level security), and every query is audited.

---

Incident Response

If you suspect an API key is compromised:

1. Immediately revoke the key: DELETE /api/v1/apikeys/<key_id>
2. Check the audit log for suspicious activity in the last 24 hours
3. Create a new key with the same scope and update your services
4. Review what data may have been accessed or sent

# View audit log for a specific key
docker exec infrasage-clickhouse clickhouse-client \
  --user infrasage --password YOUR_PASSWORD \
  --query "
    SELECT timestamp, actor, action, resource
    FROM infrasage.infrasage_audit_log
    WHERE actor = 'isage_key_abc123'
    AND timestamp > now() - INTERVAL 24 HOUR
    ORDER BY timestamp DESC
  "