wiki: update Security
chaib
parent
c3bb332447
commit
57b25acecd
1 changed files with 33 additions and 122 deletions
155
Security.md
155
Security.md
|
|
@ -1,135 +1,46 @@
|
||||||
# Security
|
# Security model
|
||||||
|
|
||||||
Atlas OS is built so that a single operator can run ~24 public services from one VPS without exposing any of them to the open internet unguarded. Security is layered: every request passes an identity gate before it reaches an app, the hosting is EU-sovereign by design, secrets never touch git, and any action with real-world consequences (money, external communications, self-modification) requires a human to approve it.
|
## Perimeter
|
||||||
|
|
||||||
> See also: [[Architecture]] · [[Atlas-OS]] · [[Fleet-and-Mesh]] · [[AI-Stack]] · [[Identity]]
|
All HTTP traffic enters through **Caddy** which:
|
||||||
|
- Terminates TLS (Let's Encrypt, auto-renew)
|
||||||
|
- Applies rate limiting
|
||||||
|
- Logs all requests
|
||||||
|
|
||||||
---
|
## Authentication
|
||||||
|
|
||||||
## At a glance
|
**Authentik** (self-hosted) provides SSO via `forward_auth`:
|
||||||
|
- Every service route checks with Authentik before proxying
|
||||||
|
- Unauthenticated requests get a 302 to the login page — never a data response
|
||||||
|
- Sessions are JWT-based with configurable expiry
|
||||||
|
- MFA supported (TOTP, WebAuthn)
|
||||||
|
|
||||||
| Layer | Control | What it protects |
|
## Network isolation
|
||||||
|---|---|---|
|
|
||||||
| Edge | Caddy (automatic TLS) | All inbound traffic is HTTPS |
|
|
||||||
| Identity | Authentik `forward_auth` on the embedded outpost | Single sign-on gate in front of apps |
|
|
||||||
| Auth strength | MFA | Account takeover |
|
|
||||||
| Sovereignty | Single Hetzner VPS in NL/DE (EU) | Jurisdiction / data residency |
|
|
||||||
| Private spine | Tailscale (`tailscale serve`) | Internal-only services, never public |
|
|
||||||
| Secrets | Vaultwarden + `/opt/atlas/secrets` (chmod 600) | Credential exposure |
|
|
||||||
| Source control | `.gitignore` enforced | Secrets leaking into git history |
|
|
||||||
| Recovery | Nightly backups | Data loss |
|
|
||||||
| Autonomy | AI policy gate (human approval) | Unauthorized money / comms / self-modify |
|
|
||||||
|
|
||||||
---
|
- Internal services (cockpit, LLM router, DBs) bind to `127.0.0.1` only
|
||||||
|
- Admin APIs bind to the Tailscale interface (`100.x.x.x`) only
|
||||||
|
- Public internet never reaches internal ports directly
|
||||||
|
|
||||||
## The SSO gate (Authentik `forward_auth`)
|
## AI agent gates
|
||||||
|
|
||||||
Every public hostname is fronted by **Caddy**, which terminates TLS and then asks **Authentik** whether the request is allowed before the upstream app ever sees it. This is done with Authentik's `forward_auth` integration running on its **embedded outpost** — Caddy makes a sub-request to the outpost for each incoming request, and only forwards the request to the app if the outpost returns an authenticated session.
|
The Atlas Brain respects a policy file that hard-blocks autonomous action for:
|
||||||
|
- Any financial transaction
|
||||||
|
- Any external communication (email, WhatsApp send)
|
||||||
|
- Any self-modification (config changes, code deploy)
|
||||||
|
|
||||||
```mermaid
|
These always require human approval in the Control screen.
|
||||||
%%{init:{'theme':'base','themeVariables':{'primaryColor':'#0c1428','primaryTextColor':'#cfe2ff','primaryBorderColor':'#1F6FE0','lineColor':'#4EA0FF'}}}%%
|
|
||||||
flowchart LR
|
|
||||||
U[Browser] -->|HTTPS| C[Caddy TLS edge]
|
|
||||||
C -->|forward_auth sub-request| O[Authentik embedded outpost]
|
|
||||||
O -->|authenticated?| C
|
|
||||||
C -->|allowed| A[App: Odoo / Open WebUI / Nextcloud / ...]
|
|
||||||
C -->|denied -> login| L[Authentik login + MFA]
|
|
||||||
L --> O
|
|
||||||
```
|
|
||||||
|
|
||||||
Practical consequences of this model:
|
## Secrets management
|
||||||
|
|
||||||
- **One front door.** A user signs in once at Authentik and gains access to the apps their identity is permitted to use, rather than logging into each service separately.
|
- No secrets in git (`.gitignore` enforced)
|
||||||
- **Apps are not directly reachable.** Because the gate sits at the edge, an unauthenticated request to a protected app is bounced to the Authentik login flow.
|
- Vaultwarden (self-hosted) for human-facing passwords
|
||||||
- **Admin identity:** `atlasshb` is the administrative identity for the platform.
|
- Env files on the VPS in `/opt/atlas/secrets/` (not world-readable)
|
||||||
|
- Rotation: manual — planned for automated rotation via Vault/n8n
|
||||||
|
|
||||||
Identity tooling itself — **Authentik** (the identity provider) and **Vaultwarden** (the password/secret vault) — lives in the **Identity** category of [[Atlas-OS]].
|
## What to audit after forking
|
||||||
|
|
||||||
---
|
1. Change all default passwords (Authentik akadmin, Forgejo, etc.)
|
||||||
|
2. Rotate the Evolution API key
|
||||||
## Multi-factor authentication (MFA)
|
3. Disable Authentik user registration if not needed
|
||||||
|
4. Review Caddy rate-limit thresholds for your traffic
|
||||||
Authentication is protected with **MFA**, so a leaked or guessed password alone is not sufficient to reach the platform. Because authentication is centralized at the Authentik gate, MFA is enforced at the single choke point rather than re-implemented per app.
|
5. Set up Uptime Kuma alerts for all services
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## EU sovereignty (no US Cloud Act)
|
|
||||||
|
|
||||||
Atlas OS runs on a **single Hetzner VPS hosted in the EU (NL/DE)**. This is a deliberate jurisdictional choice:
|
|
||||||
|
|
||||||
- **EU-sovereign hosting.** Data resides in the European Union under EU jurisdiction.
|
|
||||||
- **No US Cloud Act exposure.** The platform does not depend on US-headquartered cloud providers, so it is not subject to the US Cloud Act's reach over data held by such providers.
|
|
||||||
|
|
||||||
This sovereignty posture covers the whole stack — the ~55 Docker containers and ~24 public services described in [[Architecture]] all run on that one EU box.
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## Network model — public vs. private
|
|
||||||
|
|
||||||
Not everything that runs on the VPS is meant to be public. Atlas OS separates the two cleanly:
|
|
||||||
|
|
||||||
| Exposure | Mechanism | Examples |
|
|
||||||
|---|---|---|
|
|
||||||
| **Public** | Caddy + Authentik `forward_auth` | The ~24 public services |
|
|
||||||
| **Private** | Tailscale (`tailscale serve`) | Internal-only services, **never public** |
|
|
||||||
|
|
||||||
- **Tailscale** provides a private spine. Internal services are published over the tailnet with `tailscale serve` and are **never exposed publicly**.
|
|
||||||
- **NATS mesh** carries node-to-node messaging across the fleet (round-trip proven). See [[Fleet-and-Mesh]].
|
|
||||||
- **MeshCentral** is used to remote-manage client POS devices and other endpoints — also covered in [[Fleet-and-Mesh]].
|
|
||||||
|
|
||||||
This split means that even if an attacker probes the public surface, the internal control-plane services are simply not addressable from the internet.
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## Secrets model
|
|
||||||
|
|
||||||
Secrets are kept out of the application code and out of version control. There are two complementary stores:
|
|
||||||
|
|
||||||
| Store | Purpose | Protection |
|
|
||||||
|---|---|---|
|
|
||||||
| **Vaultwarden** | Interactive / shared credential vault | Behind the SSO gate + MFA |
|
|
||||||
| **`/opt/atlas/secrets`** | On-host secrets for services and scripts | Filesystem perms `chmod 600` (owner-only read/write) |
|
|
||||||
|
|
||||||
Rules that hold across the platform:
|
|
||||||
|
|
||||||
- **No secrets in git.** A `.gitignore` is enforced so credentials and secret files are never committed to the **Forgejo** repositories (see Ops in [[Atlas-OS]]).
|
|
||||||
- **Least-privilege filesystem access.** On-host secrets in `/opt/atlas/secrets` are mode `600`, readable only by their owner.
|
|
||||||
- **Vaultwarden as the system of record** for interactive credentials, itself gated by Authentik + MFA like every other app.
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## The AI human-approval gate
|
|
||||||
|
|
||||||
Atlas runs an autonomous core (**Atlas Brain**, a reviewed-execution model) backed by the `kernel.sqlite` spine and an LLM router. Autonomy is deliberately bounded by a **policy gate** that **always requires human approval** for the highest-risk action classes:
|
|
||||||
|
|
||||||
| Action class | Requires human approval? |
|
|
||||||
|---|---|
|
|
||||||
| Spending / moving **money** | Yes — always |
|
|
||||||
| **External communications** (anything sent outside) | Yes — always |
|
|
||||||
| **Self-modification** of the system | Yes — always |
|
|
||||||
|
|
||||||
This means the AI layer can plan, draft, and execute reviewed work autonomously, but it cannot independently spend money, message the outside world, or rewrite itself — a human stays in the loop for those. The broader AI architecture (the LLM router at `localhost:8888`, local-first model selection, and the Headroom context proxy) is documented in [[AI-Stack]].
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## Backups & recovery
|
|
||||||
|
|
||||||
- **Nightly backups** are taken to protect against data loss.
|
|
||||||
|
|
||||||
Combined with EU-sovereign hosting, this keeps both the **location** and the **recoverability** of data under operator control.
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## Security principles summary
|
|
||||||
|
|
||||||
1. **Gate first.** No public app is reached without passing Authentik `forward_auth` at the Caddy edge.
|
|
||||||
2. **Strong auth.** MFA is enforced centrally.
|
|
||||||
3. **Stay sovereign.** One EU VPS (NL/DE), no US Cloud Act exposure.
|
|
||||||
4. **Keep private things private.** Internal services ride Tailscale (`tailscale serve`) and are never public.
|
|
||||||
5. **Guard secrets.** Vaultwarden + `/opt/atlas/secrets` (`600`), and `.gitignore` keeps secrets out of git.
|
|
||||||
6. **Human-in-the-loop for consequences.** Money, external comms, and self-modification always require human approval.
|
|
||||||
7. **Be able to recover.** Nightly backups.
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
_Related pages: [[Architecture]] · [[Atlas-OS]] · [[Identity]] · [[AI-Stack]] · [[Fleet-and-Mesh]]_
|
|
||||||
|
|
|
||||||
Loading…
Reference in a new issue