Security boundaries for a BYOS control plane
How workspace authorization, encrypted server credentials, host verification, scoped repository access, and audit events fit together.
Start with clear ownership
A BYOS control plane crosses two systems: the application that coordinates work and the Linux hosts where work runs. Security begins by stating which identity owns each side. Tnion.SH users belong to workspaces, workspace roles govern access to projects and servers, and every server and instance lookup is scoped back to that workspace.
The infrastructure provider account remains outside Tnion.SH. Keep its ownership, billing access, recovery methods, and emergency credentials in the organization’s existing security process. The control plane should not become the only place where the team can identify or recover a server.
Protect the connection path
Server passwords are encrypted at rest with AES-256-GCM using a deployment key. Each encrypted payload uses a fresh nonce, and deployed environments must supply a valid 32-byte encryption key. API responses expose connection metadata and verification state, not the stored password.
The connection test is read-only. It validates reachability and credentials, reads a constrained system summary, and returns the SSH server key fingerprint so an operator can compare it through a trusted channel. Provisioning and instance actions use a separate session that is allowed to mutate the host.
Scope every operation
Sensitive operations should resolve their target through workspace-owned records, not accept an arbitrary host or repository at the final step. Tnion.SH follows that pattern across its current control-plane paths:
- A server is loaded by both server ID and workspace ID.
- An instance belongs to a project inside the workspace.
- A Git repository is selected from the workspace’s GitHub App installation.
- A module deploy resolves the branch from the instance stage.
- A backup or restore is constrained to the target instance.
Repository tokens are also kept out of deployment output. For a Git deploy, the installation token is supplied to the remote Git process as an environment value. After checkout, the repository’s stored remote is changed back to its public URL so the credential is not left in the Git configuration.
Scope does not replace authorization review, but it limits how much untrusted input reaches the operational boundary.
Make sensitive actions reviewable
Tnion.SH writes workspace audit events for server creation and changes, credential updates, project and instance operations, backup outcomes, restore outcomes, and Git-related configuration. Events include the workspace, actor when available, resource type and identifier, timestamp, and operation-specific metadata.
Use that history as an operational record, then connect it to the rest of your process:
- Keep workspace membership current and remove access when roles change.
- Review credential updates and production actions after they occur.
- Rotate the deployment encryption key only through a planned migration process.
- Limit GitHub App repository selection to repositories the workspace actually deploys.
- Maintain off-host backups and provider-level recovery outside the control plane.
Security here is not a shield icon or a single encryption claim. It is the combination of identity scope, protected secrets, constrained inputs, visible boundaries, and reviewable actions.