From 7c3cde06b5d401608f06e375c764044b1f9ed9fa Mon Sep 17 00:00:00 2001 From: tegwick Date: Mon, 2 Mar 2026 11:47:14 +0100 Subject: [PATCH] docs: introduce CONFIG.md config point registry (CP-NK-001) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Establishes the local config point registry pattern. A config point is an explicit non-default value that cannot be derived from topology, naming convention, component defaults, or automation. Minimizing the list is a design goal — absence of an entry means "accepting the upstream default". CP-NK-001: ACME contact email (bernd.worsch+netkingdom@gmail.com) Location: sso-mfa/k8s/cert-manager/issuers.yaml:38 Why non-default: ACME requires a real monitored inbox; no system default qualifies. Automation via Local Identity GECOS email is deferred. State-hub extension point EP 8e1cda6a registered in custodian domain: "Config point registry: centralized view of explicit non-default configuration values" — proposes ConfigPoint entity type + MCP tools + cross-domain minimization metric. Co-Authored-By: Claude Sonnet 4.6 --- CONFIG.md | 47 +++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 47 insertions(+) create mode 100644 CONFIG.md diff --git a/CONFIG.md b/CONFIG.md new file mode 100644 index 0000000..d3dd531 --- /dev/null +++ b/CONFIG.md @@ -0,0 +1,47 @@ +# 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.