docs(access): wire ADR-021 into CLAUDE.md, STATUS, TODO
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
This commit is contained in:
parent
649925b303
commit
13f0d482bd
3 changed files with 15 additions and 2 deletions
|
|
@ -87,6 +87,8 @@ Full design rationale: `docs/decisions/`
|
|||
- Every role must have `meta/main.yml` filled in
|
||||
- Every **service** role must have a populated `SECURITY.md` (ADR-002/004) — copy `docs/security/service-security-template.md`
|
||||
- Every **service** role must have a populated `VERIFY.md` (ADR-008/017) — copy `docs/testing/service-verify-template.md`
|
||||
- Every **service** role must have a populated `ACCESS.md` (ADR-021) — copy
|
||||
`docs/access/service-access-template.md`; rendered from the role's `access__*` data
|
||||
- One service = one self-contained role; no shared multi-service roles (ADR-004)
|
||||
- Role names: `snake_case`, descriptive nouns (`base`, `docker_host`, `reverse_proxy`)
|
||||
- Use `make new-role NAME=<name>` to scaffold — never create role structure by hand
|
||||
|
|
@ -224,6 +226,7 @@ Single-contributor, trunk-based (no merge requests / approval gates):
|
|||
| Logging & log integrity | `docs/decisions/018-logging.md` |
|
||||
| Tagging & run-targeting | `docs/decisions/019-tagging.md` |
|
||||
| Firewall strategy | `docs/decisions/020-firewall.md` |
|
||||
| Operational access | `docs/decisions/021-operational-access.md` |
|
||||
| Adding a new role | `docs/runbooks/new-role.md` |
|
||||
| Adding a new host | `docs/runbooks/new-host.md` |
|
||||
| Rotating vault secrets | `docs/runbooks/rotate-secrets.md` |
|
||||
|
|
|
|||
|
|
@ -59,6 +59,10 @@ So `make deploy PLAYBOOK=site` is still incomplete — `base` is only partially
|
|||
| Service-UI verification (Level 4) | ADR-017 / ADR-008 | **Design RESOLVED** (ADR-017 + spec + plan); resolves ADR-015 deferred #2. `/verify-service` skill + `VERIFY.md` template + standards are authorable and present. **Build pending:** running needs ubongo + `playwright` plugin + Authentik + a staging deploy. |
|
||||
| Logging pipeline (Loki + Alloy + off-site subset) | ADR-018 | **Design RESOLVED** (ADR-018 + spec). All logs → on-cluster Loki; security subset write-only off-site to askari. **Build pending:** Alloy in `base`, `loki`/`grafana` service roles, OPNsense syslog — none built. |
|
||||
| Security alerting (AIDE/auditd/fail2ban/Suricata + log-silence) | ADR-002 / ADR-018 | Wired into Grafana on the Loki stack. Designed; depends on the logging pipeline + metrics stack (TODO 3.6). |
|
||||
| Operational-access doctrine (ADR-021) | ADR-021 | **Design RESOLVED** (ADR-021 + spec + plan). Two-layer doctrine, three-tier access ladder, `access__*` model, `ACCESS.md` record, `/check-access`. Reconciles ADR-016/020 SSH. |
|
||||
| `ssh-from-control` firewall source | ADR-021 / ADR-020 | **Built (dormant).** `base__firewall_control_addr` knob + nftables rule + Molecule assertion landed; empty default = no rule until `ubongo`'s LAN address is set in `group_vars`. |
|
||||
| `/check-access` verifier | ADR-021 | **Design RESOLVED** (`.claude/commands/check-access.md` authored). **Build pending:** running needs `ubongo` + live/staging hosts + vault. Access analogue of `/verify-service` (ADR-017). |
|
||||
| Per-service `ACCESS.md` records | ADR-021 | Template + governance present; per-service files render when each service role is built. |
|
||||
|
||||
## Keeping this honest
|
||||
|
||||
|
|
|
|||
10
docs/TODO.md
10
docs/TODO.md
|
|
@ -18,7 +18,10 @@
|
|||
1. ~~Decide how to manage logs.~~ DECIDED (ADR-018): all logs → on-cluster Loki via
|
||||
Grafana Alloy (in `base`); a security subset also ships write-only off-site to
|
||||
`askari` (append-only); Grafana queries both. WORM skipped (accepted-risk R4).
|
||||
2. Decide how to manage APIs / API access.
|
||||
2. ~~Decide how to manage APIs / API access.~~ DECIDED (ADR-021): per-service `access__*`
|
||||
data declares the admin API (endpoint + `firewall_ref` to the catalog + vault token
|
||||
ref + health path); rendered into `ACCESS.md` and probed by `/check-access`. Part of
|
||||
the two-layer operational-access doctrine.
|
||||
3. ~~Decide how to import or integrate from baobabAnsibleV4.~~ DECIDED (ADR-013):
|
||||
translate-don't-transplant — V4 is a source only of gotchas + working config
|
||||
snippets, re-derived on boma's terms; never structure/requirements/values.
|
||||
|
|
@ -53,7 +56,10 @@
|
|||
|
||||
7. **Shell setup**
|
||||
1. Decide what shell setup matters for the AI's work on the control node.
|
||||
2. Decide what to set up on the hosts, given that direct access will be rare.
|
||||
2. ~~Decide what to set up on the hosts, given that direct access will be rare.~~
|
||||
DECIDED (ADR-021): the host-layer access baseline — SSH on `wt0` + from `ubongo`,
|
||||
Docker/Compose tooling, Alloy log shipping, and a recorded break-glass console per
|
||||
host class.
|
||||
|
||||
8. **Scheduled work**
|
||||
1. Run `/review-repo` as `claude -p` via cron every two weeks?
|
||||
|
|
|
|||
Loading…
Add table
Reference in a new issue