net-kingdom/CONFIG.md

48 lines
1.8 KiB
Markdown
Raw Normal View History

# Config Point Registry
## Philosophy
net-kingdom is opinionated: defaults, conventions, and automation are preferred at every
level. A config point in this file is a **conscious exception** — a value that cannot be
derived from the system's topology, naming conventions, component defaults, or available
automation.
**Minimizing this list is a design goal.** Before adding a config point, ask:
- Can the value be derived from a naming convention or topology fact?
- Can it be auto-generated (e.g. from the Linux user identity, like Local Identity does)?
- Is the default provided by the upstream component safe to accept?
If yes to any of the above, don't add it here.
---
## Summary
| ID | Name | Value | Location(s) |
|----|------|-------|-------------|
| CP-NK-001 | ACME contact email | `bernd.worsch+netkingdom@gmail.com` | `sso-mfa/k8s/cert-manager/issuers.yaml:38` |
---
## CP-NK-001 — ACME contact email
**Value:** `bernd.worsch+netkingdom@gmail.com`
**Set:** 2026-03-02
**Set by:** worsch
**Location(s):**
- `sso-mfa/k8s/cert-manager/issuers.yaml:38``spec.acme.email` on the
`letsencrypt-prod` ClusterIssuer
**Why non-default:** ACME (Let's Encrypt) requires a contact address for certificate
lifecycle notifications — expiry warnings, rate-limit alerts, policy announcements.
There is no system-level default that qualifies: this must be a real, monitored inbox.
**Why not automated:** The Linux user GECOS email (via Local Identity) would be a
natural source. However, that introduces a runtime dependency between cluster
provisioning and the local-identity tool. Deferred; revisit when Local Identity
gains a structured "operator contact" concept.
**Scope:** All TLS certificates issued by the `letsencrypt-prod` ClusterIssuer across
the entire cluster.