generated from coulomb/repo-seed
- ADR-0007: refine (not overturn) the orchestration boundary with the two-layer model — Railiance executes parametrized playbooks, NetKingdom does meta-orchestration (scenario->playbook selection, parametrization, responsibility map). Add the playbook/capability-contract dependency as the prerequisite, analogous to the IAM Profile. - INTENT.md: add "Why NetKingdom" (the kingdom metaphor: governed, defended, living/evolving, tended by its people); Principle 7 (Meta-Orchestration over Re-Implementation); an Operating Model section (kaizen-agent workforce for recurring duties + change/improvement); and matching Direction-of-Evolution entries. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
257 lines
8.0 KiB
Markdown
257 lines
8.0 KiB
Markdown
# INTENT
|
||
|
||
> This file captures **why this repository exists**,
|
||
> the **direction it is moving toward**, and
|
||
> the **kind of system it is meant to become**.
|
||
> It is intentionally **aspirational and stable**, not a description of current implementation.
|
||
|
||
---
|
||
|
||
## One-liner
|
||
|
||
**Open security core for DevSecOps on Kubernetes — designed to bootstrap, evolve, and continuously adapt security in an agent-driven world.**
|
||
|
||
---
|
||
|
||
## Why This Exists
|
||
|
||
Modern IT is entering a phase where **automation and agentic systems dramatically accelerate both capability and risk**.
|
||
|
||
Security is no longer a static perimeter problem — it is:
|
||
|
||
* dynamic,
|
||
* adversarial,
|
||
* continuously evolving.
|
||
|
||
The result is a **Cambrian explosion of vulnerabilities and countermeasures**, driven by:
|
||
|
||
* AI-powered development,
|
||
* autonomous agents,
|
||
* rapidly shifting infrastructure states.
|
||
|
||
Traditional security approaches fail because they are:
|
||
|
||
* too static,
|
||
* too centralized,
|
||
* too slow to adapt.
|
||
|
||
**NetKingdom exists to establish a foundational security core that is:**
|
||
|
||
* **dynamic by design**
|
||
* **bootstrappable from minimal environments**
|
||
* **grounded in open, inspectable components**
|
||
* **capable of evolving alongside the systems it protects**
|
||
|
||
---
|
||
|
||
## Why "NetKingdom"
|
||
|
||
The name is a deliberate metaphor, and a useful one: a kingdom is a
|
||
**governed, defended, living territory that grows over time and is tended
|
||
by its people**. NetKingdom is the same for an IT landscape:
|
||
|
||
* **Governed** — identity is the control plane; who may do what, under
|
||
which conditions, is the law of the land.
|
||
* **Defended** — security is the spine the whole territory is built on,
|
||
not a wall added afterward.
|
||
* **Living and evolving** — the landscapes NetKingdom stands up are not
|
||
set once and frozen. They **grow capability by capability** and adapt as
|
||
the systems and threats around them change. "NetKingdom" names this
|
||
*dynamic evolvement* of the infrastructure as much as its initial setup.
|
||
* **Tended by its people** — a kingdom that runs well is maintained
|
||
continuously. NetKingdom's "people" are **kaizen agents** (see
|
||
*Operating Model* below): hired to attend to the recurring duties that
|
||
keep the kingdom healthy and to carry out improvements and changes.
|
||
|
||
---
|
||
|
||
## The Mission
|
||
|
||
> *Where we are going.*
|
||
|
||
NetKingdom aims to become a:
|
||
|
||
**Dynamic, self-optimizing, full-circle security platform for Kubernetes-based infrastructure**
|
||
|
||
This means:
|
||
|
||
* Security is **continuously adapting**, not periodically configured
|
||
* Identity, access, and secrets form a **coherent control loop**
|
||
* The system can **start small (bootstrap)** and grow into **enterprise-grade security**
|
||
* You **select the capabilities you need**, and NetKingdom **places and
|
||
orchestrates** the right components to **turn-key readiness** — bringing
|
||
an IT landscape up safely and iteratively, like building a house to
|
||
handover condition
|
||
* Security decisions become **observable, testable, and evolvable**
|
||
|
||
---
|
||
|
||
## Core Principles
|
||
|
||
### 1. Bootstrap First
|
||
|
||
Security must work **before the platform is complete**.
|
||
|
||
A minimal, local, and controllable identity and trust layer is essential to:
|
||
|
||
* start systems safely
|
||
* evolve them incrementally
|
||
|
||
---
|
||
|
||
### 2. Identity is the Control Plane
|
||
|
||
Security is fundamentally about **who can do what, under which conditions**.
|
||
|
||
NetKingdom treats identity as:
|
||
|
||
* the **primary abstraction layer**
|
||
* the **integration contract across systems** (e.g. IAM Profile)
|
||
|
||
---
|
||
|
||
### 3. Open & Replaceable Core
|
||
|
||
Every component should be:
|
||
|
||
* based on **open standards**
|
||
* **replaceable without breaking the system**
|
||
* observable and verifiable
|
||
|
||
No hidden black boxes at the foundation.
|
||
|
||
---
|
||
|
||
### 4. Progressive, Capability-Driven Expansion
|
||
|
||
Security evolves by **adding capabilities**, not by rebuilding. The path
|
||
runs from bootstrap identity, through lightweight SSO and 2FA, runtime
|
||
secrets and fine-grained authorization, up to enterprise federation SSO —
|
||
but each step is taken **because a capability is needed, never because of
|
||
user count**. Footprint and cost follow the capability choice; they do not
|
||
drive it.
|
||
|
||
Each tier must:
|
||
|
||
* **be usable on its own** — you get value at every tier, not only at the top
|
||
* **transition without structural breaks** — because every tier targets
|
||
the same IAM Profile contract, adding 2FA, secrets, authorization, or
|
||
federation *extends* the system rather than replacing it
|
||
|
||
> The concrete capability ladder (C0–C6) lives in
|
||
> `docs/platform-identity-security-architecture.md` → *Capability Progression*.
|
||
|
||
---
|
||
|
||
### 5. Self-Optimization over Static Configuration
|
||
|
||
The system should:
|
||
|
||
* learn from usage
|
||
* adapt policies
|
||
* surface inconsistencies
|
||
|
||
Security becomes a **feedback system**, not a rule set.
|
||
|
||
---
|
||
|
||
### 6. Minimize Threat Exposure by Design
|
||
|
||
Instead of reacting to threats:
|
||
|
||
* reduce attack surface early
|
||
* constrain capabilities intentionally
|
||
* enforce least privilege from the start
|
||
|
||
---
|
||
|
||
### 7. Meta-Orchestration over Re-Implementation
|
||
|
||
NetKingdom does not re-implement deployment mechanics. Execution lives in
|
||
**Railiance playbooks** — parametrized, scenario-specific, with sensible
|
||
defaults. NetKingdom performs **meta-orchestration**:
|
||
|
||
* **select** the services and playbooks a scenario requires
|
||
* **parametrize** them where tuning is warranted; otherwise trust defaults
|
||
* **hold the responsibility map** — which element (a Railiance layer, an
|
||
external provider, a tenant-owned piece) owns what across the landscape
|
||
|
||
NetKingdom is the architect and conductor; Railiance is the contractor and
|
||
the instrument. (See ADR-0007 → *Meta-Orchestration Layer*.)
|
||
|
||
---
|
||
|
||
## Operating Model — A Kingdom Run by Kaizen Agents
|
||
|
||
Once a reasonable setup is established, the kingdom is not left to run
|
||
itself by accident. It is **staffed**. NetKingdom adopts a
|
||
**kaizen-agentic** operating model: specialized agents are "hired" and
|
||
assigned to the work the kingdom needs done on an ongoing basis —
|
||
|
||
* **Recurring duties** that keep the kingdom healthy: readiness checks,
|
||
rotation, audit review, drift detection, backup/restore drills,
|
||
consistency reconciliation.
|
||
* **Change and improvement work**, where agents matter even more:
|
||
introducing a new capability tier, onboarding a tenant, refining policy,
|
||
remediating findings — each carried out as inspectable, repeatable work.
|
||
|
||
This is the human-and-agent embodiment of *Self-Optimization* (Principle
|
||
5): the kingdom continuously improves because it has a workforce attending
|
||
to it, not because a static configuration happens to hold.
|
||
|
||
---
|
||
|
||
## What This Is (Conceptually)
|
||
|
||
NetKingdom is:
|
||
|
||
* a **security control core**
|
||
* a **reference architecture**
|
||
* a **bootstrap path from zero → production-grade security**
|
||
* a **capability-selectable, turn-key orchestrator** for identity,
|
||
authentication, and authorization — it places the right components and
|
||
brings them to ready-to-run state, then grows tier by tier
|
||
* a **contract layer for identity and trust**
|
||
* a **foundation for agent-aware security systems**
|
||
|
||
This is the larger ambition: an **IT-security framework that builds IT
|
||
landscapes safely and iteratively from scratch** — you choose how far up
|
||
the capability ladder you need to go, and the system gets you there
|
||
without structural breaks.
|
||
|
||
---
|
||
|
||
## What This Is Not
|
||
|
||
NetKingdom is not:
|
||
|
||
* a full infrastructure platform
|
||
* an application framework
|
||
* a monolithic security product
|
||
* a closed ecosystem
|
||
|
||
It is the **security spine** that other systems attach to.
|
||
|
||
---
|
||
|
||
## Direction of Evolution
|
||
|
||
NetKingdom is expected to evolve toward:
|
||
|
||
* **Agent-aware security orchestration**
|
||
* **A standing workforce of kaizen agents** tending the kingdom's
|
||
recurring duties and driving its improvements
|
||
* **Meta-orchestrated, turn-key landscapes** composed from Railiance
|
||
playbooks per scenario
|
||
* **Policy as code with feedback loops**
|
||
* **Tight integration with DevSecOps workflows**
|
||
* **Autonomous detection and mitigation patterns**
|
||
* **Security as a continuously optimized system**
|
||
|
||
---
|
||
|
||
## Guiding Question
|
||
|
||
> **How can security become a system that improves itself while remaining fully observable, controllable, and grounded in open primitives?**
|
||
|