Open security core for dev sec ops on kubernetes
tegwick
c2a0f2f4e0
All checks were successful
Two live runs of BEA-2026-0002 ended setup:URLError while four read-only diagnostic pods (same image, labels, mounts and config) reached every endpoint. Likely cause: a fresh Job pod reaches OpenBao before the sso/approval-engine ingress rules admit it (NetworkPolicy is programmed per destination). Now: - build waits until OpenBao, KeyCape, approval-engine, audit-core and LLDAP all answer HTTP (one shared 30 s budget); an unreachable one is named: setup:<name> not reachable. - a preflight error is a refusal named preflight_error:<Type> (preflight has no effect). - an error in the consume read-back is outcome unknown, consume_unconfirmed:<Type>, alerted; before, any exception after setup was reported as 'refused, no effect' even after consume. - any other escaping error after setup is outcome unknown (exit 5), never 'no effect'. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Assistant: claude-code Assistant-Model: opus Assistant-Process: 523928@bnt-lap001 Assistant-Session: 6c737afb-9c14-4152-9f02-477214b9c350 |
||
|---|---|---|
| .claude | ||
| .forgejo/workflows | ||
| .githooks | ||
| .repo-manager | ||
| admissions | ||
| bounded-executor | ||
| canon | ||
| capabilities/playbooks | ||
| docs | ||
| examples | ||
| generated/coordination-frame | ||
| history | ||
| identity-provisioner | ||
| intakes | ||
| keys | ||
| local-identity | ||
| projects/nk-rehearsal | ||
| registry | ||
| runbooks | ||
| security-case-type-revisions | ||
| security-case-types | ||
| security-cases | ||
| sso-mfa | ||
| tests | ||
| tools | ||
| wiki | ||
| workplans | ||
| .generated-work-records.json | ||
| .generated-work-records.mk | ||
| .gitignore | ||
| .repo-classification.yaml | ||
| .sops.yaml | ||
| AGENTS.md | ||
| CLAUDE.md | ||
| CONFIG.md | ||
| DECISIONS.md | ||
| INTENT.md | ||
| LICENSE | ||
| Makefile | ||
| README.md | ||
| SCOPE.md | ||
| SECURITY-COMPANION.md | ||
| WORK-RECORDS.md | ||
NetKingdom
NetKingdom is the canonical security architecture, integration boundary, and bootstrap/reference implementation for NetKingdom environments. It defines identity, tenancy, credential, workload-zone, and security-composition contracts while leaving provider and Railiance execution in their owning repositories.
The dynamic, self-optimizing security platform is the long-term direction in INTENT.md, not a claim about current delivery.
Orientation
- SCOPE.md — what this repo owns, current state, and when it is relevant
- SECURITY-COMPANION.md — start here. The working form of the security layer model: what to declare, what binds you, what you may never claim about evidence, and the two things the estate cannot do yet
- Security layer model — the statute the companion serves (accepted 2026-08-29): how the security estate is layered (Taxonomy / Tooling / Engines / Staff) and what each layer may own
- Security scenario composition — deterministic, plan-only capability and trust composition
- Posture feedback — deterministic, proposal-only posture and evidence remediation findings
- Emission cadence security profile — NetKingdom obligations over the InfoTechCanon declaration contract; proposed pending owner-instance migration
Security Infrastructure Documents
- secrets-engine security infrastructure boundary defines how secrets-engine participates in the NetKingdom security infrastructure and how it interacts with OpenBao, flex-auth, user-engine, ops-warden, ops-bridge, info-tech-canon, State Hub, and agents.