generated from coulomb/repo-seed
tegwick
1bff863143
Make the lightweight->expanded decision explicitly capability-driven (not scale-driven) and capture the turn-key, capability-selectable framework ambition. - arch doc: add capability-driven rationale to the identity-mode choice; add a "Capability Progression (Start Small -> Enterprise)" ladder (C0 bootstrap -> C6 self-optimizing), including the C2a/C2b 2FA split (Authelia built-in vs privacyIDEA); answer the lightweight/expanded open question as capability-driven - INTENT.md: recast Progressive Expansion as capability-driven with a no-structural-breaks guarantee; add capability-selection + turn-key orchestration to the mission and identity Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
196 lines
5.2 KiB
Markdown
196 lines
5.2 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**
|
||
|
||
---
|
||
|
||
## 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
|
||
|
||
---
|
||
|
||
## 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**
|
||
* **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?**
|
||
|