Authentication

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

JWT authentication

Human users authenticate to the API and the Admin UI with a JWT.

Token claims

{
  "sub": "[email protected]",
  "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 $INFRASAGE_URL/api/v1/anomalies \
  -H "Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..."

API key authentication

For programmatic access: ingestion agents, CI/CD, scripts. See API Keys for the full management guide.

curl -X POST $INFRASAGE_URL/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

InfraSage scopes every ClickHouse query to the authenticated tenant's tenant_id. A tenant cannot construct a query that returns another tenant's data through any API endpoint.

The application layer enforces this rather than 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
  "