Docs / Trust & compliance

Security & hardening

In design for the host baseline. Exploring for compliance evidence.

TractorStack runs on hardware you own, inside your network. That gives you control, and it also means nobody else is patching or watching it for you. The design builds security into the same Git repository as everything else, so it is reviewed, repeated on every host, and checked for drift.

Operating system baseline

Ansible roles are planned to apply a CIS-style baseline to every host: unused services removed, a host firewall that allows only what each role needs, time sync, central logging, automatic security updates on a schedule you control, and file permissions tightened. Runs use --check --diff first, so you see what will change before it changes.

SSH and admin access

• Key-based SSH only; password and direct root login disabled.
• Named accounts for each administrator, with sudo logged. No shared logins.
• Admin access from the management network or a jump host, not from user networks.
• Removing a person means removing their key in Git and running Ansible, which is quick and leaves a record.

Network segmentation

At the network layer the design separates a management network (hypervisor consoles, iDRAC or iLO, SSH, monitoring) from the networks that carry application and user traffic. No admin interface is exposed to the internet. Remote support, where agreed, goes through a VPN into the management network.

Secrets

Secrets are never stored in Git in plain text. Two options are planned, chosen per customer:

• SOPS with age: secrets live encrypted in the repository and are decrypted only on the machine running Ansible. Simple, with no extra server.
• OpenBao or HashiCorp Vault: a central secrets service with access policies and audit logs. More to run, better for larger teams.

OpenTofu state can hold secrets too. It is stored in PostgreSQL on-site, and OpenTofu supports client-side state encryption.

TLS with an internal certificate authority

Services talk over TLS, including inside the network. An internal CA issues the certificates, so you don’t depend on public certificates for internal names. Routine checks are planned to warn well before any certificate expires. In stage 3, cert-manager can issue from the same CA.

Container images

Images come from your own registry, pinned to a version or digest, never :latest. They are scanned for known vulnerabilities, for example with an open-source scanner such as Trivy, before they are promoted for use. See Kubernetes-ready rules.

Audit trail

Every change to infrastructure is a Git commit: who changed what, when, and why, with review before merge. Each OpenTofu and Ansible run is planned to save its log, so you can match a change on a server to the commit that made it.

Compliance evidence

Exploring

We are exploring tagging Ansible roles with the controls they address, such as CMMC and NIST SP 800-171 requirements, and saving the output of each run as evidence in a RustFS bucket with object lock, indexed in PostgreSQL. The aim is that, when an assessor asks how a control is met, you can show the code and the dated proof it ran.

For restricted sites, see offline and air-gapped networks.

Last updated 25 October 2026 · Questions or corrections: sales@infratractor.com