Security overview
Constellation uses account sign-in for the console and scoped API keys for integrations.
| Access | Credential | Purpose |
|---|---|---|
| Console | Constellation sign-in | Account and saved work. |
| Platform data API | API key in x-api-key | Telemetry, topology, and predictions within the key's permissions. |
| Health endpoints | None | Service and subsystem health checks. |
These are separate credentials. Signing into the console does not authenticate API requests: every integration needs its own API key. See Authentication for key creation and scopes.
Data isolation
Guest, Free, and Pro use shared infrastructure and do not include tenant isolation. Enterprise provides tenant isolation with the deployment scope agreed during onboarding. See Tenant isolation.
Protect credentials
- Use HTTPS for API calls. gRPC ingest uses TLS on port 443.
- Store API keys in environment variables or a secrets manager. Keep them out of source control, logs, URLs, and browser bundles.
- Create a separate key for each integration and select only the scopes it needs.
- Revoke an exposed key in Settings → API → API tokens and replace it in the affected integration. Contact Constellation to rotate a managed Enterprise key.
The fleet agent stores its credential in /etc/constellation/agent.env with mode 0600. Applications publish through its local socket without reading the key.
Authentication failures and request limits
Stop requests when a key is rejected with 401 or lacks access with 403. For 429, distinguish an authentication lockout from a traffic limit and respect the server's retry delay. The shared policy is documented in Errors and limits.
Contact
Send security questions or reports to contact@constellation.space. Include the affected environment, time, and request or incident ID when available. Do not include credentials or sensitive telemetry.