Keith Smith
3b75075426
Add optional TLS certificate expiry checks for website monitors and update product, package, environment, Docker, and documentation naming.
31 lines
1.2 KiB
Markdown
31 lines
1.2 KiB
Markdown
# Security
|
|
|
|
OrbitalWard must be secure from the beginning because it will store infrastructure credentials.
|
|
|
|
## Authentication
|
|
|
|
The initial implementation supports local username/password login with hashed passwords and JWT bearer tokens. Dashboard and API access must not be available anonymously.
|
|
|
|
Initial roles:
|
|
|
|
- Viewer: can view dashboards, assets, monitors, graphs, and alerts.
|
|
- Operator: can acknowledge alerts, silence alerts, and manage incidents.
|
|
- Admin: can manage assets, monitors, credentials, notification channels, and alert rules.
|
|
- Owner: can manage users, roles, global settings, and authentication settings.
|
|
|
|
## Credential Storage
|
|
|
|
Credential records are modeled separately from monitors and assets. Secret fields must be encrypted at rest before real credential storage is enabled. Stored secret values must never be returned to the frontend after creation.
|
|
|
|
Rules:
|
|
|
|
- Use `ORBITALWARD_SECRET_KEY` from the environment.
|
|
- Never log secrets.
|
|
- Mask saved secrets in the UI.
|
|
- Audit credential create, update, and delete events.
|
|
- Prefer read-only API tokens and least-privileged credentials.
|
|
|
|
## Future Authentication
|
|
|
|
Planned future options include LDAP/Active Directory login, OIDC, SAML if needed, and API tokens.
|