Appliance Hardening Statement

What the Athena virtual appliance (the OVA / VHDX image on Downloads) does to reduce its attack surface, and, just as plainly, what it does not do. Use this page for a security review or a risk assessment before you put the appliance into production.

Base operating system#

The appliance runs on Flatcar Container Linux, Stable channel: a minimal, container-only Linux distribution. Each Athena release is built on the newest Flatcar Stable release available at build time, and the Flatcar image, its SBOM and its package list are checked against Flatcar's OpenPGP image-signing key before they are used; a bad signature stops the build. Release 0.9.4 ships Flatcar 4757.2.3 (kernel 6.12.114). The exact OS version of every release is in its release notes.

The Athena server runs as the same container image that every other Athena delivery format uses, on the Docker engine that ships with Flatcar.

Summary#

Operating system#

• Read-only, verified OS. The operating system partition is mounted read-only and verified by dm-verity, so it cannot be changed at runtime. The build refuses an image where it is not read-only.
• A/B OS partitions. The OS lives in two partitions. An update writes the inactive one and leaves the running one untouched (see Updates).
• Flatcar's own updater and reboot manager are masked, not just disabled, and its update server is set to disabled. The appliance never contacts an update server.
• Kernel and network settings follow the CIS Level 1 subset that applies: no IP forwarding, no ICMP redirects, no source routing, reverse-path filtering, martian-packet logging, SYN cookies, full ASLR, kernel pointers and dmesg hidden from unprivileged users, no setuid core dumps, protected hard links and symlinks.
• Forwarding stays off at runtime, for IPv4 and IPv6, even after Docker and the network service start. The build checks it.
• Unused filesystems and USB storage are blocked (cramfs, udf, usb-storage). Core dumps are off for logins, services and containers.
• Data volume is mounted nodev,nosuid.
• No autologin on any console. Flatcar's VMware image normally gives the extra virtual consoles and the serial console a passwordless login; the appliance replaces that with a normal login prompt (with locked accounts) and turns the serial login off. SSH over the hypervisor's VM socket is off as well.

SELinux and kernel lockdown#

• SELinux is enforcing from the first boot, with Flatcar's own policy. That policy confines the containers: the Athena server and the optional local PostgreSQL run confined, and their data is labelled for container use. Host services (systemd, auditd, Docker, the console) run unconfined, so on the host SELinux adds little beyond file labels. All Athena containers share one SELinux level, so SELinux does not separate the server from its PostgreSQL; the container-versus-host boundary stays.
• An update that cannot run enforcing is rolled back: the health check after an update runs under enforcing.
• Kernel lockdown in integrity mode blocks writes to kernel memory, unsigned kexec, and module parameters that set hardware addresses. The build refuses an image where it is not active. An appliance that gets lockdown through an update reboots once more after the update commits, to switch it on.
• Honest limit: without Secure Boot, lockdown is not tamper-proof. Root on the appliance, or someone with access to the VM's disk on the hypervisor, can remove it and reboot. Drift detection watches the boot configuration, so a removed setting shows as drift, and the VM console status shows the live lockdown mode.

Network exposure#

The inbound firewall drops everything by default. It accepts loopback, replies to connections the appliance opened, basic rate-limited ICMP / ICMPv6 (including IPv6 neighbour discovery), DHCP replies, and new connections to these ports:

• Optional ports. Open or close the remote-control group and the metrics port on the VM console (2) Network → 3) Firewall / optional ports) or in the web console under Settings → Appliance → Firewall. The change is live without a restart and is audited. 8443 and 8444 cannot be closed from either place.
• Endpoints need only 8444. Since release 0.9.4, agent installs, downloads and the install one-liner use the agent port, which answers nothing but agent traffic. You can therefore restrict 8443 on your network to your administrators. See Network Ports & Firewall.
• No container-runtime API on the network. Docker listens only on its local socket; the build refuses any network listener for it.
• No routing. Docker's own NAT and bridge networking are off and nothing is forwarded. The server container uses the host network, so the firewall above is the only gate.
• The optional local PostgreSQL has no network endpoint at all; the server reaches it over a local socket.

Administrative access#

• SSH is off. The SSH service is masked, and the temporary access and host keys used while building the image are removed before it is sealed.
• Support SSH is time-limited and console-only. It can be switched on only from the VM console menu, for 1 to 480 minutes; the automatic switch-off is armed first. Each window uses one method: a one-time password for the core account, or one public key you paste (ed25519, ECDSA, or RSA of 3072 bits or more; the console shows its fingerprint). root cannot log in. A pasted key is kept in memory only, so it never survives a reboot. Switching off (by the timer, the menu or a reboot) always removes the key, locks the account again, ends its sessions and closes port 22.
• The VM console is a menu, not a shell. Ctrl+C, Ctrl+Z and Ctrl+\ are ignored. Every setting goes through one validating back end and is logged. Day-2 tasks (network, host name, NTP, proxy, database, support bundle, updates, factory reset) need no shell.
• The web console's appliance actions are a fixed list. Settings → Appliance can ask the host only for status, verifying and applying a signed update bundle, time zone and NTP, the optional firewall ports, a support bundle, the journal, restarting Athena, reboot and shutdown. Every argument is re-validated on the host. This is designed on the assumption that the server container could be compromised: even then, it can request only those actions. Network settings, support SSH and factory reset are not reachable from the web console. The actions need the Admin-only appliance.manage / appliance.power.manage permissions and are audited.
• Optional NTP authentication. An NTP symmetric key set on the console switches time sync to authenticated NTP. The key is stored readable by root only, is never shown or logged, and is removed from support bundles.
• Support bundles have secrets removed, and a bundle is refused if a secret would survive.

No default passwords, per-install secrets#

• The OS accounts root and core have no usable password in a shipped image.
• The Athena admin password is generated per install at first boot (20 random characters) and shown only on the VM console until you change it in the web console.
• The optional local PostgreSQL password is generated per install (40 characters).
• Nothing secret is baked into the image. The machine ID and SSH host keys are cleared before the image is sealed. The Athena certificate authority, the agent-port server certificate, the install ID, the package-token secret, the settings-sync instance ID and the sign-in token signing key are all created on the appliance's first start. Two VMs cloned from one image get different values for all of them, and a sign-in token from one is refused by the other.
• The trial licence is installed only when no licence exists, so a purchased licence is never replaced.

The Athena server container#

• Runs as the image's non-root user; the image contains no shell.
• All Linux capabilities dropped and no privilege escalation.
• Read-only root filesystem; every writable path is an explicit mount on the data volume.
• Confined by SELinux (see above); logs go to the system journal.
• The build starts the image with the same restrictions and fails if it does not serve its sign-in page.
• User namespaces are not used: Docker does not allow them with host networking, and host networking is what keeps the firewall the single gate.

Updates#

• Signed offline bundles. An update is one file whose manifest lists every member with its SHA-256 hash and size, signed with a dedicated offline ECDSA P-384 key (separate from the licensing CA and from Athena's own PKI). The appliance holds only the public key. The signature is checked before anything in the bundle is trusted, then the member list (no links, no duplicates, nothing unlisted) and every hash. A refused bundle changes nothing.
• No downgrades, and the same version is never applied twice.
• Mandatory database backup before anything changes.
• A/B with automatic rollback. The OS part is Flatcar's own signed update, written to the inactive partition. After the reboot the new version is kept only if Athena passes its health check and stays healthy for a settling window (three checks over 120 seconds). Otherwise the previous files, image and database are restored and the previous OS partition is booted.
• An update may only change appliance configuration; a bundle that tries to write to the operating system partition is refused before anything changes.

See Downloads → Updates for how to apply a bundle.

Logging, audit and drift detection#

• auditd is on, with rules for identity files, sudo configuration, the SSH configuration, the firewall, Athena's configuration, Docker, logins, host-name changes, kernel modules and sudo / su.
• The system journal is persistent (capped at 1 GB).
• Every support-SSH unlock is recorded in the journal and in a permanent "OS accessed" record, with the mode and key fingerprint (never a password). The record shows on the console status and in every support bundle, and a factory reset keeps it.
• Every update step is logged and kept as history you can read over the REST API.
• Drift detection. The appliance records a SHA-256 baseline of every file it manages when the image is sealed and after every update. A check runs 3 minutes after boot and then hourly, and reports changed, missing and unexpected files. Drift shows in the VM console header and Status screen, in every support bundle, and as a one-line summary on Settings → Appliance → Overview. Changes you make through the console are not drift. Nothing is fixed automatically, and drift raises no alert.

Supply chain, SBOM and CVE reports#

• Pinned inputs. The Flatcar images and update payloads, the PostgreSQL image and the build tools are pinned by hash or digest.
• SBOMs (SPDX 2.3 JSON) for the Athena server image, the PostgreSQL image, the agents, the appliance's own files, and Flatcar's published SBOM for the exact OS release.
• A CVE report (JSON and Markdown) per release. A release is blocked if Athena's own components have a Critical finding with a fix available. Findings in upstream components that do not apply to the appliance are triaged in OpenVEX documents, each with a concrete reason (for example, the vulnerable code is not in the binary, or the binary never runs on the appliance); the report shows both the raw and the after-triage counts. Anything without a concrete reason stays open.
• The SBOMs and CVE report are inside every signed update bundle and are published with each release; the release notes carry a CVE summary.
• CIS-style compliance report. There is no CIS benchmark for Flatcar, so the appliance is self-assessed against CIS Distribution Independent Linux v2.0.0 Level 1, with Docker Bench for Security and Lynis, on a running appliance. Each control states the appliance setting or why it does not apply. Known deviations include: no noexec on /tmp and /dev/shm (Flatcar defaults), no file-integrity tool beyond dm-verity and drift detection, no GRUB password, IPv6 router advertisements accepted, and no memory / CPU limits on the server container. It is a self-assessment, not a certified scan.

What the appliance does not do#

Platform notes: Hyper-V is a community-supported Flatcar platform. Questions about this statement: support@sealgrid.ai.

Related#

• Downloads → Security and hardening: the short version, next to the images.
• Network Ports & Firewall: every port Athena uses.
• Appliance Settings: firewall switches, drift summary, support bundles and power.
• Appliance Web Certificate: use your own CA's certificate on 8443.
• Appliance Backup & Restore: encrypted full backups.
• Air-Gapped Operation: running with no internet access.