tegwick
7e86430913
Finding from the inbound-library lane (ILIB-WP-0003): the build grant can write a policy, bind it to an AppRole and mint a secret-id, yielding a token outside its own denies. Options recorded for founder decision; the policy is unchanged. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Assistant: claude-code Assistant-Model: opus Assistant-Process: 1170398@bnt-lap001 Assistant-Session: 622cd705-cb31-4322-ba08-dd42e44fa583
130 lines
6.8 KiB
Markdown
130 lines
6.8 KiB
Markdown
# Intake records
|
|
|
|
## MASON-IN-0001 — Grandfather the legacy MASON-0001 identifier scheme
|
|
|
|
```yaml
|
|
id: MASON-IN-0001
|
|
kind: intake
|
|
title: Grandfather the legacy MASON-0001 identifier scheme
|
|
lane: green
|
|
status: closed
|
|
outcome: absorbed
|
|
origin: residual
|
|
origin_ref: MASON-WP-0002
|
|
priority: low
|
|
owner: ops-mason
|
|
description: The finished bootstrap workplan uses legacy MASON-0001 and noncanonical
|
|
MASON-0001-Txx identifiers, including a duplicate T01. Fleet canon says existing
|
|
identifiers are never renamed and legacy schemes must be grandfathered. Coordinate
|
|
with the Custodian canon steward and Repo Manager to add the exact legacy scheme
|
|
mapping, then verify statehub consistency without rewriting registered UUIDs or
|
|
historical source identity.
|
|
notes: Custodian decision 3c487545-ee40-4049-89fa-34b41747a7eb grandfathered
|
|
the exact MASON-0001 workplan and MASON-0001-TNN task schemes. Registered UUIDs
|
|
remain unchanged, and the duplicate MASON-0001-T01 source blocks are indexed as
|
|
one logical task while retaining both source locations as diagnostic provenance.
|
|
Absorbed by that decision and the CUST-WP-0063 canon/validator update.
|
|
created: '2026-08-22T09:33:08.629717Z'
|
|
updated: '2026-08-22T21:19:02Z'
|
|
state_hub_intake_id: "01a028d1-c4af-7a06-adb5-c90399721872"
|
|
```
|
|
|
|
## MASON-IN-0002 — Declaration requested: state this repository's layer in INTENT.md (security layer model §11)
|
|
|
|
```yaml
|
|
id: MASON-IN-0002
|
|
kind: intake
|
|
title: 'Declaration requested: state this repository''s layer in INTENT.md (security
|
|
layer model §11)'
|
|
status: closed
|
|
outcome: absorbed
|
|
origin: cross-repo
|
|
origin_ref: net-kingdom security-layer-model_v0.4 §11
|
|
priority: low
|
|
owner: ops-mason
|
|
requested_by: gate-house
|
|
proposed_layer: Staff
|
|
description: 'A conformance sweep on 2026-08-28 found this repository has no layer
|
|
declaration of its own. It carries a layering review note gate-house wrote into
|
|
the top of its INTENT.md on 2026-08-24, and that note names a layer — but the words
|
|
are gate-house''s, sitting above a line admitting the body is unadapted. Section
|
|
11 has since been amended to say so explicitly: a layer stated about a repository
|
|
by another repository is not a declaration; only the repository''s own file, in
|
|
its own voice, conforms. Seven of fifteen estate-authored repositories have declared;
|
|
this is one of the eight that have not. REQUESTED: state the layer in INTENT.md
|
|
in your own voice, or contest it. PROPOSED LAYER: Staff. Builds and tears down access
|
|
routes, credentials, and perimeters. Two things to state in your words: the Staff
|
|
binding rule (you act through Engine APIs, never directly against Tooling — a grep
|
|
of your own source is the check, as ops-warden did and found one), and the demarcation
|
|
you are half of: ops-mason and ops-warden own access lanes, access-engine owns access
|
|
rules. Contesting is a real option and costs nothing — the three repositories that
|
|
reviewed this model each returned a correction, two of which changed the standard.
|
|
If the proposed layer is wrong for what this repository actually does, that is more
|
|
useful to us than a label added to close a checkbox. Standard: net-kingdom/canon/standards/security-layer-model_v0.4.md.'
|
|
created: '2026-08-28T21:03:29.920563Z'
|
|
updated: '2026-09-28T09:54:34.065401Z'
|
|
notes: >-
|
|
Closed against the repository-authored Staff / pep-shaped declaration in
|
|
INTENT.md, dated 2026-09-21. That declaration names access-engine as the
|
|
authorization decision point and explicitly records direct Tooling contacts
|
|
and the founder-accepted plan-approval exception. The declaration request is
|
|
fulfilled; the accepted conformance gaps and their 2026-12-21 review remain
|
|
declared and are not marked conformant by this intake closure.
|
|
```
|
|
|
|
## MASON-IN-0004 — Close the policy-plus-AppRole escalation path in ops-mason-build
|
|
|
|
```yaml
|
|
id: MASON-IN-0004
|
|
kind: intake
|
|
title: Close the policy-plus-AppRole escalation path in ops-mason-build
|
|
status: open
|
|
origin: review
|
|
origin_ref: inbound-library ILIB-WP-0003 (finding raised 2026-10-05 while preparing the first grant)
|
|
priority: high
|
|
owner: ops-mason
|
|
requested_by: founder
|
|
description: >-
|
|
policies/ops-mason-build.hcl says OpenBao, not convention, enforces "ops-mason
|
|
never reads a secret value". The explicit denies on platform/, operators/ and
|
|
secret/ data hold only for tokens that carry ops-mason-build. The same grant can
|
|
also do the following:
|
|
(1) create or update any ACL policy except its own (sys/policies/acl/*);
|
|
(2) create or update any AppRole role and read or write anything beneath it
|
|
(auth/approle/role/*), which includes reading role-id and minting secret-id;
|
|
(3) do the same for Kubernetes auth roles.
|
|
A grant holder could therefore write a policy granting read on platform/data/*,
|
|
bind it to a new AppRole, read that role's role-id, mint a secret-id and log in.
|
|
The resulting token does not carry ops-mason-build, so none of its denies
|
|
apply. Kubernetes roles allow the same path for anyone holding a
|
|
service-account JWT. This was confirmed by reading the policy text. It was
|
|
not exercised.
|
|
The builder legitimately needs to write policies and mint secret-ids to deliver
|
|
AppRole lanes, as it did for inbound-library-imap-approle on 2026-10-05. A
|
|
path-level deny on secret-id would therefore break every build. Parameter
|
|
constraints such as allowed_parameters with token_policies=workload-kv-read-*
|
|
narrow the role binding but not policy content, because a policy with a
|
|
conforming name can still grant platform/data/*.
|
|
options: >-
|
|
(a) Separation of duties: ops-mason drafts policy HCL in the plan, and the
|
|
founder applies the policy write in an attended operator session. The grant
|
|
loses sys/policies/acl/* create/update and keeps role binding and delivery,
|
|
restricted by allowed_parameters to the policy names the plan approved.
|
|
(b) Detective control: after every build, re-read the written policy and role
|
|
and compare them to the approved build_spec (policy text derived from kv_path
|
|
and capabilities). Alert from the OpenBao audit log on any sys/policies/acl
|
|
write or role secret-id mint by a claude-* display_name that has no matching
|
|
build-log record.
|
|
(c) Two grants: a read-only survey grant (survey, metadata, capabilities), and
|
|
a build grant minted only after plan approval and scoped by allowed_parameters
|
|
to that plan's exact policy and role names. Bao policies cannot template on
|
|
plan content, so this means minting a per-plan policy at grant time, itself an
|
|
operator act.
|
|
These can be combined, for example (b) now and (a) or (c) as the structural fix.
|
|
This is a decision for the founder. Do not widen or loosen ops-mason-build
|
|
while it is open.
|
|
notes: >-
|
|
A survey needs only (c)'s read-only grant. Today MASON-WP-0008 plan-survey runs
|
|
under the full build grant, so separating them also reduces what a survey
|
|
session can do.
|
|
```
|