Sign-in & SSO

Planned design. TractorStack is in development. This page describes how it is designed to work; nothing here is available to install yet. See the roadmap for the status of each part.

Exploring An idea we are working through, not a committed design.

Identity and single sign-on for platform services matter as soon as a stack has more than a couple of web interfaces. A typical TractorStack site may end up with a self-hosted GitLab, dashboards from monitoring, a RustFS console, a container registry and, later, Argo CD. Without single sign-on, each one has its own users and passwords, and removing a person who leaves means remembering every one of them.

Single sign-on: what it would cover

The services we are thinking about are the ones people log into through a browser or a CLI:

GitLab, where merge requests for change requests are reviewed and approved;
dashboards and log search;
the object storage console, for administrators only;
the container registry;
the Kubernetes API and Argo CD from stage 3.

Applications you run on the platform can use the same identity service if you want, but that is your choice, not a requirement.

Two directions we are looking at

	Use your existing directory	Run an identity service on site
Example	Active Directory, FreeIPA or an existing LDAP or OIDC provider	Keycloak, connected to your directory or with its own users
Who manages users	Whoever already does	Your directory, or the platform team
Extra to run	Nothing, if services can speak to it directly	One more service, with its own backups and database
Good fit	Organizations with a directory that already works	Sites without one, or where several services need OIDC that the directory cannot provide

In both cases the idea is that group membership in the directory decides access, and the mapping from groups to roles in each service lives in the repository. In GitLab, directory groups map to GitLab groups and projects, which also decide who may approve merge requests. Granting someone production access becomes a reviewed change, and the audit trail shows who approved it.

MFA for admins

Multi-factor authentication for anyone with admin rights is one thing we expect to treat as required rather than optional. That covers platform admins, people who can approve production changes, and anyone with access to secrets. Hardware keys or authenticator apps are both reasonable; SMS codes are a weaker last resort.

SSH access to hosts is a separate path. As described in Security & hardening, it stays key-based, with keys managed in Git. Tying SSH certificates to the identity service is something we may look at later.

When the identity service is down

If everyone signs in through one service, that service failing locks everyone out, including the people who would fix it. The design we are exploring keeps:

a local admin account on each critical service, with credentials held under the break-glass process in Secrets & credentials;
the identity service itself backed up and restore-tested like any other PostgreSQL database;
a runbook for signing in without it.

Teams and tenants

For MSPs, one identity service across customers is convenient and risky in equal measure. We lean towards a separate realm or provider per customer, mapped to that customer’s own GitLab group, in line with Teams & tenants, but this is still open.

Nothing here is built yet. If you already have a directory, tell us what it is during a pilot; fitting into what you have is usually better than adding something new.

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