How is sluis designed?¶
One issuer that every cluster, cloud account, CD system and console trusts, fed by the corporate directories the company already runs. It answers two questions about a person, whether the account is live and who is in a group. It turns the answer into a token under a policy that is a file in git. It authenticates nobody but the recovery account and a conformance test account. Passwords, MFA and device policy stay with the corporate directory.
One binary per module¶
The issuer, the signer and the console are one process, sluis-issuer. The GitHub, Slack, Google, Cloudflare and backup modules are processes of their own, one binary each, that the issuer calls (ADR 0071). A module whose remote is unset in the issuer's document runs inside the issuer instead and shares its health probes. A login's only network call is to the Google module, which reaches the directory.
The directory's own endpoint is not served. The controllers read the console's API with their own identity, with the policy digest on every answer.
That leaves one chart, one policy file, and per process one service document and one health endpoint. The assembly is internal/rosterapp: wiring only, and the halves keep their own packages and tests.
A module alone holds its credentials: a GitHub App key is in the GitHub module's namespace and nowhere else. The boundary sits in IAM per role, in validated configuration and in the release signature.
Where each part is explained¶
| Part | Page |
|---|---|
| Every container and how they connect | Architecture |
| Two trust anchors and one vocabulary | Trust |
| Workspaces, domains and what authoritative means | Directory model |
| Snapshots, leases and shared state | Freshness |
| The policy, what is verified, three grants and three endpoints | Verify and issue |
| Sessions, limits and sign-out | Sessions, back-channel logout |
| The web UI | Console |
| Joiners, movers and leavers on GitHub | GitHub controller |
| Channel membership on Slack | Slack reconciler |
| The audit trail | Audit, audit actions |
| State, secrets and blobs | Store, ports |
| The way in when no directory can vouch | Recovery |
| Functions, roles and signing keys on AWS | Lambda, signing on AWS |
| What happens when something fails | Failure semantics |
| What was removed | Not served |
Consoles without OpenID¶
A console with no OpenID flow of its own uses gateway-native OIDC on Envoy Gateway, or upstream oauth2-proxy on other gateways (ADR 0003). See oauth2-proxy.