How is sluis configured?¶

The keys, types and defaults are in the configuration reference and the chart values.

One file, one binary, one chart¶

sluis is one chart, charts/sluis, and one binary, with a Deployment per module. The issuer, always rendered, holds the directory reads, the policy, the OpenID provider, the login page and the console. Enable modules.github, slack, google or cloudflare for the others. In documents mode the issuer's pod runs the controllers its document names (one binary per module).

Two documents configure a process. The service document says where State lives and which keys sign. The policy says who may have what. They change for different reasons and have different owners.

Documents are immutable per instance¶

The process reads each document once, at start. A change to configuration or policy is a new set of instances, never a reload.

On Kubernetes the chart renders a checksum/* annotation per document, so a change rolls the Deployment.
On AWS Lambda a change is a new configuration layer version (AWS Lambda).
Elsewhere a change is a restart.

Credentials and State stay live. The process reads a secret when it uses it or on a short refresh, so rotating one is not a deployment.

Documents are validated before anything starts¶

A JSON Schema written by hand and embedded in the binary holds each document. An unknown key, a missing required key or a value of the wrong type refuses to start and names the path.

The chart's values.schema.json embeds the same schemas, so the same mistake fails helm install. The chart's tests hold what it renders to them. The service refuses the retired environment variables instead of ignoring them (retired variables).

A secret is named, never written¶

A document holds a secret's name, and secrets.source says how the platform delivers it: a mounted Secret, SSM or OpenBao. The document stays safe to review, render and commit. Rotating a secret needs no new document. See secrets.

What the chart does not do¶

It does not create the signing key. cert-manager issues one, or signingKey.existingSecret names one that external-secrets delivers.
It puts no authenticating proxy in front. Where a gateway forwards an identity (login.forwarded), set networkPolicy.gatewayNamespace so nothing else reaches the port.
It dictates no Secret name. Every value that consumes a Secret the chart did not create takes the Secret's name and the keys inside it. Key names are fixed only for a Secret the service writes itself.

On the deprecated legacy adapter the service reads and writes plain Kubernetes Secrets and ConfigMaps in its own namespace. To deliver a declared Secret into the namespace, see deliver a declared Secret.

Two routes¶

The console has its own HTTPRoute, separate from the issuer's. A gateway policy attaches to a route, and a policy on a shared route would also cover /token, /keys and discovery. The console's route renders whether or not anything attaches to it.

The console is a path, not a host, because discovery must sit at the root of the origin in every token's iss. The service strips the console's mount itself. A gateway that strips it too hands the console a path it never serves.

A record and its credential are two objects¶

The reasons are in the store.

Who reads the directory¶

The service has no directory API listener. The issuer reads the directory by function call.

The GitHub controller asks the console's API (Explain, ListHolders) with its own ServiceAccount token, verified against its cluster's published key set. The policy's service_account matchers put it in all:sluis:viewer.

A service that needs to know who somebody is verifies the issuer's token and reads the groups claim (service to service).