Security

Agent-to-centre transport

Every agent connects to the centre over mutual TLS: the centre acts as its own certificate authority and issues each agent its own client certificate. If an agent's certificate or CA material is missing or unreadable, it refuses to start rather than falling back to an unencrypted connection, a broken -tls-dir is loud, not a silent downgrade.

Certificate lifecycle

• Issuance: a client certificate is issued to each agent automatically when it onboards, signed by the centre's own root.
• Validity: the root is valid for 10 years; each agent's client certificate for 2 years by default.
• Renewal is manual, not automatic. From Settings → Certificates, an operator sees every agent's certificate status and a per-host Renew action, which re-issues the certificate and pushes it to the host over WinRM, the agent restarts and reconnects under its new identity. The console surfaces the deadline before it becomes an outage: a certificate within 30 days of expiry shows its remaining days directly against the host, and an expired one is called out as a failure rather than folded into a generic "unhealthy" state.
• Revocation is not implemented. Removing a host from management stops the centre issuing it further work; it does not invalidate a certificate that host already holds. There is no CRL or OCSP responder. A decommissioned host's certificate remains cryptographically valid until it expires, if a host's key material is known to be compromised, the CA root itself would need to be rotated to cut it off, which invalidates every other agent's certificate too and requires re-onboarding the fleet. Treat host decommissioning as inventory hygiene, not as a security boundary, until revocation exists.

Operator sign-in

The console and REST API are guarded separately from the agents. Operator authentication never touches the agent channel, so a host keeps enforcing its last-honoured state whoever is, or is not, signed in, and whether or not a domain controller is reachable.

• Local accounts. Passwords are stored as bcrypt hashes. A new account needs at least 8 characters.
• Sessions. A session token is 256 random bits, held only in the operator's browser. The centre stores just a SHA-256 hash of it, so a leaked database cannot be replayed as a live sign-in. A session lasts 12 hours and slides forward while it is in use. Sessions survive a centre restart.
• Roles. Administrator, Operator and Read-only, enforced by the centre on every request. Read-only cannot open an interactive console, because a console types into a machine. Anything the centre does not recognise is treated as Read-only.
• Active Directory. Included in every tier. The bind account's password is sealed in the credential vault, the operator's own password is used once to prove who they are and is never stored, and plain LDAP is refused. A local account is always tried first and is the break-glass login, so losing a domain controller never locks operators out. See Active Directory sign-in.

What is not there: Ballast has no multi-factor sign-in of its own and does not throttle repeated wrong passwords. With directory sign-in, each attempt is a real sign-in against Active Directory, so your domain's lockout policy applies.

Least-privilege agent account

The documented default is that the agent's Windows service account is a Domain Admin. That is more than the agent actually needs, and the narrower set below is confirmed working on real AD, not just designed. The script that creates such an account is under Settings, Agents (the Agent service account panel) and is linked from the New host dialog:

• Kerberos constrained delegation for live migration, the account needs write access to msDS-AllowedToDelegateTo on computer objects in its OU. An object-level ACL grant is sufficient on its own; the account does not need the SeEnableDelegationPrivilege user right some documentation suggests is also required. Confirmed with a real live migration between two lab hosts.
• Cluster Name Object (CNO) creation for cluster formation, the account needs create/delete rights over computer objects, scoped to its OU and to the computer object class only (not Full Control of the OU, and not a single prestaged, named object). Confirmed by forming, destroying, and re-forming a failover cluster under more than one cluster name with no per-name setup step.
• The account needs no domain-join rights at all, domain join uses a separate, per-operation credential supplied by the centre, never the service account's own identity.

Not confirmed yet: a broader manual pass across the rest of the reconcile surface (switch/vNIC, disk resize, general VM operations) under this account, beyond cluster formation and migration specifically.

Verifying the agent binary

Every release on the Downloads page publishes a SHA256SUMS file alongside the binaries, compare a downloaded file's hash against its line there before installing it (the Downloads page shows the exact commands). There is no code-signing yet, so a checksum match confirms the file wasn't corrupted or swapped in transit; it doesn't independently prove who built it. Treat the checksum plus the source (this site, or the public GitHub repository the agent builds from) as the current guarantee, not a cryptographic signature.

This covers binaries fetched from the Downloads page or a GitHub release. The centre's own Update all outdated action, which pushes its embedded agent binary to stale hosts over WinRM, does not check it against SHA256SUMS, that push is trusted by virtue of coming from a centre the operator already runs and trusts, not by an independent verification step.

This website and analytics

This documentation site (ballast.halvantic.com) can use Google Analytics to count visits and see which pages are useful. It is off until you accept it in the banner: nothing is requested from Google before that, and declining sends nothing. If you accept, Google sets cookies and receives usage data (pages viewed, approximate location, browser and device details), with IP addresses anonymised. You can change or withdraw the choice at any time from Analytics settings in the footer; withdrawing takes effect on the next page load.

This applies to the website only. The Ballast agent, centre and Manager do not send usage data to Halvantic or to any analytics service, and licence keys are verified offline against an embedded public key, so an air-gapped deployment behaves the same as a connected one.