# Terdut operator

Exposes terdut-server's configuration as Kubernetes objects, so teams can self-service it over
gitops. See [DESIGN.md](./DESIGN.md) for the design (read its revision section first: it is the
current shape of credentials and the CRD catalog), and [examples/demo](./examples/demo) for a
working install.

## CRDs

### TerdutServer
A terdut-server install: Deployment, Service, database wiring (a DSN, or a Zalando
`postgresClusterRef`), and an operator key Secret it hands to the server so the operator can
authenticate. `allowedTeams` consents to `TerdutTeam`s in other namespaces.

### TerdutTeam
One team on a server, possibly in another namespace (`serverRef`, gated by that server's
`allowedTeams`). It carries the team's whole configuration:
  - `displayName` and OIDC group bindings
  - `escalation` — the escalation ladder
  - `deadmanSwitches` — dead man's switches, by name (switches not listed are removed)

### TerdutAlertSource
An alert-ingest integration on a team (`teamRef`). The server shows the webhook key once; it is
surfaced only through a generated Secret next to the object, never set explicitly.

## Demo

[`examples/demo`](./examples/demo) wires one of each together — two teams, each with an
escalation ladder, a dead man's switch and an alert source — plus a script that fires synthetic
Alertmanager webhooks at it, so you can watch incidents open, escalate and resolve without a real
Alertmanager.