diff --git a/docs/ecosystem.md b/docs/ecosystem.md index 79795a0..be55c24 100644 --- a/docs/ecosystem.md +++ b/docs/ecosystem.md @@ -6,7 +6,7 @@ production admission or owner assent. | Concern | Existing owner / intended interaction | | --- | --- | | Railiance repository/runtime architecture | railiance-master; confirm source ownership and future rapp/reef packaging | -| Initial authority host | railiance-infra S1 (resolve inherited railiance-hosts source) / platform / reef-railiance; see infrastructure.md | +| Initial authority host | railiance-infra S1 (confirmed by ADR-0004) / platform / reef-railiance; see infrastructure.md | | Source/history | Coulomb organization on Forgejo, operated through railiance-forge; retain policy/source/evidence without assigning clock truth to Git dates | | Shared discovery/work records | Repo Manager + primary Statehub; derive exact pushed source and stable identifiers | | Security architecture | net-kingdom / gate-house; review layer role and trust/validity semantics | diff --git a/docs/identity-and-utc-review.md b/docs/identity-and-utc-review.md new file mode 100644 index 0000000..fe165e4 --- /dev/null +++ b/docs/identity-and-utc-review.md @@ -0,0 +1,113 @@ +# Identity and host UTC contract review + +Status: review proposal, 2026-09-14. RCLK-WP-0002-T01/T02/T03 remain open. +This review authorizes no principal provisioning, policy grant or production use. + +## Source baseline + +Reviewed NetKingdom commit `8dc5050aa380f1864d8ffbf80bd07c131f7df895`: + +- `canon/standards/iam-profile_v0.3.md`: accepted; principal types human, + service and agent, issuer-scoped subjects and delegated actor attribution. +- `canon/standards/security-layer-model_v0.7.md`: accepted baseline. +- `canon/standards/security-layer-model_v0.8.md`: proposed successor, not + automatically adopted by this review. +- `canon/standards/tenancy-posture_v0.1.md`: proposed; useful explicit workload + identity/binding model, with adoption status to be confirmed by its owner. + +S1 ownership is established by railiance-master ADR-0004 and railiance-infra's +reef source map. The live host receipt is +`evidence/2026-09-14-railiance01-clock-inventory.json`. + +## Identity vocabulary and proposed execution attribution + +The user's human/agentic/functional distinction should build on existing principal +types. Do not add a fourth `functional` token principal type merely to represent +an operational responsibility. The following concepts need separate references: + +| Concept | Clock deployment example | Meaning | +| --- | --- | --- | +| Human principal | Operator requesting or approving a deployment | Accountable actor, issuer plus subject | +| Agent principal | Agent preparing or initiating the change | Own identity plus delegation when applicable | +| Service principal | Runner or authority service runtime credential | Machine identity scoped to environment/audience | +| Workload identity | Independently governed deployment runner or clock service | Stable execution unit bound to runtime principals | +| Functional responsibility | Host time operator, clock sample provider | Responsibility/capability; does not itself grant access | +| Authorization role | Reviewed permission to converge host time configuration | Policy assignment with scope and lifecycle | +| Ansible role | Versioned host time role in railiance-infra | Reusable code artifact; not a credential or principal | +| Execution | One invocation against a reviewed inventory | Run ID linking actor, executor, artifact and result | + +Proposed audit chain: initiating actor → delegated agent (when present) → +executing workload/runtime principal → action and target → exact source and +Ansible role artifact → native decision/approval references → result receipt. +An agent can itself be an executing workload when authoritatively declared; do +not invent a service hop for every execution. Neither a role filename nor a +repository name establishes the authenticated executor or its permissions. + +A run receipt should reference issuer/subject, tenant, environment, delegation +reference, workload binding, run ID, source commit/artifact digest, target inventory +reference, action, applicable decision/approval IDs and attributed time interval. +Use existing owner schemas and custody rules; never embed bearer credentials. +A signing key ID identifies a trust key, not the complete service identity. Bind it +to the intended authority and environment through the reviewed trust lifecycle. + +Review negatives: role name mistaken for permission; agent using human subject; +missing delegation; cross-tenant or environment credential reuse; runtime principal +without matching workload binding; valid time sample mistaken for authorization. +Reject ambiguous identity at the relevant enforcement owner; retain unknown +attribution explicitly in diagnostic evidence. + +## Host UTC findings and proposed policy gates + +The live host reports timesyncd enabled, UTC and synchronized, with distro fallback +`ntp.ubuntu.com`. This is sufficient inventory evidence, not a reviewed UTC bound. + +Systemd v255 documentation says timesyncd implements SNTP and can step large +clock offsets. It describes boot initialization separately from synchronization; +`time-set.target` alone does not wait for reference synchronization. The application +also needs continuing quality checks after any startup synchronization gate. +[Source](https://raw.githubusercontent.com/systemd/systemd/v255/man/systemd-timesyncd.service.xml). + +Configured NTP servers are tried in turn. Per-link sources also participate, and +fallback servers apply only when other source information is absent. Consequently, +a longer configured server list does not provide simultaneous independent-source +agreement. RootDistanceMaxSec is a source-selection threshold, not an independently +established bound on this application's UTC estimate. +[Source](https://raw.githubusercontent.com/systemd/systemd/v255/man/timesyncd.conf.xml). +These versioned upstream documents guide review; the installed package/version and +vendor changes still need recording before the role is implemented. + +Proposed policy requirements for the owner review: + +1. Retain the existing daemon during inventory. Before calling it an adequate + authority baseline, decide how the health adapter establishes a conservative + error bound under stated upstream, network and host trust assumptions. If it + cannot, expose diagnostic health only and return unusable authority time. + Evaluate a reviewed daemon replacement if necessary; never run two disciplines. +2. Record approved source operators, endpoints, leap convention, source-selection + behavior and treatment of DHCP/per-link/runtime overrides. Endpoint count is + not evidence of operator or reference independence. No new endpoints are selected + by this review. +3. Propose unsmeared UTC as the starting convention, subject to infrastructure and + consumer assent. Define wire behavior through a leap explicitly: until that + behavior is reviewed and tested, protected use is unavailable across an announced + or detected leap/continuity ambiguity. Do not guess a safe exclusion duration. +4. Require a versioned error model, maximum observation age and tested host drift + assumptions. Missing measurements or stale health produce unusable state. + A signed quality flag, stratum, last offset or sample dispersion alone cannot + stand in for that model. Disable protected offline holdover initially. +5. Source loss, reboot, step and unexpected source/leap change invalidate authority + continuity as specified. Bootstrap verifies reference synchronization and the + application quality gate; ongoing monitoring detects later degradation. + +## Owner review requests and acceptance + +| Owner | Concrete review requested | Completion evidence | +| --- | --- | --- | +| NetKingdom / gate-house | Confirm identity vocabulary, binding/delegation model, and clock Tooling versus Engine/PIP boundary | Versioned ruling; no speculative layer declaration | +| railiance-infra | Confirm effective source/version inventory and propose daemon/health model against these gates | Source policy and measurement plan in RAIL-HO-WP-0013 | +| railiance-bootstrap | Confirm time initialization versus usable-reference ordering and handoff | Owner automation references and failed-quality startup test | +| Clock/security consumers | Review leap handling, unknown bounds and identity/time separation | Accepted contract references and C05/C09/C14/C16 negatives | + +Track identity review in RCLK-WP-0002-T01, trust/leap review in T02, and the measured +error model in T03. Broader IAM schema changes belong to NetKingdom's owner work +records; this document proposes a cross-owner review, not a parallel IAM system. diff --git a/docs/infrastructure.md b/docs/infrastructure.md index 1ffff72..05467b7 100644 --- a/docs/infrastructure.md +++ b/docs/infrastructure.md @@ -7,7 +7,7 @@ implementation are tracked in RCLK-WP-0005. No infrastructure is deployed by see | Concern | Source/operation owner | Bootstrap responsibility | | --- | --- | --- | -| Host UTC daemon, upstreams, OS baseline, health adapter | railiance-infra S1; resolve inherited railiance-hosts source before editing | Invoke owner convergence before time-sensitive higher layers | +| Host UTC daemon, upstreams, OS baseline, health adapter | railiance-infra S1 (confirmed by ADR-0004 and RCLK-WP-0005-T01) | Invoke owner convergence before time-sensitive higher layers | | Cluster/network substrate | railiance-cluster and reef-railiance | Sequence their existing prerequisite gates | | Application-clock source and contract | railiance-clock | Consume a published version; do not embed a second implementation | | Workload packaging and placement | Reviewed rapp package / rail-kubernetes / reef-railiance | Invoke admitted deployment after prerequisites | @@ -16,9 +16,9 @@ implementation are tracked in RCLK-WP-0005. No infrastructure is deployed by see The current railiance-bootstrap INTENT says it sequences a new estate and hands off, and explicitly excludes ongoing operations and S1 OS baseline ownership. -railiance-infra owns the declarative substrate. railiance-hosts still contains -historical S1 content; T01 must settle the actual canonical source rather than -copy it. railiance-master owns that boundary decision. +railiance-infra owns the declarative substrate. railiance-hosts contains historical S1 content and is superseded. T01 confirmed +railiance-infra as canonical against railiance-master ADR-0004; RAIL-HO-WP-0013 +owns the host time implementation. ## Practical deployment choice diff --git a/workplans/RCLK-WP-0002-contract-review.md b/workplans/RCLK-WP-0002-contract-review.md index 2e23484..01c0423 100644 --- a/workplans/RCLK-WP-0002-contract-review.md +++ b/workplans/RCLK-WP-0002-contract-review.md @@ -4,7 +4,7 @@ type: workplan title: "Review time authority, trust and consumer contracts" domain: infotech repo: railiance-clock -status: ready +status: active owner: codex topic_slug: custodian created: "2026-09-14" @@ -20,7 +20,7 @@ Ready to perform review of the completed draft, not ready for production securit ```task id: RCLK-WP-0002-T01 -status: todo +status: progress priority: high state_hub_task_id: "437734bd-8930-56d5-9eb3-2835cb19db8b" ``` @@ -31,7 +31,7 @@ Obtain Railiance architecture and NetKingdom/gate-house review. Resolve authorit ```task id: RCLK-WP-0002-T02 -status: todo +status: progress priority: high state_hub_task_id: "5f7dd460-06d7-59ef-9d37-102ca9a22f6c" ``` @@ -42,7 +42,7 @@ Choose established signing profile, canonical encoding and wire schema; trust bo ```task id: RCLK-WP-0002-T03 -status: todo +status: progress priority: high state_hub_task_id: "8038f9ee-8585-57e3-a769-701e16ff7e8b" ``` @@ -59,3 +59,8 @@ state_hub_task_id: "53d248c0-b73d-5ee7-a3a8-360bd1b1042d" ``` Agree with flex-auth, approval-engine, secrets-engine and audit-core on clock injection/server-side execution, validity boundaries, CAS/check-to-use semantics and event attribution. Preserve current refusal until reviewed replacement. Pin accepted contract versions and update acceptance matrix C07/C10–C12/C16. Record disagreements as decisions/live work. + +Review started 2026-09-14: `docs/identity-and-utc-review.md` pins the IAM/layer +source baseline, separates actors/workloads/permissions/Ansible artifacts, and +identifies source-selection, leap and error-bound gates. Owner assent and measured +policy remain pending; no review task is complete from the proposal alone.