generated from coulomb/repo-seed
Add security architecture pattern infospace
This commit is contained in:
@@ -0,0 +1,115 @@
|
||||
# Capability: Object Storage Access
|
||||
|
||||
Status: draft
|
||||
Readiness target: RL3 production
|
||||
Primary owners: NetKingdom, Railiance platform, artifact-store
|
||||
|
||||
## Intent
|
||||
|
||||
Provide safe object-storage access for platform and tenant workloads
|
||||
without giving applications long-lived root credentials or making each
|
||||
application own storage authorization policy.
|
||||
|
||||
## Scope
|
||||
|
||||
Included:
|
||||
|
||||
- identity-backed access requests;
|
||||
- bucket, prefix, action, tenant, and TTL scoping;
|
||||
- temporary credentials with session token and expiration;
|
||||
- audit correlation across identity, authorization, OpenBao, backend,
|
||||
and workload events;
|
||||
- transitional static credential bridge where STS is not ready.
|
||||
|
||||
Excluded:
|
||||
|
||||
- object-storage backend deployment;
|
||||
- product-specific artifact package semantics;
|
||||
- replacing flex-auth with provider-specific bucket policy;
|
||||
- exposing parent object-store credentials to tenant workloads.
|
||||
|
||||
## Threats Addressed
|
||||
|
||||
- leaked long-lived object-store access keys;
|
||||
- application repos becoming policy owners for storage access;
|
||||
- cross-tenant bucket or prefix access;
|
||||
- workloads using platform-root object-store credentials;
|
||||
- unaudited access to generated artifacts, backups, reports, and
|
||||
evidence packages;
|
||||
- failure to revoke or expire credentials after task completion.
|
||||
|
||||
## Required Controls
|
||||
|
||||
- IAM Profile token validation for human, service, and agent callers.
|
||||
- flex-auth decision envelope for protected system, tenant, resource,
|
||||
action set, TTL, assurance, obligations, and deny reason.
|
||||
- Provider-native temporary credentials where the backend supports them.
|
||||
- OpenBao custody for parent credentials, broker configuration, delivery
|
||||
secrets, and audit records where used.
|
||||
- Consumer support for `AWS_SESSION_TOKEN` and expiration-aware refresh.
|
||||
- Durable audit sink and correlation id.
|
||||
|
||||
## Implementation Options
|
||||
|
||||
| Option | Use when | Notes |
|
||||
| --- | --- | --- |
|
||||
| AWS STS `AssumeRoleWithWebIdentity` | AWS-native object storage | Strong native fit; use IAM OIDC provider and role trust policies |
|
||||
| Ceph RGW STS | self-hosted Ceph object storage | Use when RGW IAM/STS maturity fits deployment risk |
|
||||
| MinIO/AIStor STS | lightweight or self-hosted S3-compatible storage | Good fit if consumers support session tokens |
|
||||
| Cloudflare R2 temporary credentials | Cloudflare object storage | Requires backend-specific broker protecting parent credentials |
|
||||
| Transitional static bridge | before STS support is ready | Store scoped static credentials in OpenBao; rotate and retire quickly |
|
||||
|
||||
## Platform Responsibility
|
||||
|
||||
- define issuer, audience, tenant, and assurance requirements;
|
||||
- define flex-auth resource/action vocabulary;
|
||||
- operate or approve the credential-vending service;
|
||||
- protect backend parent credentials through OpenBao;
|
||||
- provide audit retention and break-glass procedure.
|
||||
|
||||
## Product Responsibility
|
||||
|
||||
- use temporary credentials rather than root/static credentials;
|
||||
- refresh credentials before expiration;
|
||||
- include correlation ids in storage operations where possible;
|
||||
- handle deny and expiration cleanly;
|
||||
- avoid embedding policy decisions in application code.
|
||||
|
||||
## Tenant Responsibility
|
||||
|
||||
- request access only to registered tenant resources;
|
||||
- manage tenant-scoped groups or memberships where delegated;
|
||||
- review tenant-visible audit events where available.
|
||||
|
||||
## Readiness Criteria
|
||||
|
||||
| Level | Criteria |
|
||||
| --- | --- |
|
||||
| RL1 | static scoped credentials are not committed; object-store root credentials are not used |
|
||||
| RL2 | tenant/bucket/prefix mapping exists; OpenBao or equivalent custody protects credentials |
|
||||
| RL3 | temporary credentials, session token support, flex-auth decisions, audit correlation, and refresh behavior are verified |
|
||||
| RL4 | tenant-visible audit, dual control for platform-scoped access, restore/revocation drills, and standards mapping are complete |
|
||||
|
||||
## Evidence
|
||||
|
||||
- `docs/object-storage-sts-credential-vending.md`
|
||||
- `ADR-0008 - Object Storage STS Credential Vending Boundary`
|
||||
- artifact-store support for `AWS_SESSION_TOKEN`
|
||||
- OpenBao audit record for broker/parent credential access
|
||||
- flex-auth decision record with stable reason codes
|
||||
- backend credential expiration and revocation proof
|
||||
|
||||
## Related Patterns
|
||||
|
||||
- `pattern-sts-credential-vending.md`
|
||||
- secret zero avoidance
|
||||
- delegated authorization
|
||||
- workload identity
|
||||
- central audit ledger
|
||||
|
||||
## Related Standards
|
||||
|
||||
- NIST CSF Protect and Detect functions.
|
||||
- OWASP API Security broken object-level authorization risk.
|
||||
- SLSA and artifact integrity patterns where object storage holds release
|
||||
artifacts or provenance.
|
||||
@@ -0,0 +1,44 @@
|
||||
# Pattern: API Gateway as Security Boundary
|
||||
|
||||
Status: seed
|
||||
Readiness target: RL3 production
|
||||
Primary owners: Railiance platform, product repos
|
||||
Genesis family: Application/API security
|
||||
|
||||
## Problem
|
||||
|
||||
Public APIs need consistent edge protections before traffic reaches
|
||||
product services.
|
||||
|
||||
## Context
|
||||
|
||||
Use this pattern for public HTTP APIs, tenant-facing APIs, admin APIs,
|
||||
ingress paths, rate limiting, schema checks, authentication, and edge
|
||||
logging.
|
||||
|
||||
## Forces
|
||||
|
||||
- Gateways can centralize common controls.
|
||||
- Applications still need local authorization and validation.
|
||||
- Edge policies must not hide tenant or object-level checks.
|
||||
- Admin APIs require stricter exposure rules than public product APIs.
|
||||
|
||||
## Solution
|
||||
|
||||
Place a managed gateway at API ingress to enforce authentication
|
||||
prechecks, TLS, rate limits, request size, schema constraints, logging,
|
||||
and routing before forwarding to application enforcement points.
|
||||
|
||||
## Verification
|
||||
|
||||
- Unauthenticated or malformed requests are rejected at the edge.
|
||||
- Rate limits and abuse controls are active.
|
||||
- Admin surfaces use separate routes and stronger controls.
|
||||
- Application-level object authorization still runs behind the gateway.
|
||||
|
||||
## Related Patterns
|
||||
|
||||
- Object-Level Authorization Check.
|
||||
- Schema-First API Security.
|
||||
- Network Default Deny.
|
||||
- Central Audit Ledger.
|
||||
@@ -0,0 +1,46 @@
|
||||
# Pattern: Backend-for-Frontend
|
||||
|
||||
Status: seed
|
||||
Readiness target: RL2 private beta
|
||||
Primary owners: product repos, NetKingdom
|
||||
Genesis family: Application/API security
|
||||
|
||||
## Problem
|
||||
|
||||
Different UI clients often need different API shapes, but exposing broad
|
||||
backend APIs directly to browsers or mobile clients increases token and
|
||||
data exposure.
|
||||
|
||||
## Context
|
||||
|
||||
Use this pattern for web frontends, mobile clients, admin consoles,
|
||||
tenant portals, and agent-facing UI surfaces.
|
||||
|
||||
## Forces
|
||||
|
||||
- UI clients need tailored data and workflow APIs.
|
||||
- Backend services may expose fields or operations that clients should
|
||||
not see.
|
||||
- Tokens and sessions need client-appropriate handling.
|
||||
- Authorization decisions still need tenant and object context.
|
||||
|
||||
## Solution
|
||||
|
||||
Create a client-specific backend layer that mediates session handling,
|
||||
data shaping, authorization calls, and downstream API access for one
|
||||
frontend class.
|
||||
|
||||
## Verification
|
||||
|
||||
- The BFF exposes only client-appropriate operations and fields.
|
||||
- Downstream calls include trusted user, tenant, and authorization
|
||||
context.
|
||||
- Sensitive backend tokens are not exposed to clients.
|
||||
- Session and CSRF controls match the client type.
|
||||
|
||||
## Related Patterns
|
||||
|
||||
- API Gateway as Security Boundary.
|
||||
- Object-Level Authorization Check.
|
||||
- Tenant Context Propagation.
|
||||
- Schema-First API Security.
|
||||
@@ -0,0 +1,77 @@
|
||||
# Pattern: Break-Glass Access
|
||||
|
||||
Status: reviewed
|
||||
Readiness target: RL3 production
|
||||
Primary owners: NetKingdom, Railiance platform
|
||||
|
||||
## Problem
|
||||
|
||||
Operators need a recovery path when normal identity, policy, cluster, or
|
||||
secret services fail, but emergency access can easily become an
|
||||
unbounded platform-root bypass.
|
||||
|
||||
## Context
|
||||
|
||||
Use this pattern for OpenBao recovery, cluster recovery, privileged
|
||||
account recovery, incident containment, and platform restore workflows.
|
||||
|
||||
## Forces
|
||||
|
||||
- Emergency access must work during partial outages.
|
||||
- It must be limited, auditable, and rarely used.
|
||||
- Tenant administrators must not receive platform-root powers.
|
||||
- Post-event review must turn emergency use into durable fixes.
|
||||
|
||||
## Solution
|
||||
|
||||
Define a small emergency path with explicit custody, MFA or quorum where
|
||||
possible, narrow scope, recorded use, and mandatory post-event review.
|
||||
Keep it separate from ordinary administration.
|
||||
|
||||
## Implementation Sketch
|
||||
|
||||
1. Identify emergency scenarios and required minimum authority.
|
||||
2. Store emergency material separately with named custodians.
|
||||
3. Require ceremony, reason, and timestamp for use.
|
||||
4. Alert on activation where systems are available.
|
||||
5. Rotate or reseal affected credentials after use.
|
||||
6. Run post-event review and close follow-up tasks.
|
||||
|
||||
## Failure Modes
|
||||
|
||||
| Failure | Mitigation |
|
||||
| --- | --- |
|
||||
| Break-glass becomes routine admin | require review and track frequency |
|
||||
| Emergency access is too broad | define scenario-specific bundles |
|
||||
| Recovery material is stale | run drills and rotation checks |
|
||||
| Tenant admins gain platform-root access | hard-separate tenant and platform authority |
|
||||
|
||||
## Related Capabilities
|
||||
|
||||
- Incident response and recovery.
|
||||
- Privileged access management.
|
||||
- Secrets, keys, and credentials.
|
||||
- Security governance and production readiness.
|
||||
|
||||
## Maturity
|
||||
|
||||
Reviewed. The concept is anchored in NetKingdom/OpenBao planning, but
|
||||
drills and custody evidence are required before canonical graduation.
|
||||
|
||||
## Verification
|
||||
|
||||
- Emergency path is documented and tested.
|
||||
- Activation produces an event record and follow-up review.
|
||||
- Credentials are rotated or revalidated after use.
|
||||
- Tenant and platform emergency powers are separated.
|
||||
|
||||
## Research Basis
|
||||
|
||||
Seeded by break-glass access, incident response process, backup restore,
|
||||
and secret-zero avoidance requirements.
|
||||
|
||||
## References
|
||||
|
||||
- Initial exploration: Identity and access patterns.
|
||||
- Initial exploration: Incident response and recovery.
|
||||
- Railiance OpenBao platform secrets service.
|
||||
@@ -0,0 +1,44 @@
|
||||
# Pattern: Cell-based Architecture
|
||||
|
||||
Status: seed
|
||||
Readiness target: RL3 production
|
||||
Primary owners: Railiance platform, product repos
|
||||
Genesis family: Tenant isolation
|
||||
|
||||
## Problem
|
||||
|
||||
Large multi-tenant systems need blast-radius control when a single
|
||||
shared runtime or data plane would make incidents too broad.
|
||||
|
||||
## Context
|
||||
|
||||
Use this pattern when tenants can be grouped into cells, shards, or
|
||||
regional service instances with independent capacity, deployment, and
|
||||
failure boundaries.
|
||||
|
||||
## Forces
|
||||
|
||||
- Cells reduce blast radius and scaling contention.
|
||||
- Routing and tenant placement become platform responsibilities.
|
||||
- Identity, policy, and audit must work across cells.
|
||||
- Cross-cell operations need strict control and observability.
|
||||
|
||||
## Solution
|
||||
|
||||
Assign tenants to isolated cells that contain runtime, data, or service
|
||||
subsystems. Keep global control-plane operations minimal and require
|
||||
tenant-to-cell mapping in deployment, routing, policy, and audit.
|
||||
|
||||
## Verification
|
||||
|
||||
- Tenant-to-cell placement is explicit and auditable.
|
||||
- Failure in one cell does not grant access to another cell.
|
||||
- Deployments can be rolled out cell by cell.
|
||||
- Cross-cell administrative actions are explicitly authorized.
|
||||
|
||||
## Related Patterns
|
||||
|
||||
- Tenant Isolation.
|
||||
- Tenant Context Propagation.
|
||||
- Central Audit Ledger.
|
||||
- Kill Switch / Tenant Freeze.
|
||||
@@ -0,0 +1,78 @@
|
||||
# Pattern: Central Audit Ledger
|
||||
|
||||
Status: seed
|
||||
Readiness target: RL3 production
|
||||
Primary owners: NetKingdom, Railiance platform, State Hub
|
||||
|
||||
## Problem
|
||||
|
||||
Security-relevant events lose accountability when identity, policy,
|
||||
OpenBao, Kubernetes, deployment, and workload logs remain disconnected.
|
||||
|
||||
## Context
|
||||
|
||||
Use this pattern when platform actions, tenant actions, agent actions,
|
||||
policy decisions, secret access, deployments, and data access must be
|
||||
correlated for operations, incident response, and customer trust.
|
||||
|
||||
## Forces
|
||||
|
||||
- Logs are high volume, but audit events must be durable and searchable.
|
||||
- Tenants may need partial visibility without seeing platform secrets.
|
||||
- Agents and humans need distinct attribution.
|
||||
- Correlation ids must cross system boundaries.
|
||||
|
||||
## Solution
|
||||
|
||||
Define a central security event taxonomy and durable audit ledger for
|
||||
security-sensitive actions. Every protected system emits events with
|
||||
actor, tenant, resource, action, decision, correlation id, and source.
|
||||
|
||||
## Implementation Sketch
|
||||
|
||||
1. Define security event classes and required fields.
|
||||
2. Emit events from key-cape, flex-auth, Topaz, OpenBao, Kubernetes,
|
||||
artifact-store, ops-bridge, and workloads.
|
||||
3. Preserve correlation ids across request, decision, secret, and data
|
||||
paths.
|
||||
4. Protect ledger retention, access, and integrity.
|
||||
5. Add tenant-visible projections where appropriate.
|
||||
|
||||
## Failure Modes
|
||||
|
||||
| Failure | Mitigation |
|
||||
| --- | --- |
|
||||
| Logs exist but cannot answer who did what | require actor/resource/action fields |
|
||||
| Tenant-visible logs expose platform internals | define projection and redaction rules |
|
||||
| Agent events hide behind human account | require explicit agent identity |
|
||||
| Audit sink outage loses privileged events | fail closed for privileged paths or buffer under policy |
|
||||
|
||||
## Related Capabilities
|
||||
|
||||
- Observability, detection, and audit.
|
||||
- Incident response and recovery.
|
||||
- Authorization and access control.
|
||||
- Agent access control.
|
||||
|
||||
## Maturity
|
||||
|
||||
Seed. The need is clear, but storage, retention, projection, and State
|
||||
Hub integration decisions remain open.
|
||||
|
||||
## Verification
|
||||
|
||||
- Critical systems emit events with required fields.
|
||||
- A single correlation id links identity, policy, secret, and workload
|
||||
events.
|
||||
- Ledger access is protected and audited.
|
||||
- Tenant-visible views contain only tenant-appropriate records.
|
||||
|
||||
## Research Basis
|
||||
|
||||
Seeded by security logging, central log collection, audit trail, tenant
|
||||
visible audit logs, and security event taxonomy.
|
||||
|
||||
## References
|
||||
|
||||
- Initial exploration: Observability, detection, and audit.
|
||||
- Initial exploration: Detection and response patterns.
|
||||
@@ -0,0 +1,47 @@
|
||||
# Pattern: Central Identity Provider
|
||||
|
||||
Status: seed
|
||||
Readiness target: RL3 production
|
||||
Primary owners: NetKingdom, key-cape, Keycloak
|
||||
Genesis family: Identity and access
|
||||
|
||||
## Problem
|
||||
|
||||
Services drift into local user stores and inconsistent login behavior
|
||||
when there is no shared identity source.
|
||||
|
||||
## Context
|
||||
|
||||
Use this pattern for platform services, admin tools, product
|
||||
applications, and operational interfaces that need interactive user
|
||||
login or identity claims.
|
||||
|
||||
## Forces
|
||||
|
||||
- Product teams need a simple integration point.
|
||||
- Platform operators need lifecycle, MFA, and audit consistency.
|
||||
- Lightweight local identity and expanded Keycloak deployments need to
|
||||
share a stable profile contract.
|
||||
- Tenant users and platform operators must remain distinguishable.
|
||||
|
||||
## Solution
|
||||
|
||||
Route interactive authentication through a central IdP and expose a
|
||||
stable NetKingdom IAM Profile to consumers. The implementation may be
|
||||
lightweight key-cape mode or expanded Keycloak mode, but applications
|
||||
consume the same issuer, audience, subject, tenant, role, and assurance
|
||||
shape.
|
||||
|
||||
## Verification
|
||||
|
||||
- Applications reject tokens from unknown issuers or audiences.
|
||||
- Privileged flows require MFA or equivalent assurance evidence.
|
||||
- User disablement removes access across integrated services.
|
||||
- Audit events identify user, tenant, issuer, and client.
|
||||
|
||||
## Related Patterns
|
||||
|
||||
- Identity Broker.
|
||||
- Tenant Membership Boundary.
|
||||
- Human/Agent Identity Split.
|
||||
- Delegated Authorization.
|
||||
@@ -0,0 +1,43 @@
|
||||
# Pattern: Certificate Automation
|
||||
|
||||
Status: seed
|
||||
Readiness target: RL3 production
|
||||
Primary owners: Railiance platform, NetKingdom
|
||||
Genesis family: Secrets and cryptography
|
||||
|
||||
## Problem
|
||||
|
||||
Manual certificate issuance and renewal create outages, weak defaults,
|
||||
and stale trust anchors.
|
||||
|
||||
## Context
|
||||
|
||||
Use this pattern for ingress TLS, internal service TLS, mTLS, workload
|
||||
certificates, admin endpoints, and platform APIs.
|
||||
|
||||
## Forces
|
||||
|
||||
- Certificates need automated issuance and renewal.
|
||||
- Trust roots must be owned and rotated.
|
||||
- Internal and external certificate policies differ.
|
||||
- Expiry must be observable before outage.
|
||||
|
||||
## Solution
|
||||
|
||||
Automate certificate issuance, renewal, monitoring, and rotation through
|
||||
approved issuers and scoped identities. Treat certificate authority
|
||||
material as platform-root secret material.
|
||||
|
||||
## Verification
|
||||
|
||||
- Certificates renew before expiry.
|
||||
- Issuers and trust roots are documented and protected.
|
||||
- Expiry monitoring alerts before service impact.
|
||||
- mTLS or internal TLS policies are tested where required.
|
||||
|
||||
## Related Patterns
|
||||
|
||||
- Workload Identity.
|
||||
- Secret Zero Avoidance.
|
||||
- Secure Cluster Baseline.
|
||||
- Network Default Deny.
|
||||
@@ -0,0 +1,45 @@
|
||||
# Pattern: Cluster-per-Tenant
|
||||
|
||||
Status: seed
|
||||
Readiness target: RL4 regulated production
|
||||
Primary owners: Railiance platform
|
||||
Genesis family: Tenant isolation
|
||||
|
||||
## Problem
|
||||
|
||||
Some tenants require stronger runtime and control-plane separation than
|
||||
namespace isolation can provide.
|
||||
|
||||
## Context
|
||||
|
||||
Use this pattern for regulated customers, high-trust deployments,
|
||||
dedicated environments, high-risk workloads, or tenants with contractual
|
||||
isolation requirements.
|
||||
|
||||
## Forces
|
||||
|
||||
- Separate clusters increase isolation and blast-radius control.
|
||||
- More clusters increase operational complexity and cost.
|
||||
- Shared platform services still need consistent identity, policy,
|
||||
secrets, and audit contracts.
|
||||
- Tenant lifecycle and upgrades must remain manageable.
|
||||
|
||||
## Solution
|
||||
|
||||
Allocate a dedicated Kubernetes cluster or equivalent control boundary
|
||||
per tenant while preserving shared NetKingdom identity, authorization,
|
||||
secret, deployment, and audit contracts.
|
||||
|
||||
## Verification
|
||||
|
||||
- Tenant workloads cannot share Kubernetes control-plane authority.
|
||||
- Cluster credentials, secrets, and audit sinks are tenant scoped.
|
||||
- Shared platform integrations preserve tenant identity and ownership.
|
||||
- Restore and upgrade procedures are tested per tenant cluster class.
|
||||
|
||||
## Related Patterns
|
||||
|
||||
- Tenant Isolation.
|
||||
- Shared Control Plane, Isolated Data Plane.
|
||||
- Central Audit Ledger.
|
||||
- Secure Cluster Baseline.
|
||||
@@ -0,0 +1,78 @@
|
||||
# Pattern: Delegated Authorization
|
||||
|
||||
Status: reviewed
|
||||
Readiness target: RL3 production
|
||||
Primary owners: flex-auth, NetKingdom
|
||||
|
||||
## Problem
|
||||
|
||||
Identity providers and application code should not become the scattered
|
||||
home for every tenant, resource, and object-level authorization rule.
|
||||
|
||||
## Context
|
||||
|
||||
Use this pattern for protected systems that need consistent decisions
|
||||
for tenant-scoped resources, privileged operations, object storage,
|
||||
agent access, and application APIs.
|
||||
|
||||
## Forces
|
||||
|
||||
- Applications need local enforcement, but policy needs central shape.
|
||||
- Tenant, resource, action, assurance, and context must travel together.
|
||||
- Some decisions can be delegated to PDP runtimes such as Topaz.
|
||||
- Deny reasons and obligations need to be auditable.
|
||||
|
||||
## Solution
|
||||
|
||||
Use flex-auth as the canonical authorization boundary. Callers submit a
|
||||
standard decision request; flex-auth evaluates directly or delegates to
|
||||
Topaz; applications enforce the returned allow/deny, obligations, and
|
||||
audit metadata at the boundary.
|
||||
|
||||
## Implementation Sketch
|
||||
|
||||
1. Register protected systems and resource/action vocabulary.
|
||||
2. Define the decision envelope and CARING descriptors.
|
||||
3. Add policy packages with tenant/platform separation.
|
||||
4. Delegate to Topaz where ReBAC or policy runtime support is useful.
|
||||
5. Return stable allow/deny, reason, obligation, and audit fields.
|
||||
6. Require applications to enforce decisions before resource access.
|
||||
|
||||
## Failure Modes
|
||||
|
||||
| Failure | Mitigation |
|
||||
| --- | --- |
|
||||
| App ignores deny obligations | add conformance tests at enforcement points |
|
||||
| Policies mix platform and tenant authority | separate policy packages and review paths |
|
||||
| Decision context omits tenant | fail closed |
|
||||
| PDP outage becomes implicit allow | fail closed except documented emergency flows |
|
||||
|
||||
## Related Capabilities
|
||||
|
||||
- Authorization and access control.
|
||||
- Tenant isolation.
|
||||
- Application and API security.
|
||||
- Observability, detection, and audit.
|
||||
|
||||
## Maturity
|
||||
|
||||
Reviewed. This is a core NetKingdom boundary and should become
|
||||
canonical once flex-auth conformance fixtures are stable.
|
||||
|
||||
## Verification
|
||||
|
||||
- Decision envelopes include actor, tenant, resource, action, context,
|
||||
obligations, reason, and audit id.
|
||||
- Enforcement points deny when flex-auth denies or is unavailable.
|
||||
- Topaz delegation is visible in decision records.
|
||||
- Tenant and platform policy packages are separated.
|
||||
|
||||
## Research Basis
|
||||
|
||||
Seeded by the policy decision point/enforcement point pattern, tenant
|
||||
scoped authorization, API authorization, and CARING modeling notes.
|
||||
|
||||
## References
|
||||
|
||||
- NetKingdom platform identity/security architecture.
|
||||
- Initial exploration: Authorization and access control.
|
||||
@@ -0,0 +1,42 @@
|
||||
# Pattern: Dependency Update Bot
|
||||
|
||||
Status: seed
|
||||
Readiness target: RL2 private beta
|
||||
Primary owners: product repos
|
||||
Genesis family: Supply chain
|
||||
|
||||
## Problem
|
||||
|
||||
Dependency updates become stale, risky, and manual when there is no
|
||||
repeatable intake and test path.
|
||||
|
||||
## Context
|
||||
|
||||
Use this pattern for application dependencies, container base images,
|
||||
GitHub Actions, Helm charts, Terraform providers, and platform tools.
|
||||
|
||||
## Forces
|
||||
|
||||
- Automated updates reduce known-vulnerability exposure.
|
||||
- Update noise can overwhelm reviewers.
|
||||
- Security updates need prioritization.
|
||||
- Tests must catch compatibility breakage.
|
||||
|
||||
## Solution
|
||||
|
||||
Use automated dependency update pull requests with grouping rules,
|
||||
security prioritization, test gates, review ownership, and release notes.
|
||||
|
||||
## Verification
|
||||
|
||||
- Dependency inventory is covered by update automation.
|
||||
- Security updates are surfaced with priority.
|
||||
- Update PRs run relevant tests.
|
||||
- Deferred updates have owner and reason.
|
||||
|
||||
## Related Patterns
|
||||
|
||||
- Protected Main Branch.
|
||||
- SBOM-per-Release.
|
||||
- Quarantined Build Runner.
|
||||
- Supply-Chain Provenance.
|
||||
@@ -0,0 +1,76 @@
|
||||
# Pattern: Dynamic Secrets
|
||||
|
||||
Status: draft
|
||||
Readiness target: RL3 production
|
||||
Primary owners: Railiance platform, OpenBao
|
||||
|
||||
## Problem
|
||||
|
||||
Static service credentials accumulate, drift from ownership, and remain
|
||||
useful after compromise.
|
||||
|
||||
## Context
|
||||
|
||||
Use this pattern for databases, object stores, message brokers, internal
|
||||
APIs, and operator workflows where credentials can be issued with a
|
||||
lease and revoked after use.
|
||||
|
||||
## Forces
|
||||
|
||||
- Consumers need credentials on demand.
|
||||
- Backends vary in their ability to mint short-lived credentials.
|
||||
- Lease and revocation behavior must be observable.
|
||||
- Application teams need stable integration contracts even when backend
|
||||
credential mechanisms differ.
|
||||
|
||||
## Solution
|
||||
|
||||
Use OpenBao or a credential broker to issue scoped credentials with TTL,
|
||||
lease metadata, renewal rules, and revocation. Keep parent credentials
|
||||
inside the platform secret authority.
|
||||
|
||||
## Implementation Sketch
|
||||
|
||||
1. Define a protected system and role for each dynamic credential type.
|
||||
2. Authenticate the caller with workload or human identity.
|
||||
3. Authorize requested scope and TTL through policy.
|
||||
4. Generate backend-native credentials or brokered session material.
|
||||
5. Record lease id, caller, tenant, backend, and expiry.
|
||||
6. Revoke credentials on expiry, deployment teardown, or incident.
|
||||
|
||||
## Failure Modes
|
||||
|
||||
| Failure | Mitigation |
|
||||
| --- | --- |
|
||||
| Backend does not support dynamic users | use brokered credentials or shorter static bridge with explicit exception |
|
||||
| Lease renewal hides stale consumers | cap max TTL and require owner metadata |
|
||||
| Parent credential exposed to apps | keep parent material only in OpenBao or broker config |
|
||||
| Revocation is untested | include revocation drills in readiness gates |
|
||||
|
||||
## Related Capabilities
|
||||
|
||||
- Secrets, keys, and credentials.
|
||||
- Authorization and access control.
|
||||
- Observability, detection, and audit.
|
||||
|
||||
## Maturity
|
||||
|
||||
Draft. The OpenBao direction is established, but each backend needs a
|
||||
verified lease and revocation story.
|
||||
|
||||
## Verification
|
||||
|
||||
- Issued credentials have owner, scope, TTL, and lease metadata.
|
||||
- Revocation invalidates access at the backend.
|
||||
- Expired credentials are rejected.
|
||||
- Audit records link issuance and revocation to actor and tenant.
|
||||
|
||||
## Research Basis
|
||||
|
||||
Seeded by central secrets management, workload secret injection, secret
|
||||
rotation, short-lived credentials, and OpenBao runtime authority.
|
||||
|
||||
## References
|
||||
|
||||
- Initial exploration: Secrets, keys, and credentials.
|
||||
- Railiance OpenBao platform secrets service.
|
||||
@@ -0,0 +1,44 @@
|
||||
# Pattern: External Secrets Operator
|
||||
|
||||
Status: seed
|
||||
Readiness target: RL3 production
|
||||
Primary owners: Railiance platform, OpenBao
|
||||
Genesis family: Secrets and cryptography
|
||||
|
||||
## Problem
|
||||
|
||||
Kubernetes applications need secrets without making Kubernetes itself
|
||||
the long-term source of truth for secret material.
|
||||
|
||||
## Context
|
||||
|
||||
Use this pattern when workloads consume secrets from OpenBao or another
|
||||
external secret manager through Kubernetes-native references.
|
||||
|
||||
## Forces
|
||||
|
||||
- Workloads often expect Kubernetes Secrets.
|
||||
- Secret source of truth should remain in OpenBao.
|
||||
- Sync creates copies that need scope, ownership, and rotation.
|
||||
- Tenant and namespace boundaries must be respected.
|
||||
|
||||
## Solution
|
||||
|
||||
Use an external secrets controller to reconcile secret references from
|
||||
OpenBao into scoped Kubernetes Secrets, with explicit ownership, refresh
|
||||
intervals, RBAC, namespace boundaries, and audit.
|
||||
|
||||
## Verification
|
||||
|
||||
- Kubernetes Secrets are derived from OpenBao references, not committed
|
||||
plaintext.
|
||||
- Sync permissions are namespace and tenant scoped.
|
||||
- Rotation in OpenBao reaches consumers within the expected interval.
|
||||
- Sync failures are visible and fail safe.
|
||||
|
||||
## Related Patterns
|
||||
|
||||
- Workload Identity.
|
||||
- Dynamic Secrets.
|
||||
- Secret Zero Avoidance.
|
||||
- Namespace-per-Tenant.
|
||||
@@ -0,0 +1,44 @@
|
||||
# Pattern: GitOps with Guardrails
|
||||
|
||||
Status: seed
|
||||
Readiness target: RL3 production
|
||||
Primary owners: Railiance platform, product repos
|
||||
Genesis family: Kubernetes and platform
|
||||
|
||||
## Problem
|
||||
|
||||
GitOps can make operations reproducible while still deploying unsafe
|
||||
state if review, policy, secrets, and provenance controls are weak.
|
||||
|
||||
## Context
|
||||
|
||||
Use this pattern for platform and product deployment repositories,
|
||||
environment promotion, configuration changes, and operational rollbacks.
|
||||
|
||||
## Forces
|
||||
|
||||
- Desired state should be reviewable and auditable.
|
||||
- Secrets must not be exposed in Git.
|
||||
- Policy checks need to run before reconciliation.
|
||||
- Emergency changes need traceability.
|
||||
|
||||
## Solution
|
||||
|
||||
Use Git as the reviewed desired-state source while enforcing branch
|
||||
protection, policy-as-code checks, encrypted secret references, signed
|
||||
artifact admission, and clear rollback procedures.
|
||||
|
||||
## Verification
|
||||
|
||||
- Production changes enter through reviewed commits or documented
|
||||
emergency paths.
|
||||
- Reconciliation rejects policy failures.
|
||||
- Secret plaintext is absent from Git.
|
||||
- Rollbacks preserve audit and policy evidence.
|
||||
|
||||
## Related Patterns
|
||||
|
||||
- Protected Main Branch.
|
||||
- Policy-as-Code Admission Control.
|
||||
- Sealed Secret / Encrypted Git Secret.
|
||||
- Signed Image Admission.
|
||||
@@ -0,0 +1,75 @@
|
||||
# Pattern: Human/Agent Identity Split
|
||||
|
||||
Status: draft
|
||||
Readiness target: RL3 production
|
||||
Primary owners: NetKingdom, ops-bridge, product repos
|
||||
|
||||
## Problem
|
||||
|
||||
Agents acting as invisible extensions of human users make access scope,
|
||||
accountability, rate limits, and incident response ambiguous.
|
||||
|
||||
## Context
|
||||
|
||||
Use this pattern for AI agents, automation workers, repository agents,
|
||||
ops agents, scheduled tasks, and delegated user workflows.
|
||||
|
||||
## Forces
|
||||
|
||||
- Agents need to act on behalf of people or systems.
|
||||
- Human approval does not mean unlimited agent authority.
|
||||
- Audit must distinguish sponsor, agent, tool, and target action.
|
||||
- Agents may need tighter scopes and shorter TTLs than humans.
|
||||
|
||||
## Solution
|
||||
|
||||
Give agents explicit identities with their own scopes, limits,
|
||||
credentials, and audit records. Link agent activity to a human or system
|
||||
sponsor without collapsing them into the same principal.
|
||||
|
||||
## Implementation Sketch
|
||||
|
||||
1. Define agent identity type in IAM Profile or equivalent registry.
|
||||
2. Bind agent to sponsor, purpose, tenant, allowed tools, and TTL.
|
||||
3. Issue scoped credentials or certificates for agent activity.
|
||||
4. Require flex-auth to evaluate agent context separately.
|
||||
5. Emit audit events with both sponsor and agent ids.
|
||||
6. Support revocation by agent, sponsor, tenant, and task.
|
||||
|
||||
## Failure Modes
|
||||
|
||||
| Failure | Mitigation |
|
||||
| --- | --- |
|
||||
| Agent uses human token directly | require separate agent credentials |
|
||||
| Audit only records sponsor | include agent id and tool/action metadata |
|
||||
| Agent keeps broad long-lived access | enforce TTL and purpose-bound scopes |
|
||||
| Tenant cannot revoke delegated agent | support tenant-scoped revocation controls |
|
||||
|
||||
## Related Capabilities
|
||||
|
||||
- Agent access control.
|
||||
- Identity and user management.
|
||||
- Authorization and access control.
|
||||
- Observability, detection, and audit.
|
||||
|
||||
## Maturity
|
||||
|
||||
Draft. The need is explicit in the platform direction; detailed IAM
|
||||
Profile claim shape and ops integration are still open.
|
||||
|
||||
## Verification
|
||||
|
||||
- Agent events are distinguishable from human events.
|
||||
- Revoking the agent does not require disabling the sponsor.
|
||||
- flex-auth decisions include agent context.
|
||||
- Agent credentials have explicit scope and TTL.
|
||||
|
||||
## Research Basis
|
||||
|
||||
Seeded by agent access control, human/agent identity split,
|
||||
time-boxed privilege elevation, and auditability requirements.
|
||||
|
||||
## References
|
||||
|
||||
- Initial exploration: Authorization and access control.
|
||||
- Initial exploration: Identity and access patterns.
|
||||
@@ -0,0 +1,43 @@
|
||||
# Pattern: Idempotent Command API
|
||||
|
||||
Status: seed
|
||||
Readiness target: RL2 private beta
|
||||
Primary owners: product repos
|
||||
Genesis family: Application/API security
|
||||
|
||||
## Problem
|
||||
|
||||
Retries, duplicate submissions, and partial failures can create unsafe
|
||||
state changes when command APIs are not idempotent.
|
||||
|
||||
## Context
|
||||
|
||||
Use this pattern for payment-like operations, provisioning, tenant
|
||||
configuration, file processing, job submission, and external callbacks.
|
||||
|
||||
## Forces
|
||||
|
||||
- Networks and clients retry requests.
|
||||
- Commands need audit and correlation.
|
||||
- Duplicate execution can create data or authorization errors.
|
||||
- Some commands must be scoped to actor and tenant.
|
||||
|
||||
## Solution
|
||||
|
||||
Require command identifiers and replay-safe semantics for state-changing
|
||||
operations. Bind idempotency keys to actor, tenant, command type, and
|
||||
resource scope.
|
||||
|
||||
## Verification
|
||||
|
||||
- Replaying a command id returns the prior result or safe status.
|
||||
- Idempotency keys cannot be reused across tenants or actors.
|
||||
- Command audit records include correlation id and outcome.
|
||||
- Partial failures are recoverable without duplicate effects.
|
||||
|
||||
## Related Patterns
|
||||
|
||||
- Tenant Context Propagation.
|
||||
- Central Audit Ledger.
|
||||
- Schema-First API Security.
|
||||
- Incident Runbook Library.
|
||||
@@ -0,0 +1,47 @@
|
||||
# Pattern: Identity Broker
|
||||
|
||||
Status: seed
|
||||
Readiness target: RL3 production
|
||||
Primary owners: NetKingdom, key-cape, Keycloak
|
||||
Genesis family: Identity and access
|
||||
|
||||
## Problem
|
||||
|
||||
External, customer, or ecosystem identities cannot be trusted directly
|
||||
by every product service without duplicating federation and mapping
|
||||
logic.
|
||||
|
||||
## Context
|
||||
|
||||
Use this pattern when tenants bring their own IdP, when operators need
|
||||
multiple upstream identity sources, or when the platform must normalize
|
||||
federated identity into the IAM Profile.
|
||||
|
||||
## Forces
|
||||
|
||||
- Upstream IdPs have different claim shapes and assurance semantics.
|
||||
- Tenant membership is not the same as global user identity.
|
||||
- Product applications need stable claims.
|
||||
- Federation errors can create cross-tenant or privilege confusion.
|
||||
|
||||
## Solution
|
||||
|
||||
Broker external identity through a controlled IAM layer that validates
|
||||
upstream issuer trust, maps claims into the NetKingdom IAM Profile, and
|
||||
records federation source, tenant membership, assurance, and lifecycle
|
||||
state.
|
||||
|
||||
## Verification
|
||||
|
||||
- Each upstream IdP has explicit trust metadata and claim mappings.
|
||||
- Tenant membership is resolved after federation, not assumed from raw
|
||||
upstream claims.
|
||||
- Assurance and MFA evidence are normalized for privileged flows.
|
||||
- Federation failures fail closed with auditable reason codes.
|
||||
|
||||
## Related Patterns
|
||||
|
||||
- Central Identity Provider.
|
||||
- Tenant Membership Boundary.
|
||||
- Role Composition.
|
||||
- Object-Level Authorization Check.
|
||||
@@ -0,0 +1,44 @@
|
||||
# Pattern: Incident Runbook Library
|
||||
|
||||
Status: seed
|
||||
Readiness target: RL3 production
|
||||
Primary owners: NetKingdom, Railiance platform, product repos
|
||||
Genesis family: Detection and response
|
||||
|
||||
## Problem
|
||||
|
||||
Incident response becomes slow and inconsistent when teams rely on
|
||||
memory or ad hoc decisions during security events.
|
||||
|
||||
## Context
|
||||
|
||||
Use this pattern for credential compromise, tenant isolation incidents,
|
||||
malicious uploads, policy bypass, OpenBao recovery, build compromise,
|
||||
and platform outage scenarios.
|
||||
|
||||
## Forces
|
||||
|
||||
- Incidents need quick containment.
|
||||
- Actions must be safe, authorized, and reversible where possible.
|
||||
- Evidence preservation matters.
|
||||
- Tenant communication and post-incident learning need structure.
|
||||
|
||||
## Solution
|
||||
|
||||
Maintain a reviewed library of incident runbooks with triggers,
|
||||
severity, roles, containment steps, evidence handling, tenant
|
||||
communication, recovery, and post-incident follow-up.
|
||||
|
||||
## Verification
|
||||
|
||||
- High-value scenarios have runbooks with owners.
|
||||
- Runbooks are tested through drills or tabletop exercises.
|
||||
- Containment actions link to audit and decision records.
|
||||
- Post-incident reviews create tracked follow-up work.
|
||||
|
||||
## Related Patterns
|
||||
|
||||
- Break-glass Access.
|
||||
- Kill Switch / Tenant Freeze.
|
||||
- Token Revocation Sweep.
|
||||
- Central Audit Ledger.
|
||||
@@ -0,0 +1,43 @@
|
||||
# Pattern: Key-per-Tenant
|
||||
|
||||
Status: seed
|
||||
Readiness target: RL4 regulated production
|
||||
Primary owners: NetKingdom, Railiance platform, product repos
|
||||
Genesis family: Secrets and cryptography
|
||||
|
||||
## Problem
|
||||
|
||||
Shared encryption keys make tenant data separation and incident
|
||||
containment weaker than the tenant model may require.
|
||||
|
||||
## Context
|
||||
|
||||
Use this pattern for sensitive tenant data, regulated tenants, object
|
||||
storage, databases, backups, and export/deletion workflows.
|
||||
|
||||
## Forces
|
||||
|
||||
- Per-tenant keys strengthen isolation and revocation.
|
||||
- Key lifecycle is operationally complex.
|
||||
- Applications need safe key selection without tenant spoofing.
|
||||
- Backups and derived data need the same key boundary.
|
||||
|
||||
## Solution
|
||||
|
||||
Assign tenant-specific encryption keys or key hierarchy roots where risk
|
||||
requires it. Bind key use to trusted tenant context, policy, audit, and
|
||||
rotation procedures.
|
||||
|
||||
## Verification
|
||||
|
||||
- Tenant data is encrypted with the correct tenant key or key hierarchy.
|
||||
- Cross-tenant key use is denied.
|
||||
- Rotation and revocation are tested.
|
||||
- Backups and exports preserve tenant key boundaries.
|
||||
|
||||
## Related Patterns
|
||||
|
||||
- Tenant Data Partitioning.
|
||||
- Tenant Context Propagation.
|
||||
- OpenBao runtime secret authority.
|
||||
- Central Audit Ledger.
|
||||
@@ -0,0 +1,43 @@
|
||||
# Pattern: Kill Switch / Tenant Freeze
|
||||
|
||||
Status: seed
|
||||
Readiness target: RL3 production
|
||||
Primary owners: NetKingdom, product repos, Railiance platform
|
||||
Genesis family: Detection and response
|
||||
|
||||
## Problem
|
||||
|
||||
Operators need a fast containment mechanism when a tenant, app, token,
|
||||
or integration appears compromised or abusive.
|
||||
|
||||
## Context
|
||||
|
||||
Use this pattern for tenant compromise, runaway automation, abusive API
|
||||
usage, malicious uploads, credential exposure, or legal/security holds.
|
||||
|
||||
## Forces
|
||||
|
||||
- Containment must be fast.
|
||||
- Freezing a tenant can be high impact.
|
||||
- Actions need scope, reason, approval, and audit.
|
||||
- Recovery must be predictable and reversible where possible.
|
||||
|
||||
## Solution
|
||||
|
||||
Provide controlled kill-switch or tenant-freeze states that can block
|
||||
login, API access, background jobs, credential vending, uploads, or data
|
||||
mutation according to scoped policy.
|
||||
|
||||
## Verification
|
||||
|
||||
- Freeze actions take effect across API, jobs, credentials, and uploads.
|
||||
- Scope and reason are recorded.
|
||||
- Tenant-visible communication rules are defined.
|
||||
- Unfreeze requires authorized review and audit.
|
||||
|
||||
## Related Patterns
|
||||
|
||||
- Tenant Isolation.
|
||||
- Token Revocation Sweep.
|
||||
- Incident Runbook Library.
|
||||
- Central Audit Ledger.
|
||||
@@ -0,0 +1,44 @@
|
||||
# Pattern: Namespace-per-Tenant
|
||||
|
||||
Status: seed
|
||||
Readiness target: RL2 private beta
|
||||
Primary owners: Railiance platform, product repos
|
||||
Genesis family: Tenant isolation
|
||||
|
||||
## Problem
|
||||
|
||||
Shared Kubernetes clusters need tenant boundaries without the cost and
|
||||
operational overhead of one cluster per tenant.
|
||||
|
||||
## Context
|
||||
|
||||
Use this pattern for medium-strength tenant isolation where workloads can
|
||||
share a cluster but need separate Kubernetes namespaces, resource
|
||||
quotas, network policies, and access controls.
|
||||
|
||||
## Forces
|
||||
|
||||
- Shared clusters reduce platform cost.
|
||||
- Namespaces are not a hard security boundary by themselves.
|
||||
- Tenant workloads need quotas, labels, policies, and ownership.
|
||||
- Platform controllers can accidentally gain cross-tenant reach.
|
||||
|
||||
## Solution
|
||||
|
||||
Assign each tenant one or more namespaces with mandatory labels,
|
||||
resource quotas, network default deny, RBAC boundaries, admission
|
||||
policies, and tenant-aware audit events.
|
||||
|
||||
## Verification
|
||||
|
||||
- Tenant service accounts cannot access other tenant namespaces.
|
||||
- Network policies block cross-namespace traffic unless allowed.
|
||||
- Quotas and pod security policies apply to every tenant namespace.
|
||||
- Audit records include namespace and tenant id.
|
||||
|
||||
## Related Patterns
|
||||
|
||||
- Tenant Isolation.
|
||||
- Network Default Deny.
|
||||
- Pod Security Baseline/Restricted.
|
||||
- Tenant Context Propagation.
|
||||
@@ -0,0 +1,76 @@
|
||||
# Pattern: Network Default Deny
|
||||
|
||||
Status: seed
|
||||
Readiness target: RL3 production
|
||||
Primary owners: Railiance platform, product repos
|
||||
|
||||
## Problem
|
||||
|
||||
Flat internal networks allow accidental exposure and lateral movement
|
||||
when one workload, namespace, or tenant is compromised.
|
||||
|
||||
## Context
|
||||
|
||||
Use this pattern for Kubernetes namespaces, tenant workloads, platform
|
||||
services, ingress paths, egress control, admin surfaces, and service to
|
||||
service communication.
|
||||
|
||||
## Forces
|
||||
|
||||
- Services need explicit communication paths.
|
||||
- Product teams need a manageable way to declare network intent.
|
||||
- Some platform services must be reachable across tenants or namespaces.
|
||||
- Debugging becomes harder when default connectivity disappears.
|
||||
|
||||
## Solution
|
||||
|
||||
Deny network traffic by default and allow only explicit, reviewed paths
|
||||
between workloads, namespaces, platform services, ingress, and egress
|
||||
destinations.
|
||||
|
||||
## Implementation Sketch
|
||||
|
||||
1. Apply namespace-level default deny policies.
|
||||
2. Define service-specific ingress and egress policies.
|
||||
3. Separate tenant, platform, admin, and observability networks.
|
||||
4. Route public traffic through managed ingress.
|
||||
5. Log or sample denied flows where practical.
|
||||
6. Provide policy templates for product teams.
|
||||
|
||||
## Failure Modes
|
||||
|
||||
| Failure | Mitigation |
|
||||
| --- | --- |
|
||||
| Broad allow rules recreate flat network | review wildcard selectors and CIDRs |
|
||||
| DNS or observability breaks silently | maintain platform allow templates |
|
||||
| Admin tools exposed like public apps | separate admin surfaces and access paths |
|
||||
| Teams bypass policy through host networking | enforce pod security and admission rules |
|
||||
|
||||
## Related Capabilities
|
||||
|
||||
- Network and edge security.
|
||||
- Tenant isolation.
|
||||
- Platform and Kubernetes hardening.
|
||||
- Observability, detection, and audit.
|
||||
|
||||
## Maturity
|
||||
|
||||
Seed. The pattern is a production baseline candidate; implementation
|
||||
needs Railiance network policy conventions.
|
||||
|
||||
## Verification
|
||||
|
||||
- New namespaces start with deny-all ingress and egress.
|
||||
- Required service paths have explicit policies.
|
||||
- Cross-tenant connectivity is denied by default.
|
||||
- Admin surfaces are not reachable through public workload paths.
|
||||
|
||||
## Research Basis
|
||||
|
||||
Seeded by network segmentation, egress control, service-to-service
|
||||
trust, network default deny, and Kubernetes hardening requirements.
|
||||
|
||||
## References
|
||||
|
||||
- Initial exploration: Network and edge security.
|
||||
- Initial exploration: Kubernetes and platform patterns.
|
||||
@@ -0,0 +1,76 @@
|
||||
# Pattern: Object-Level Authorization Check
|
||||
|
||||
Status: draft
|
||||
Readiness target: RL3 production
|
||||
Primary owners: flex-auth, product repos, NetKingdom
|
||||
|
||||
## Problem
|
||||
|
||||
APIs often authenticate callers correctly while still allowing access to
|
||||
objects, records, files, or tenant resources outside the caller's scope.
|
||||
|
||||
## Context
|
||||
|
||||
Use this pattern for product APIs, admin APIs, object storage brokers,
|
||||
artifact-store, tenant data, background jobs, and any endpoint that
|
||||
accepts resource identifiers.
|
||||
|
||||
## Forces
|
||||
|
||||
- Object ownership and scope are application-specific.
|
||||
- Authorization must happen before data is returned or mutated.
|
||||
- Tenant context must be trusted, not copied from user input.
|
||||
- Bulk, search, and background operations need the same checks.
|
||||
|
||||
## Solution
|
||||
|
||||
Require every object access path to ask an authorization boundary with
|
||||
trusted actor, tenant, resource, action, and context before reading,
|
||||
writing, deleting, exporting, or sharing an object.
|
||||
|
||||
## Implementation Sketch
|
||||
|
||||
1. Define resource types and action vocabulary.
|
||||
2. Derive actor and tenant from trusted identity/session evidence.
|
||||
3. Resolve object ownership or scope before access.
|
||||
4. Ask flex-auth or local policy adapter for a decision.
|
||||
5. Enforce allow/deny before data access.
|
||||
6. Log object-level decisions with correlation ids.
|
||||
|
||||
## Failure Modes
|
||||
|
||||
| Failure | Mitigation |
|
||||
| --- | --- |
|
||||
| Endpoint checks role but not object ownership | add object-level conformance tests |
|
||||
| Search/list endpoints bypass item checks | enforce tenant/resource filters in query layer |
|
||||
| Background jobs run with global authority | carry tenant and actor context in job envelopes |
|
||||
| Deny reason leaks object existence | use stable, non-revealing deny responses |
|
||||
|
||||
## Related Capabilities
|
||||
|
||||
- Application and API security.
|
||||
- Authorization and access control.
|
||||
- Tenant isolation.
|
||||
- Data protection and privacy.
|
||||
|
||||
## Maturity
|
||||
|
||||
Draft. The pattern maps directly to flex-auth but requires product-level
|
||||
adoption and tests.
|
||||
|
||||
## Verification
|
||||
|
||||
- Cross-tenant object access tests fail.
|
||||
- List/search endpoints cannot reveal out-of-scope objects.
|
||||
- Background jobs preserve authorization context.
|
||||
- Deny paths are audited and do not leak sensitive existence details.
|
||||
|
||||
## Research Basis
|
||||
|
||||
Seeded by API authorization, object-level authorization, OWASP API
|
||||
security framing, and tenant-scoped authorization.
|
||||
|
||||
## References
|
||||
|
||||
- Initial exploration: Application and API security.
|
||||
- Initial exploration: Application/API patterns.
|
||||
@@ -0,0 +1,44 @@
|
||||
# Pattern: Pod Security Baseline/Restricted
|
||||
|
||||
Status: seed
|
||||
Readiness target: RL3 production
|
||||
Primary owners: Railiance platform, product repos
|
||||
Genesis family: Kubernetes and platform
|
||||
|
||||
## Problem
|
||||
|
||||
Workloads can gain host, network, filesystem, or privilege escalation
|
||||
capabilities that are unnecessary and dangerous in production.
|
||||
|
||||
## Context
|
||||
|
||||
Use this pattern for Kubernetes workloads, tenant namespaces, platform
|
||||
services, controllers, and admission policies.
|
||||
|
||||
## Forces
|
||||
|
||||
- Some platform components need elevated privileges.
|
||||
- Most product workloads should run with restricted settings.
|
||||
- Exceptions must not become broad namespace bypasses.
|
||||
- Developers need clear guidance for safe pod specs.
|
||||
|
||||
## Solution
|
||||
|
||||
Apply Kubernetes Pod Security baseline or restricted profiles with
|
||||
admission enforcement, explicit exceptions, and tests for privileged
|
||||
features such as host networking, hostPath, root users, and privilege
|
||||
escalation.
|
||||
|
||||
## Verification
|
||||
|
||||
- Non-exempt workloads run as non-root and cannot escalate privileges.
|
||||
- hostPath, host networking, and privileged mode are rejected by default.
|
||||
- Exceptions are scoped, owned, and time bounded.
|
||||
- Policy tests cover representative manifests.
|
||||
|
||||
## Related Patterns
|
||||
|
||||
- Secure Cluster Baseline.
|
||||
- Policy-as-Code Admission Control.
|
||||
- Namespace-per-Tenant.
|
||||
- Network Default Deny.
|
||||
@@ -0,0 +1,42 @@
|
||||
# Pattern: Policy-as-Code Admission Control
|
||||
|
||||
Status: seed
|
||||
Readiness target: RL3 production
|
||||
Primary owners: Railiance platform, NetKingdom
|
||||
Genesis family: Kubernetes and platform
|
||||
|
||||
## Problem
|
||||
|
||||
Unsafe Kubernetes manifests can reach runtime when deployment safety
|
||||
depends only on convention or manual review.
|
||||
|
||||
## Context
|
||||
|
||||
Use this pattern for CI checks, GitOps flows, admission webhooks,
|
||||
namespace guardrails, image trust, pod security, and exception handling.
|
||||
|
||||
## Forces
|
||||
|
||||
- Product teams need self-service deployment.
|
||||
- Platform teams need enforceable guardrails.
|
||||
- Policies must be versioned, reviewable, and tested.
|
||||
- Emergency exceptions need expiry and audit.
|
||||
|
||||
## Solution
|
||||
|
||||
Encode deployment rules as policy packages evaluated before workloads
|
||||
run. Reject or quarantine manifests that violate baseline controls.
|
||||
|
||||
## Verification
|
||||
|
||||
- Unsafe manifests fail in CI and at admission.
|
||||
- Policy packages have tests and review history.
|
||||
- Exceptions carry owner, reason, risk, and expiry.
|
||||
- Admission decisions are logged.
|
||||
|
||||
## Related Patterns
|
||||
|
||||
- Policy-as-Code Admission.
|
||||
- Secure Cluster Baseline.
|
||||
- Pod Security Baseline/Restricted.
|
||||
- Signed Image Admission.
|
||||
@@ -0,0 +1,76 @@
|
||||
# Pattern: Policy-as-Code Admission
|
||||
|
||||
Status: seed
|
||||
Readiness target: RL3 production
|
||||
Primary owners: Railiance platform, NetKingdom
|
||||
|
||||
## Problem
|
||||
|
||||
Unsafe workloads can enter production when deployment checks depend on
|
||||
manual review, inconsistent conventions, or late runtime detection.
|
||||
|
||||
## Context
|
||||
|
||||
Use this pattern for Kubernetes manifests, Helm releases, GitOps
|
||||
deployments, image admission, network policy, pod security, and tenant
|
||||
guardrails.
|
||||
|
||||
## Forces
|
||||
|
||||
- Product teams need self-service deployments.
|
||||
- Platform teams need enforceable production baselines.
|
||||
- Policies must be reviewable and testable.
|
||||
- Emergency exceptions need explicit expiry and audit.
|
||||
|
||||
## Solution
|
||||
|
||||
Represent deployment and platform safety rules as policy packages that
|
||||
run before workloads are admitted. Reject or quarantine unsafe manifests
|
||||
before runtime.
|
||||
|
||||
## Implementation Sketch
|
||||
|
||||
1. Define baseline policies for pod security, RBAC, image trust,
|
||||
namespace ownership, labels, resources, and network intent.
|
||||
2. Run policy checks in CI and admission.
|
||||
3. Version policy packages through Git review.
|
||||
4. Support exceptions with owner, reason, expiry, and risk acceptance.
|
||||
5. Emit policy decision events to the audit ledger.
|
||||
|
||||
## Failure Modes
|
||||
|
||||
| Failure | Mitigation |
|
||||
| --- | --- |
|
||||
| Policies only run in CI | enforce at admission too |
|
||||
| Exceptions never expire | require expiry and review |
|
||||
| Policy language is opaque to teams | publish examples and test fixtures |
|
||||
| Admission outage blocks recovery | document break-glass admission process |
|
||||
|
||||
## Related Capabilities
|
||||
|
||||
- Platform and Kubernetes hardening.
|
||||
- Security governance and production readiness.
|
||||
- Software supply chain security.
|
||||
- Observability, detection, and audit.
|
||||
|
||||
## Maturity
|
||||
|
||||
Seed. The pattern is a baseline candidate, but tool choice and policy
|
||||
package lifecycle need implementation work.
|
||||
|
||||
## Verification
|
||||
|
||||
- Unsafe manifests are rejected before runtime.
|
||||
- Policy packages have tests and change review.
|
||||
- Exceptions are time bounded and visible.
|
||||
- Admission decisions are logged.
|
||||
|
||||
## Research Basis
|
||||
|
||||
Seeded by policy-as-code admission control, pod security
|
||||
baseline/restricted, signed image admission, and GitOps with guardrails.
|
||||
|
||||
## References
|
||||
|
||||
- Initial exploration: Kubernetes and platform patterns.
|
||||
- Initial exploration: Platform and Kubernetes hardening.
|
||||
@@ -0,0 +1,46 @@
|
||||
# Pattern: Policy Decision Point / Policy Enforcement Point
|
||||
|
||||
Status: reviewed
|
||||
Readiness target: RL3 production
|
||||
Primary owners: flex-auth, NetKingdom
|
||||
Genesis family: Identity and access
|
||||
|
||||
## Problem
|
||||
|
||||
Authorization becomes inconsistent when policy decisions live inside
|
||||
many applications without a shared decision contract.
|
||||
|
||||
## Context
|
||||
|
||||
Use this pattern when product services, platform APIs, object-storage
|
||||
brokers, admin tools, and agents need consistent allow or deny decisions
|
||||
for protected resources.
|
||||
|
||||
## Forces
|
||||
|
||||
- Applications must enforce decisions at local boundaries.
|
||||
- Policy needs central shape, testability, and audit.
|
||||
- Tenant, resource, action, assurance, and context must be included.
|
||||
- PDP outages must not become implicit allow.
|
||||
|
||||
## Solution
|
||||
|
||||
Separate policy decision from policy enforcement. flex-auth acts as the
|
||||
canonical PDP boundary and may delegate to Topaz; applications and
|
||||
gateways act as PEPs that enforce allow, deny, obligations, and reason
|
||||
codes.
|
||||
|
||||
## Verification
|
||||
|
||||
- Decision requests include actor, tenant, resource, action, assurance,
|
||||
and context.
|
||||
- PEPs deny on explicit deny, malformed decision, or PDP outage.
|
||||
- Decisions produce stable reason codes and audit correlation ids.
|
||||
- Policy packages are tested before production use.
|
||||
|
||||
## Related Patterns
|
||||
|
||||
- Delegated Authorization.
|
||||
- Role Composition.
|
||||
- Object-Level Authorization Check.
|
||||
- Policy-as-Code Admission Control.
|
||||
@@ -0,0 +1,44 @@
|
||||
# Pattern: Protected Main Branch
|
||||
|
||||
Status: seed
|
||||
Readiness target: RL2 private beta
|
||||
Primary owners: product repos, NetKingdom
|
||||
Genesis family: Supply chain
|
||||
|
||||
## Problem
|
||||
|
||||
Production code can be changed without review, tests, or traceable
|
||||
approval when the main branch is not protected.
|
||||
|
||||
## Context
|
||||
|
||||
Use this pattern for repositories that produce production services,
|
||||
platform manifests, policy packages, documentation standards, or release
|
||||
artifacts.
|
||||
|
||||
## Forces
|
||||
|
||||
- Teams need fast iteration.
|
||||
- Production branches need review and checks.
|
||||
- Emergency fixes need traceable override.
|
||||
- Branch rules should match artifact criticality.
|
||||
|
||||
## Solution
|
||||
|
||||
Protect main and release branches with review, required checks, signed
|
||||
or verified changes where useful, and explicit emergency override
|
||||
procedures.
|
||||
|
||||
## Verification
|
||||
|
||||
- Direct pushes to protected branches are blocked.
|
||||
- Required tests and reviews pass before merge.
|
||||
- Emergency overrides are logged and reviewed.
|
||||
- Release artifacts link back to protected branch commits.
|
||||
|
||||
## Related Patterns
|
||||
|
||||
- GitOps with Guardrails.
|
||||
- SLSA Build Provenance.
|
||||
- SBOM-per-Release.
|
||||
- Supply-Chain Provenance.
|
||||
@@ -0,0 +1,43 @@
|
||||
# Pattern: Quarantined Build Runner
|
||||
|
||||
Status: seed
|
||||
Readiness target: RL3 production
|
||||
Primary owners: Railiance platform, product repos
|
||||
Genesis family: Supply chain
|
||||
|
||||
## Problem
|
||||
|
||||
Build jobs often process untrusted code while also having access to
|
||||
secrets, registries, signing keys, or deployment credentials.
|
||||
|
||||
## Context
|
||||
|
||||
Use this pattern for CI/CD runners, release builders, image builders,
|
||||
dependency test jobs, and signing workflows.
|
||||
|
||||
## Forces
|
||||
|
||||
- Builds need network and artifact access.
|
||||
- Pull requests may contain untrusted code.
|
||||
- Signing and deployment credentials are high impact.
|
||||
- Runners need cleanup and isolation between jobs.
|
||||
|
||||
## Solution
|
||||
|
||||
Run build jobs in isolated, least-privilege environments with limited
|
||||
secrets, scoped network access, clean workspaces, and separate trusted
|
||||
release/signing stages.
|
||||
|
||||
## Verification
|
||||
|
||||
- Untrusted jobs cannot access release or deployment secrets.
|
||||
- Runner workspaces are isolated and cleaned.
|
||||
- Network and registry access are scoped.
|
||||
- Signing happens only in trusted release contexts.
|
||||
|
||||
## Related Patterns
|
||||
|
||||
- SLSA Build Provenance.
|
||||
- Signed Container Images.
|
||||
- Dependency Update Bot.
|
||||
- Protected Main Branch.
|
||||
@@ -0,0 +1,43 @@
|
||||
# Pattern: Role Composition
|
||||
|
||||
Status: seed
|
||||
Readiness target: RL3 production
|
||||
Primary owners: NetKingdom, flex-auth
|
||||
Genesis family: Identity and access
|
||||
|
||||
## Problem
|
||||
|
||||
Hardcoded roles become too broad, inconsistent, and difficult to review
|
||||
as products, tenants, agents, and operational tasks grow.
|
||||
|
||||
## Context
|
||||
|
||||
Use this pattern for platform roles, tenant roles, product roles,
|
||||
operator privileges, and agent scopes.
|
||||
|
||||
## Forces
|
||||
|
||||
- Roles need stable names for people and policy.
|
||||
- Permissions are resource and action specific.
|
||||
- Tenant roles differ from platform roles.
|
||||
- Agents need narrower scopes than human sponsors.
|
||||
|
||||
## Solution
|
||||
|
||||
Compose roles from named capabilities, resource scopes, actions,
|
||||
constraints, and obligations. Keep role vocabulary in a reviewable model
|
||||
that can be evaluated by flex-auth or a delegated PDP.
|
||||
|
||||
## Verification
|
||||
|
||||
- Each role maps to explicit capabilities and action sets.
|
||||
- Privileged roles are time bounded or separately approved.
|
||||
- Tenant and platform roles cannot be confused.
|
||||
- Access reviews can explain why an actor has an action.
|
||||
|
||||
## Related Patterns
|
||||
|
||||
- Policy Decision Point / Policy Enforcement Point.
|
||||
- Time-boxed Privilege Elevation.
|
||||
- Human/Agent Identity Split.
|
||||
- Object-Level Authorization Check.
|
||||
@@ -0,0 +1,46 @@
|
||||
# Pattern: Runtime Threat Detection
|
||||
|
||||
Status: seed
|
||||
Readiness target: RL3 production
|
||||
Primary owners: Railiance platform, NetKingdom
|
||||
Genesis family: Kubernetes and platform
|
||||
|
||||
## Problem
|
||||
|
||||
Admission controls and build checks do not detect every compromise that
|
||||
appears after workloads are running.
|
||||
|
||||
## Context
|
||||
|
||||
Use this pattern for Kubernetes runtime events, process and network
|
||||
signals, container behavior, privileged action monitoring, and incident
|
||||
response triggers.
|
||||
|
||||
## Forces
|
||||
|
||||
- Runtime signals can be noisy.
|
||||
- Detection must distinguish platform, tenant, human, service, and
|
||||
agent activity.
|
||||
- Alerts need enough context for response.
|
||||
- Detection coverage should feed audit and incident workflows.
|
||||
|
||||
## Solution
|
||||
|
||||
Collect runtime process, network, Kubernetes, and workload signals,
|
||||
classify them using a security event taxonomy, and route actionable
|
||||
alerts into incident response and audit workflows.
|
||||
|
||||
## Verification
|
||||
|
||||
- Runtime detections include actor, workload, namespace, tenant, and
|
||||
severity where available.
|
||||
- Known suspicious events trigger alerts or findings.
|
||||
- False positives are tuned without disabling critical coverage.
|
||||
- Detection events link to incident runbooks.
|
||||
|
||||
## Related Patterns
|
||||
|
||||
- Security Event Taxonomy.
|
||||
- Central Audit Ledger.
|
||||
- Incident Runbook Library.
|
||||
- Kill Switch / Tenant Freeze.
|
||||
@@ -0,0 +1,43 @@
|
||||
# Pattern: SBOM-per-Release
|
||||
|
||||
Status: seed
|
||||
Readiness target: RL3 production
|
||||
Primary owners: artifact-store, product repos
|
||||
Genesis family: Supply chain
|
||||
|
||||
## Problem
|
||||
|
||||
Teams cannot assess exposure, license risk, or incident impact if
|
||||
release components are not recorded.
|
||||
|
||||
## Context
|
||||
|
||||
Use this pattern for containers, packages, product releases, platform
|
||||
images, and deployable artifacts.
|
||||
|
||||
## Forces
|
||||
|
||||
- SBOM generation should be automated.
|
||||
- SBOMs need to stay attached to release artifacts.
|
||||
- Consumers need stable formats and storage.
|
||||
- Vulnerability triage needs component evidence.
|
||||
|
||||
## Solution
|
||||
|
||||
Generate a software bill of materials for each release artifact and
|
||||
store it with artifact metadata, provenance, signature, and deployment
|
||||
records.
|
||||
|
||||
## Verification
|
||||
|
||||
- Each production release has an SBOM.
|
||||
- SBOMs are stored with immutable artifact identity.
|
||||
- Vulnerability scans can reference SBOM components.
|
||||
- Release promotion checks require SBOM presence.
|
||||
|
||||
## Related Patterns
|
||||
|
||||
- Supply-Chain Provenance.
|
||||
- SLSA Build Provenance.
|
||||
- Signed Container Images.
|
||||
- Protected Main Branch.
|
||||
@@ -0,0 +1,43 @@
|
||||
# Pattern: Schema-First API Security
|
||||
|
||||
Status: seed
|
||||
Readiness target: RL3 production
|
||||
Primary owners: product repos, NetKingdom
|
||||
Genesis family: Application/API security
|
||||
|
||||
## Problem
|
||||
|
||||
APIs become difficult to validate, test, and protect when the request
|
||||
and response contract is implicit.
|
||||
|
||||
## Context
|
||||
|
||||
Use this pattern for OpenAPI, async APIs, event schemas, public APIs,
|
||||
tenant APIs, and internal service contracts.
|
||||
|
||||
## Forces
|
||||
|
||||
- Schemas can drive validation and tests.
|
||||
- Schemas alone do not prove authorization.
|
||||
- Backward compatibility must be managed.
|
||||
- Sensitive fields need explicit treatment.
|
||||
|
||||
## Solution
|
||||
|
||||
Define API schemas before or alongside implementation and use them to
|
||||
drive validation, compatibility checks, security tests, documentation,
|
||||
and gateway/application enforcement.
|
||||
|
||||
## Verification
|
||||
|
||||
- Requests and responses are validated against versioned schemas.
|
||||
- Sensitive fields are marked and tested.
|
||||
- Breaking changes are detected before release.
|
||||
- Authorization tests cover resources described by the schema.
|
||||
|
||||
## Related Patterns
|
||||
|
||||
- API Gateway as Security Boundary.
|
||||
- Object-Level Authorization Check.
|
||||
- Backend-for-Frontend.
|
||||
- Secure File Upload Pipeline.
|
||||
@@ -0,0 +1,44 @@
|
||||
# Pattern: Sealed Secret / Encrypted Git Secret
|
||||
|
||||
Status: seed
|
||||
Readiness target: RL2 private beta
|
||||
Primary owners: NetKingdom, Railiance platform
|
||||
Genesis family: Secrets and cryptography
|
||||
|
||||
## Problem
|
||||
|
||||
GitOps workflows need reproducible secret references, but plaintext
|
||||
secrets in Git are unacceptable.
|
||||
|
||||
## Context
|
||||
|
||||
Use this pattern for bootstrap secrets, local development secrets,
|
||||
environment configuration, and recovery material that must be carried in
|
||||
versioned operational bundles.
|
||||
|
||||
## Forces
|
||||
|
||||
- Git gives review and history.
|
||||
- Secret plaintext must not be stored in Git.
|
||||
- Encryption recipients and rotation need ownership.
|
||||
- Bootstrap secrets should transition to runtime secret authority.
|
||||
|
||||
## Solution
|
||||
|
||||
Store only encrypted secret payloads or sealed secret manifests in Git,
|
||||
with documented recipients, rotation, and bootstrap scope. Move runtime
|
||||
secret issuance to OpenBao where possible.
|
||||
|
||||
## Verification
|
||||
|
||||
- Plaintext secret scans pass.
|
||||
- Encryption recipients and owners are documented.
|
||||
- Decryption is limited to approved bootstrap or recovery contexts.
|
||||
- Runtime workloads do not depend on bootstrap root material.
|
||||
|
||||
## Related Patterns
|
||||
|
||||
- Secret Zero Avoidance.
|
||||
- GitOps with Guardrails.
|
||||
- External Secrets Operator.
|
||||
- Break-glass Access.
|
||||
@@ -0,0 +1,81 @@
|
||||
# Pattern: Secret Zero Avoidance
|
||||
|
||||
Status: reviewed
|
||||
Readiness target: RL3 production
|
||||
Primary owners: NetKingdom, Railiance platform
|
||||
|
||||
## Problem
|
||||
|
||||
A secret manager cannot safely improve the platform if its bootstrap
|
||||
material becomes a larger unmanaged secret than the credentials it is
|
||||
meant to protect.
|
||||
|
||||
## Context
|
||||
|
||||
Use this pattern when introducing OpenBao, encrypted Git secrets,
|
||||
emergency bundles, age/SOPS bootstrap material, or recovery ceremonies.
|
||||
|
||||
## Forces
|
||||
|
||||
- The platform needs an initial trust anchor.
|
||||
- Operators need recoverability, but ordinary workloads must never use
|
||||
platform-root material.
|
||||
- GitOps needs reproducible configuration, but secret plaintext does not
|
||||
belong in repositories.
|
||||
- Emergency access must exist without becoming normal operating access.
|
||||
|
||||
## Solution
|
||||
|
||||
Separate bootstrap trust from runtime secret authority. Use encrypted
|
||||
bootstrap material only for installation and recovery, then transfer
|
||||
ordinary secret issuance, rotation, audit, and lease tracking to
|
||||
OpenBao.
|
||||
|
||||
## Implementation Sketch
|
||||
|
||||
1. Store bootstrap and recovery material in encrypted form with explicit
|
||||
custody.
|
||||
2. Require a documented ceremony for unseal, restore, and emergency
|
||||
recovery.
|
||||
3. Move runtime workloads to OpenBao-issued or brokered secrets.
|
||||
4. Keep root/recovery material out of normal deployment paths.
|
||||
5. Record every break-glass or bootstrap use as a review event.
|
||||
|
||||
## Failure Modes
|
||||
|
||||
| Failure | Mitigation |
|
||||
| --- | --- |
|
||||
| Bootstrap root token reused by workloads | prohibit root material in runtime manifests |
|
||||
| Encrypted secret repository becomes undocumented | maintain owner, recipient, and rotation inventory |
|
||||
| Recovery ceremony untested | run restore and unseal drills |
|
||||
| Emergency bundle becomes daily admin path | require post-event review and replacement |
|
||||
|
||||
## Related Capabilities
|
||||
|
||||
- Secrets, keys, and credentials.
|
||||
- Security governance and production readiness.
|
||||
- Incident response and recovery.
|
||||
- Observability, detection, and audit.
|
||||
|
||||
## Maturity
|
||||
|
||||
Reviewed. NetKingdom credential and OpenBao architecture already anchor
|
||||
the pattern; operational drills are still needed before canonical status.
|
||||
|
||||
## Verification
|
||||
|
||||
- Runtime workloads do not reference bootstrap root material.
|
||||
- OpenBao audit is enabled before production use.
|
||||
- Recovery and unseal steps are documented and tested.
|
||||
- Emergency access events produce reviewable records.
|
||||
|
||||
## Research Basis
|
||||
|
||||
Seeded by encrypted Git secret, central secrets management, break-glass,
|
||||
and incident recovery requirements in the initial exploration.
|
||||
|
||||
## References
|
||||
|
||||
- NetKingdom credential-management standard.
|
||||
- NetKingdom recursive platform identity/security architecture.
|
||||
- Railiance OpenBao platform secrets service.
|
||||
@@ -0,0 +1,44 @@
|
||||
# Pattern: Secure Cluster Baseline
|
||||
|
||||
Status: seed
|
||||
Readiness target: RL3 production
|
||||
Primary owners: Railiance platform
|
||||
Genesis family: Kubernetes and platform
|
||||
|
||||
## Problem
|
||||
|
||||
Production Kubernetes clusters inherit unsafe defaults unless baseline
|
||||
hardening is explicit, versioned, and verified.
|
||||
|
||||
## Context
|
||||
|
||||
Use this pattern for every cluster class that hosts platform services,
|
||||
tenant workloads, identity services, secret managers, or production
|
||||
applications.
|
||||
|
||||
## Forces
|
||||
|
||||
- Kubernetes exposes many powerful APIs by default.
|
||||
- Platform add-ons need privileged access but must be bounded.
|
||||
- Baseline controls must survive upgrades.
|
||||
- Product teams need predictable guardrails.
|
||||
|
||||
## Solution
|
||||
|
||||
Define a secure cluster baseline covering API server settings, RBAC,
|
||||
node hardening, pod security, admission, network policy, secret
|
||||
handling, audit, backups, and upgrade posture.
|
||||
|
||||
## Verification
|
||||
|
||||
- Cluster baseline checks run before production admission.
|
||||
- Privileged Kubernetes APIs are limited and reviewed.
|
||||
- Audit logging, backup, and restore paths are enabled.
|
||||
- Upgrade tests verify baseline controls remain active.
|
||||
|
||||
## Related Patterns
|
||||
|
||||
- Pod Security Baseline/Restricted.
|
||||
- Policy-as-Code Admission Control.
|
||||
- Network Default Deny.
|
||||
- Runtime Threat Detection.
|
||||
@@ -0,0 +1,43 @@
|
||||
# Pattern: Secure File Upload Pipeline
|
||||
|
||||
Status: seed
|
||||
Readiness target: RL3 production
|
||||
Primary owners: product repos, artifact-store, NetKingdom
|
||||
Genesis family: Application/API security
|
||||
|
||||
## Problem
|
||||
|
||||
User-supplied files can carry malware, parser attacks, data leakage, and
|
||||
unsafe object-storage exposure.
|
||||
|
||||
## Context
|
||||
|
||||
Use this pattern for tenant file uploads, artifact ingestion, document
|
||||
processing, media upload, and user-controlled object storage paths.
|
||||
|
||||
## Forces
|
||||
|
||||
- Users need convenient uploads.
|
||||
- Uploaded files should not be trusted until processed.
|
||||
- Scanning, classification, and transformation may be asynchronous.
|
||||
- Object access must remain tenant and authorization scoped.
|
||||
|
||||
## Solution
|
||||
|
||||
Route uploads through a controlled pipeline: accept to quarantine,
|
||||
record metadata, scan/classify, transform if needed, promote to trusted
|
||||
storage, and serve through authorized access paths.
|
||||
|
||||
## Verification
|
||||
|
||||
- Raw uploads land in quarantine or untrusted storage.
|
||||
- Scanning and classification results are recorded before promotion.
|
||||
- Access to uploaded objects uses tenant and object-level authorization.
|
||||
- Malicious or unsupported files fail safely.
|
||||
|
||||
## Related Patterns
|
||||
|
||||
- Object-Level Authorization Check.
|
||||
- STS Credential Vending.
|
||||
- Tenant Data Partitioning.
|
||||
- Central Audit Ledger.
|
||||
@@ -0,0 +1,43 @@
|
||||
# Pattern: Security Event Taxonomy
|
||||
|
||||
Status: seed
|
||||
Readiness target: RL3 production
|
||||
Primary owners: NetKingdom, Railiance platform
|
||||
Genesis family: Detection and response
|
||||
|
||||
## Problem
|
||||
|
||||
Logs become noisy and hard to correlate when security-relevant events
|
||||
do not share names, fields, severities, and actor/resource semantics.
|
||||
|
||||
## Context
|
||||
|
||||
Use this pattern for identity, authorization, OpenBao, Kubernetes,
|
||||
artifact-store, ops access, workload events, and incident response.
|
||||
|
||||
## Forces
|
||||
|
||||
- Different systems emit different event shapes.
|
||||
- Tenant-visible audit requires careful projection.
|
||||
- Agents and humans need separate attribution.
|
||||
- Detection and response need severity and category consistency.
|
||||
|
||||
## Solution
|
||||
|
||||
Define a shared taxonomy for security events with event class, actor,
|
||||
tenant, resource, action, outcome, severity, source, correlation id, and
|
||||
visibility rules.
|
||||
|
||||
## Verification
|
||||
|
||||
- Critical systems emit events matching required fields.
|
||||
- Event classes map to detection and response workflows.
|
||||
- Tenant-visible fields are explicitly marked.
|
||||
- Correlation ids link identity, policy, secret, and workload events.
|
||||
|
||||
## Related Patterns
|
||||
|
||||
- Central Audit Ledger.
|
||||
- Tenant Audit Log View.
|
||||
- Runtime Threat Detection.
|
||||
- Incident Runbook Library.
|
||||
@@ -0,0 +1,45 @@
|
||||
# Pattern: Shared Control Plane, Isolated Data Plane
|
||||
|
||||
Status: seed
|
||||
Readiness target: RL3 production
|
||||
Primary owners: NetKingdom, Railiance platform
|
||||
Genesis family: Tenant isolation
|
||||
|
||||
## Problem
|
||||
|
||||
Platforms often need centralized management while tenant workloads and
|
||||
data require stronger separation than the control plane itself.
|
||||
|
||||
## Context
|
||||
|
||||
Use this pattern for SaaS management planes, tenant runtime clusters,
|
||||
dedicated object storage, per-tenant databases, or cell-based data
|
||||
planes.
|
||||
|
||||
## Forces
|
||||
|
||||
- Shared control planes reduce management overhead.
|
||||
- Tenant data planes need stronger isolation and blast-radius control.
|
||||
- Control-plane actions are high impact and must be tenant scoped.
|
||||
- Audit must explain who affected which tenant data plane.
|
||||
|
||||
## Solution
|
||||
|
||||
Keep management APIs and policy orchestration in a shared control plane,
|
||||
but isolate tenant runtime and data paths. Every control action carries
|
||||
tenant, target plane, actor, policy, and audit context.
|
||||
|
||||
## Verification
|
||||
|
||||
- Tenant users cannot mutate global control-plane state unless
|
||||
delegated.
|
||||
- Data-plane credentials and network paths are tenant scoped.
|
||||
- Control-plane actions produce tenant and target-plane audit events.
|
||||
- A compromised tenant data plane cannot directly control another.
|
||||
|
||||
## Related Patterns
|
||||
|
||||
- Tenant Isolation.
|
||||
- Cluster-per-Tenant.
|
||||
- Cell-based Architecture.
|
||||
- Tenant Data Partitioning.
|
||||
@@ -0,0 +1,43 @@
|
||||
# Pattern: Short-lived Credentials
|
||||
|
||||
Status: reviewed
|
||||
Readiness target: RL3 production
|
||||
Primary owners: NetKingdom, Railiance platform, flex-auth
|
||||
Genesis family: Secrets and cryptography
|
||||
|
||||
## Problem
|
||||
|
||||
Static credentials remain useful after compromise and are difficult to
|
||||
inventory, rotate, and scope.
|
||||
|
||||
## Context
|
||||
|
||||
Use this pattern for object storage, SSH, API tokens, database access,
|
||||
workload secrets, and operator elevation.
|
||||
|
||||
## Forces
|
||||
|
||||
- Consumers need stable integration contracts.
|
||||
- Backends differ in session or lease support.
|
||||
- Refresh and expiration behavior must be tested.
|
||||
- Audit must link issuance to actor, tenant, resource, and purpose.
|
||||
|
||||
## Solution
|
||||
|
||||
Prefer credentials with explicit TTL, scope, lease metadata, and
|
||||
revocation path. Normalize issuance through identity, authorization,
|
||||
and brokered secret authority.
|
||||
|
||||
## Verification
|
||||
|
||||
- Credentials include scope, expiry, and owner metadata.
|
||||
- Consumers refresh before expiration.
|
||||
- Expired credentials are rejected by backends.
|
||||
- Issuance and revocation are auditable.
|
||||
|
||||
## Related Patterns
|
||||
|
||||
- STS Credential Vending.
|
||||
- Dynamic Secrets.
|
||||
- Short-Lived SSH Certificates.
|
||||
- Time-boxed Privilege Elevation.
|
||||
@@ -0,0 +1,76 @@
|
||||
# Pattern: Short-Lived SSH Certificates
|
||||
|
||||
Status: draft
|
||||
Readiness target: RL3 production
|
||||
Primary owners: ops-warden, ops-bridge, NetKingdom
|
||||
|
||||
## Problem
|
||||
|
||||
Long-lived SSH keys make operator and agent access hard to revoke,
|
||||
audit, and scope.
|
||||
|
||||
## Context
|
||||
|
||||
Use this pattern for administrative shell access, tunnel access,
|
||||
automation access, and agent access to infrastructure where SSH remains
|
||||
necessary.
|
||||
|
||||
## Forces
|
||||
|
||||
- Operators need reliable emergency and maintenance access.
|
||||
- Access must be time-boxed, attributable, and least privilege.
|
||||
- Agents need identities separate from their human sponsors.
|
||||
- SSH remains useful but should not bypass platform authorization.
|
||||
|
||||
## Solution
|
||||
|
||||
Issue short-lived SSH certificates from a controlled authority after
|
||||
identity and policy checks. Consumers use certificates through
|
||||
ops-bridge or equivalent access paths that record actor, purpose,
|
||||
target, TTL, and correlation ids.
|
||||
|
||||
## Implementation Sketch
|
||||
|
||||
1. Authenticate the human, automation, or agent identity.
|
||||
2. Authorize target, role, command class, and TTL.
|
||||
3. Have ops-warden issue an SSH certificate with principal and expiry.
|
||||
4. Route access through ops-bridge where practical for audit capture.
|
||||
5. Revoke or let certificates expire quickly after use.
|
||||
|
||||
## Failure Modes
|
||||
|
||||
| Failure | Mitigation |
|
||||
| --- | --- |
|
||||
| Static SSH key fallback persists | inventory and remove unmanaged keys |
|
||||
| Certificates have broad principals | bind principals to role and target class |
|
||||
| Agent access borrows human identity | issue explicit agent certificates |
|
||||
| Audit path bypassed | restrict direct network/admin paths |
|
||||
|
||||
## Related Capabilities
|
||||
|
||||
- Privileged access management.
|
||||
- Agent access control.
|
||||
- Incident response and recovery.
|
||||
- Observability, detection, and audit.
|
||||
|
||||
## Maturity
|
||||
|
||||
Draft. Pattern ownership is clear, but implementation details live in
|
||||
the ops repos and need verification fixtures.
|
||||
|
||||
## Verification
|
||||
|
||||
- Certificates expire quickly and cannot be renewed silently.
|
||||
- Certificate principal, target, actor, and reason are logged.
|
||||
- Static key exceptions are inventoried and reviewed.
|
||||
- Agent identities are distinguishable from human identities.
|
||||
|
||||
## Research Basis
|
||||
|
||||
Seeded by privileged access management, time-boxed privilege elevation,
|
||||
human/agent identity split, and break-glass access patterns.
|
||||
|
||||
## References
|
||||
|
||||
- Initial exploration: Authorization and access control.
|
||||
- NetKingdom ownership map: ops-warden and ops-bridge.
|
||||
@@ -0,0 +1,43 @@
|
||||
# Pattern: Signed Container Images
|
||||
|
||||
Status: seed
|
||||
Readiness target: RL3 production
|
||||
Primary owners: artifact-store, Railiance platform, product repos
|
||||
Genesis family: Supply chain
|
||||
|
||||
## Problem
|
||||
|
||||
Container images can be replaced, confused, or deployed from untrusted
|
||||
origins unless image identity is cryptographically verifiable.
|
||||
|
||||
## Context
|
||||
|
||||
Use this pattern for production container images, platform controllers,
|
||||
tenant workloads, and deployment admission.
|
||||
|
||||
## Forces
|
||||
|
||||
- Tags are mutable unless controlled.
|
||||
- Signatures need trusted keys or identities.
|
||||
- Admission must verify the image that actually runs.
|
||||
- Rollbacks need signed artifacts too.
|
||||
|
||||
## Solution
|
||||
|
||||
Sign container image digests after trusted builds and require production
|
||||
deployments to reference images whose signatures and provenance satisfy
|
||||
policy.
|
||||
|
||||
## Verification
|
||||
|
||||
- Images are signed by trusted build or release identities.
|
||||
- Admission rejects unsigned or untrusted images.
|
||||
- Deployments pin or verify immutable digests.
|
||||
- Signature rotation and key compromise processes exist.
|
||||
|
||||
## Related Patterns
|
||||
|
||||
- Signed Image Admission.
|
||||
- SLSA Build Provenance.
|
||||
- SBOM-per-Release.
|
||||
- Quarantined Build Runner.
|
||||
@@ -0,0 +1,43 @@
|
||||
# Pattern: Signed Image Admission
|
||||
|
||||
Status: seed
|
||||
Readiness target: RL3 production
|
||||
Primary owners: Railiance platform, artifact-store, product repos
|
||||
Genesis family: Kubernetes and platform
|
||||
|
||||
## Problem
|
||||
|
||||
Clusters cannot trust that an image came from reviewed source or an
|
||||
approved build unless admission verifies signature and provenance.
|
||||
|
||||
## Context
|
||||
|
||||
Use this pattern for Kubernetes admission, container registries,
|
||||
artifact-store, release promotion, and supply-chain evidence.
|
||||
|
||||
## Forces
|
||||
|
||||
- Developers need fast image builds.
|
||||
- Production needs evidence of review and provenance.
|
||||
- Not every image source is equally trusted.
|
||||
- Emergency rollback must still use trusted artifacts.
|
||||
|
||||
## Solution
|
||||
|
||||
Require production workloads to use signed images from approved
|
||||
registries. Admission verifies signature, digest, provenance, and policy
|
||||
before the workload runs.
|
||||
|
||||
## Verification
|
||||
|
||||
- Unsigned images are rejected in production namespaces.
|
||||
- Admission pins by digest or verifies immutable references.
|
||||
- Signatures and provenance link to reviewed source and build identity.
|
||||
- Emergency images follow the same trust policy.
|
||||
|
||||
## Related Patterns
|
||||
|
||||
- Supply-Chain Provenance.
|
||||
- Signed Container Images.
|
||||
- SLSA Build Provenance.
|
||||
- Policy-as-Code Admission Control.
|
||||
@@ -0,0 +1,43 @@
|
||||
# Pattern: SLSA Build Provenance
|
||||
|
||||
Status: seed
|
||||
Readiness target: RL3 production
|
||||
Primary owners: artifact-store, product repos, Railiance platform
|
||||
Genesis family: Supply chain
|
||||
|
||||
## Problem
|
||||
|
||||
Production artifacts are hard to trust if the platform cannot prove
|
||||
which source, builder, dependencies, and process produced them.
|
||||
|
||||
## Context
|
||||
|
||||
Use this pattern for release pipelines, container builds, package
|
||||
publishing, artifact-store metadata, and deployment admission.
|
||||
|
||||
## Forces
|
||||
|
||||
- Provenance must be generated by a trustworthy build process.
|
||||
- Developers need usable build workflows.
|
||||
- Provenance must be verifiable after release.
|
||||
- Admission and incident response need artifact lineage.
|
||||
|
||||
## Solution
|
||||
|
||||
Emit SLSA-style provenance for production artifacts, linking artifact
|
||||
digest to source repository, commit, builder identity, workflow, inputs,
|
||||
and build parameters.
|
||||
|
||||
## Verification
|
||||
|
||||
- Production artifacts carry verifiable provenance.
|
||||
- Provenance links to protected source and trusted builder identity.
|
||||
- Admission or release promotion checks provenance policy.
|
||||
- Incident triage can trace an artifact back to source and build.
|
||||
|
||||
## Related Patterns
|
||||
|
||||
- Supply-Chain Provenance.
|
||||
- Protected Main Branch.
|
||||
- Quarantined Build Runner.
|
||||
- Signed Container Images.
|
||||
@@ -0,0 +1,117 @@
|
||||
# Pattern: STS Credential Vending
|
||||
|
||||
Status: reviewed
|
||||
Readiness target: RL3 production
|
||||
Primary owners: NetKingdom, flex-auth, Railiance platform
|
||||
|
||||
## Problem
|
||||
|
||||
Applications need object-storage access, but long-lived access keys in
|
||||
application pods, repositories, or tenant namespaces create a durable
|
||||
compromise path. Provider-specific bucket policy alone is not enough for
|
||||
NetKingdom because access decisions must include identity, tenant,
|
||||
resource, action, TTL, assurance, and audit context.
|
||||
|
||||
## Context
|
||||
|
||||
Use this pattern when a workload, service, agent, or human needs
|
||||
temporary access to S3-compatible object storage. The first target
|
||||
consumer is `artifact-store`, but the pattern is intended for any
|
||||
NetKingdom-enabled platform or tenant workload.
|
||||
|
||||
The pattern applies across AWS S3, Ceph RGW, MinIO/AIStor, Cloudflare R2,
|
||||
and OpenBao-assisted broker paths.
|
||||
|
||||
## Forces
|
||||
|
||||
- Provider-native STS gives strong backend expiration semantics, but
|
||||
providers differ in API shape and OIDC support.
|
||||
- Applications need a simple credential contract, but security decisions
|
||||
require rich context.
|
||||
- OpenBao can protect parent credentials and audit broker operations, but
|
||||
must not become the authorization policy engine.
|
||||
- Tenant administrators need self-service within tenant scope, but must
|
||||
not receive platform-root object-store or OpenBao authority.
|
||||
- Temporary credentials reduce blast radius, but consumers must refresh
|
||||
safely and support session tokens.
|
||||
|
||||
## Solution
|
||||
|
||||
Introduce a credential-vending service that accepts a NetKingdom IAM
|
||||
Profile token or workload identity, asks flex-auth for an authorization
|
||||
decision, and exchanges approved requests for provider-native temporary
|
||||
credentials or an OpenBao-assisted broker path.
|
||||
|
||||
The consumer receives normalized credentials:
|
||||
|
||||
```text
|
||||
access key id
|
||||
secret access key
|
||||
session token
|
||||
expiration
|
||||
scope metadata
|
||||
decision/audit correlation id
|
||||
```
|
||||
|
||||
## Implementation Sketch
|
||||
|
||||
1. Caller authenticates through key-cape or Keycloak.
|
||||
2. Credential-vending service validates issuer, audience, subject,
|
||||
tenant, expiration, and assurance evidence.
|
||||
3. Service builds a flex-auth request with protected-system id, bucket,
|
||||
prefix/object, actions, TTL, actor, tenant, and context.
|
||||
4. flex-auth evaluates policy, delegated to Topaz where appropriate.
|
||||
5. Deny returns a stable reason code and audit id.
|
||||
6. Allow invokes backend exchange:
|
||||
- AWS STS `AssumeRoleWithWebIdentity`;
|
||||
- Ceph RGW STS;
|
||||
- MinIO/AIStor STS;
|
||||
- Cloudflare R2 temporary credential API;
|
||||
- OpenBao-assisted broker path for protected parent material.
|
||||
7. Service records identity, policy, backend, lease, and audit metadata.
|
||||
8. Consumer refreshes before expiration.
|
||||
|
||||
## Failure Modes
|
||||
|
||||
| Failure | Mitigation |
|
||||
| --- | --- |
|
||||
| Consumer lacks `AWS_SESSION_TOKEN` support | keep static bridge only as transitional; add session token refs |
|
||||
| flex-auth unavailable | fail closed except documented emergency platform workflows |
|
||||
| OpenBao unavailable | fail if parent material or broker config is required |
|
||||
| Backend STS unavailable | return retryable backend error; do not fall back to root credentials |
|
||||
| Tenant mismatch | deny with stable reason code |
|
||||
| TTL too long | reduce to policy maximum or deny |
|
||||
| Audit sink unavailable | deny privileged/platform-scoped requests; buffer only if policy permits |
|
||||
|
||||
## Related Capabilities
|
||||
|
||||
- Object storage access.
|
||||
- Authorization and access control.
|
||||
- Secrets, keys, and credentials.
|
||||
- Tenant isolation.
|
||||
- Observability, detection, and audit.
|
||||
|
||||
## Maturity
|
||||
|
||||
Reviewed. The pattern has architecture and ADR coverage in NetKingdom.
|
||||
It should not be marked canonical until artifact-store temporary session
|
||||
token support and at least one backend exchange path are verified.
|
||||
|
||||
## Verification
|
||||
|
||||
- IAM Profile validation rejects wrong issuer or audience.
|
||||
- flex-auth decision includes tenant, protected system, bucket/prefix,
|
||||
action set, TTL, obligations, and deny reason.
|
||||
- Backend returns access key id, secret access key, session token, and
|
||||
expiration.
|
||||
- OpenBao audit record exists when parent material or broker config is
|
||||
accessed.
|
||||
- Consumer refreshes before expiration.
|
||||
- Deny paths emit stable reason codes.
|
||||
|
||||
## References
|
||||
|
||||
- NetKingdom `docs/object-storage-sts-credential-vending.md`.
|
||||
- NetKingdom `ADR-0008 - Object Storage STS Credential Vending Boundary`.
|
||||
- Railiance Platform `docs/openbao.md`.
|
||||
- Artifact-store `ARTIFACT-STORE-WP-0007`.
|
||||
@@ -0,0 +1,78 @@
|
||||
# Pattern: Supply-Chain Provenance
|
||||
|
||||
Status: seed
|
||||
Readiness target: RL3 production
|
||||
Primary owners: Railiance platform, artifact-store, product repos
|
||||
|
||||
## Problem
|
||||
|
||||
Production artifacts become hard to trust when source, dependencies,
|
||||
build runners, images, signatures, SBOMs, and deployment admission are
|
||||
not connected.
|
||||
|
||||
## Context
|
||||
|
||||
Use this pattern for container images, packages, release artifacts,
|
||||
SBOMs, dependency updates, GitHub/GitLab workflows, artifact-store, and
|
||||
Kubernetes admission.
|
||||
|
||||
## Forces
|
||||
|
||||
- Teams need fast dependency updates and builds.
|
||||
- Production needs evidence that artifacts came from reviewed source.
|
||||
- Build systems need secrets, but secret exposure in CI is high impact.
|
||||
- Admission should verify artifacts without blocking all development.
|
||||
|
||||
## Solution
|
||||
|
||||
Require production artifacts to carry review, dependency, build,
|
||||
signature, and provenance evidence. Admission and release workflows use
|
||||
that evidence to decide what can run or be promoted.
|
||||
|
||||
## Implementation Sketch
|
||||
|
||||
1. Protect main branches and release tags.
|
||||
2. Generate SBOMs per release.
|
||||
3. Sign container images and release artifacts.
|
||||
4. Emit SLSA-style build provenance from trusted runners.
|
||||
5. Keep build runners isolated and least privilege.
|
||||
6. Verify signatures and provenance before production admission.
|
||||
|
||||
## Failure Modes
|
||||
|
||||
| Failure | Mitigation |
|
||||
| --- | --- |
|
||||
| SBOM generated but not stored with releases | store SBOMs in artifact-store or release records |
|
||||
| Signatures exist but admission ignores them | enforce signed image admission |
|
||||
| CI runner has broad production secrets | quarantine runners and restrict secret access |
|
||||
| Dependency bot floods unreviewed changes | require tests and review gates |
|
||||
|
||||
## Related Capabilities
|
||||
|
||||
- Software supply chain security.
|
||||
- Platform and Kubernetes hardening.
|
||||
- Security governance and production readiness.
|
||||
- Observability, detection, and audit.
|
||||
|
||||
## Maturity
|
||||
|
||||
Seed. The pattern has strong external standards, but NetKingdom still
|
||||
needs concrete artifact-store and admission integration.
|
||||
|
||||
## Verification
|
||||
|
||||
- Releases include SBOM, signature, and provenance.
|
||||
- Admission rejects unsigned or untrusted production artifacts.
|
||||
- Build runner access to secrets is minimized.
|
||||
- Dependency updates are tested and reviewed.
|
||||
|
||||
## Research Basis
|
||||
|
||||
Seeded by protected main branch, dependency update bot, SBOM-per-release,
|
||||
SLSA build provenance, signed container images, and quarantined build
|
||||
runner patterns.
|
||||
|
||||
## References
|
||||
|
||||
- Initial exploration: Software supply chain security.
|
||||
- Initial exploration: Supply-chain patterns.
|
||||
@@ -0,0 +1,44 @@
|
||||
# Pattern: Tenant Audit Log View
|
||||
|
||||
Status: seed
|
||||
Readiness target: RL4 regulated production
|
||||
Primary owners: product repos, NetKingdom, Railiance platform
|
||||
Genesis family: Detection and response
|
||||
|
||||
## Problem
|
||||
|
||||
Enterprise tenants need visibility into relevant security events without
|
||||
being exposed to platform-only internals or other tenants' data.
|
||||
|
||||
## Context
|
||||
|
||||
Use this pattern for tenant admin portals, compliance exports, data
|
||||
access events, privileged tenant actions, and platform actions that
|
||||
affect a tenant.
|
||||
|
||||
## Forces
|
||||
|
||||
- Tenants need trust and accountability.
|
||||
- Platform logs may contain sensitive internal details.
|
||||
- Event redaction must preserve evidence value.
|
||||
- Tenant exports require retention and integrity rules.
|
||||
|
||||
## Solution
|
||||
|
||||
Project central audit events into tenant-scoped views with explicit
|
||||
visibility rules, redaction, retention, export controls, and access
|
||||
authorization.
|
||||
|
||||
## Verification
|
||||
|
||||
- Tenants can see their own relevant events only.
|
||||
- Platform-only fields are redacted or omitted.
|
||||
- Tenant audit access is itself audited.
|
||||
- Exports preserve integrity and retention rules.
|
||||
|
||||
## Related Patterns
|
||||
|
||||
- Central Audit Ledger.
|
||||
- Security Event Taxonomy.
|
||||
- Tenant Context Propagation.
|
||||
- Object-Level Authorization Check.
|
||||
@@ -0,0 +1,77 @@
|
||||
# Pattern: Tenant Context Propagation
|
||||
|
||||
Status: draft
|
||||
Readiness target: RL3 production
|
||||
Primary owners: NetKingdom, product repos, Railiance platform
|
||||
|
||||
## Problem
|
||||
|
||||
Tenant isolation breaks when request handlers, background jobs, events,
|
||||
storage access, or audit records lose the tenant context that justified
|
||||
the action.
|
||||
|
||||
## Context
|
||||
|
||||
Use this pattern for APIs, workers, queues, schedulers, event streams,
|
||||
data stores, object storage, audit events, and admin workflows.
|
||||
|
||||
## Forces
|
||||
|
||||
- Tenant context must be explicit and authenticated.
|
||||
- Some actions are platform-scoped and must not masquerade as tenant
|
||||
actions.
|
||||
- Background jobs often outlive the original request.
|
||||
- Logs and policy decisions need the same tenant correlation.
|
||||
|
||||
## Solution
|
||||
|
||||
Carry tenant context as a required field in trusted request, job, event,
|
||||
authorization, storage, and audit envelopes. Derive it from identity or
|
||||
controlled platform context, not from arbitrary user input.
|
||||
|
||||
## Implementation Sketch
|
||||
|
||||
1. Define tenant id and platform-scope semantics.
|
||||
2. Add tenant context to API, job, and event envelopes.
|
||||
3. Require flex-auth decisions to include tenant scope.
|
||||
4. Persist tenant context through queues and background workers.
|
||||
5. Include tenant id in audit and detection events.
|
||||
6. Reject ambiguous or conflicting tenant context.
|
||||
|
||||
## Failure Modes
|
||||
|
||||
| Failure | Mitigation |
|
||||
| --- | --- |
|
||||
| Tenant id is passed as untrusted parameter | derive from trusted identity/session claims |
|
||||
| Worker jobs omit tenant id | require typed job envelopes and tests |
|
||||
| Platform job uses tenant scope accidentally | distinguish platform-scope explicitly |
|
||||
| Audit records miss tenant | make tenant field required for tenant actions |
|
||||
|
||||
## Related Capabilities
|
||||
|
||||
- Tenant isolation.
|
||||
- Authorization and access control.
|
||||
- Application and API security.
|
||||
- Observability, detection, and audit.
|
||||
|
||||
## Maturity
|
||||
|
||||
Draft. This is foundational for multi-tenant correctness and should be
|
||||
promoted with product conformance tests.
|
||||
|
||||
## Verification
|
||||
|
||||
- Request, job, event, policy, and audit envelopes include tenant scope.
|
||||
- Ambiguous tenant context fails closed.
|
||||
- Platform-scope operations are explicitly marked and reviewed.
|
||||
- Cross-tenant propagation tests fail for APIs and workers.
|
||||
|
||||
## Research Basis
|
||||
|
||||
Seeded by tenant context propagation, tenant identity boundary,
|
||||
tenant-scoped authorization, and tenant data partitioning.
|
||||
|
||||
## References
|
||||
|
||||
- Initial exploration: Tenant isolation patterns.
|
||||
- Initial exploration: Application and API security.
|
||||
@@ -0,0 +1,43 @@
|
||||
# Pattern: Tenant Data Partitioning
|
||||
|
||||
Status: seed
|
||||
Readiness target: RL3 production
|
||||
Primary owners: product repos, NetKingdom
|
||||
Genesis family: Tenant isolation
|
||||
|
||||
## Problem
|
||||
|
||||
Tenant data can leak when storage, query, object, or cache access does
|
||||
not enforce tenant partition boundaries.
|
||||
|
||||
## Context
|
||||
|
||||
Use this pattern for shared databases, object storage, search indexes,
|
||||
caches, queues, analytics stores, and backup/export paths.
|
||||
|
||||
## Forces
|
||||
|
||||
- Shared data stores improve efficiency.
|
||||
- Every data access must include trusted tenant scope.
|
||||
- Query bugs can bypass application-level checks.
|
||||
- Backups and exports need the same tenant boundary as live systems.
|
||||
|
||||
## Solution
|
||||
|
||||
Partition data by tenant at the storage or query layer and require
|
||||
tenant-scoped authorization before access. Use schema, prefix, row-level
|
||||
security, bucket/prefix policy, or dedicated stores according to risk.
|
||||
|
||||
## Verification
|
||||
|
||||
- Cross-tenant query and object access tests fail.
|
||||
- Background jobs and exports carry tenant context.
|
||||
- Backups, search, and caches preserve tenant partitioning.
|
||||
- Audit records identify tenant, object, and actor.
|
||||
|
||||
## Related Patterns
|
||||
|
||||
- Tenant Context Propagation.
|
||||
- Object-Level Authorization Check.
|
||||
- Key-per-Tenant.
|
||||
- STS Credential Vending.
|
||||
@@ -0,0 +1,81 @@
|
||||
# Pattern: Tenant Isolation
|
||||
|
||||
Status: draft
|
||||
Readiness target: RL3 production
|
||||
Primary owners: NetKingdom, Railiance platform, product repos
|
||||
|
||||
## Problem
|
||||
|
||||
Multi-tenant systems fail dangerously when tenant identity, runtime,
|
||||
data, control-plane authority, or background jobs can cross boundaries
|
||||
implicitly.
|
||||
|
||||
## Context
|
||||
|
||||
Use this pattern for SaaS products, shared clusters, shared databases,
|
||||
object storage, platform services, admin tools, and asynchronous jobs.
|
||||
|
||||
## Forces
|
||||
|
||||
- Shared infrastructure improves efficiency.
|
||||
- Tenants need strong data and authorization boundaries.
|
||||
- Isolation may be implemented at namespace, cluster, cell, database,
|
||||
key, policy, or API layers.
|
||||
- Product teams need a clear contract for carrying tenant context.
|
||||
|
||||
## Solution
|
||||
|
||||
Make tenant context an explicit security boundary across identity,
|
||||
authorization, runtime, data, audit, and operations. Choose isolation
|
||||
strength per risk: namespace, cluster, cell, data partition, or isolated
|
||||
data plane.
|
||||
|
||||
## Implementation Sketch
|
||||
|
||||
1. Define tenant id format and trust source.
|
||||
2. Require tenant context in request and job envelopes.
|
||||
3. Enforce tenant scope in flex-auth decisions.
|
||||
4. Partition data and object storage by tenant.
|
||||
5. Apply runtime and network boundaries for tenant workloads.
|
||||
6. Record tenant id in audit and detection events.
|
||||
|
||||
## Failure Modes
|
||||
|
||||
| Failure | Mitigation |
|
||||
| --- | --- |
|
||||
| Tenant id accepted from untrusted input | derive from trusted identity/session claims |
|
||||
| Background jobs lose tenant context | require job envelope tenant binding |
|
||||
| Shared database queries miss tenant filter | add query guards and tests |
|
||||
| Control plane can mutate tenant resources globally | add guardrails and review flows |
|
||||
|
||||
## Related Capabilities
|
||||
|
||||
- Tenant isolation.
|
||||
- Authorization and access control.
|
||||
- Data protection and privacy.
|
||||
- Observability, detection, and audit.
|
||||
|
||||
## Maturity
|
||||
|
||||
Draft. The capability is central and well described; individual products
|
||||
need concrete verification patterns.
|
||||
|
||||
## Verification
|
||||
|
||||
- Cross-tenant access tests fail for APIs, jobs, storage, and admin
|
||||
paths.
|
||||
- Tenant id is present in identity, authorization, and audit records.
|
||||
- Data access includes tenant partition enforcement.
|
||||
- Control-plane operations are tenant scoped unless explicitly platform
|
||||
scoped.
|
||||
|
||||
## Research Basis
|
||||
|
||||
Seeded by tenant identity boundary, namespace-per-tenant,
|
||||
cluster-per-tenant, cell-based architecture, isolated data plane,
|
||||
tenant context propagation, and tenant data partitioning.
|
||||
|
||||
## References
|
||||
|
||||
- Initial exploration: Tenant isolation capability group.
|
||||
- Initial exploration: Tenant isolation patterns.
|
||||
@@ -0,0 +1,45 @@
|
||||
# Pattern: Tenant Membership Boundary
|
||||
|
||||
Status: seed
|
||||
Readiness target: RL3 production
|
||||
Primary owners: NetKingdom, product repos
|
||||
Genesis family: Identity and access
|
||||
|
||||
## Problem
|
||||
|
||||
Multi-tenant systems become unsafe when global user identity is treated
|
||||
as proof of membership, authority, or role inside a tenant.
|
||||
|
||||
## Context
|
||||
|
||||
Use this pattern for invitations, groups, tenant admin roles, product
|
||||
accounts, background jobs, audit events, and tenant-scoped policy.
|
||||
|
||||
## Forces
|
||||
|
||||
- One human can belong to multiple tenants.
|
||||
- Tenant role assignment may be delegated to tenant administrators.
|
||||
- Platform roles must not leak into tenant roles.
|
||||
- Offboarding must revoke tenant membership without necessarily deleting
|
||||
global identity.
|
||||
|
||||
## Solution
|
||||
|
||||
Represent tenant membership as an explicit relationship separate from
|
||||
global identity. Every tenant-scoped decision uses trusted identity plus
|
||||
membership, role, tenant, and resource context.
|
||||
|
||||
## Verification
|
||||
|
||||
- Removing tenant membership blocks tenant access while preserving the
|
||||
global account where appropriate.
|
||||
- Cross-tenant membership tests fail closed.
|
||||
- Tenant admins can manage only delegated tenant-scoped membership.
|
||||
- Audit records include global identity and tenant membership context.
|
||||
|
||||
## Related Patterns
|
||||
|
||||
- Tenant Context Propagation.
|
||||
- Role Composition.
|
||||
- Delegated Authorization.
|
||||
- Tenant Isolation.
|
||||
@@ -0,0 +1,44 @@
|
||||
# Pattern: Time-boxed Privilege Elevation
|
||||
|
||||
Status: seed
|
||||
Readiness target: RL3 production
|
||||
Primary owners: NetKingdom, ops-warden, flex-auth
|
||||
Genesis family: Identity and access
|
||||
|
||||
## Problem
|
||||
|
||||
Permanent privileged access increases blast radius and makes it hard to
|
||||
distinguish ordinary access from exceptional authority.
|
||||
|
||||
## Context
|
||||
|
||||
Use this pattern for operator access, tenant admin elevation, emergency
|
||||
maintenance, agent tasks, production data access, and SSH certificate
|
||||
issuance.
|
||||
|
||||
## Forces
|
||||
|
||||
- Operators need enough authority to fix incidents.
|
||||
- Privilege should expire automatically.
|
||||
- Elevation should include reason, scope, approval, and audit.
|
||||
- Break-glass must remain separate from ordinary elevation.
|
||||
|
||||
## Solution
|
||||
|
||||
Grant privileged roles or credentials only for a bounded purpose, scope,
|
||||
and TTL. The elevation request records actor, tenant, resource, reason,
|
||||
approval, assurance, and expiration.
|
||||
|
||||
## Verification
|
||||
|
||||
- Elevated access expires without manual cleanup.
|
||||
- The platform records who elevated, why, for what, and until when.
|
||||
- Expired elevation cannot be reused by agents or background sessions.
|
||||
- Emergency break-glass paths are distinguishable from normal elevation.
|
||||
|
||||
## Related Patterns
|
||||
|
||||
- Short-Lived SSH Certificates.
|
||||
- Short-lived Credentials.
|
||||
- Break-glass Access.
|
||||
- Central Audit Ledger.
|
||||
@@ -0,0 +1,45 @@
|
||||
# Pattern: Token Revocation Sweep
|
||||
|
||||
Status: seed
|
||||
Readiness target: RL3 production
|
||||
Primary owners: NetKingdom, key-cape, flex-auth
|
||||
Genesis family: Detection and response
|
||||
|
||||
## Problem
|
||||
|
||||
Credential compromise requires quickly invalidating related tokens,
|
||||
sessions, keys, leases, and grants across multiple systems.
|
||||
|
||||
## Context
|
||||
|
||||
Use this pattern for user compromise, agent compromise, tenant incident,
|
||||
OpenBao lease revocation, object-storage session exposure, and SSH
|
||||
certificate containment.
|
||||
|
||||
## Forces
|
||||
|
||||
- Tokens may be issued by different systems.
|
||||
- Some credentials expire naturally but still need immediate revocation.
|
||||
- Revocation must target scope without disabling unrelated tenants.
|
||||
- Audit and evidence must survive the sweep.
|
||||
|
||||
## Solution
|
||||
|
||||
Define revocation sweep procedures that identify affected actor, tenant,
|
||||
credential class, session, lease, key, and token families, then revoke or
|
||||
expire them through owning systems.
|
||||
|
||||
## Verification
|
||||
|
||||
- Sweep inputs can target actor, tenant, session, token class, and time
|
||||
window.
|
||||
- Revoked credentials fail at enforcement points.
|
||||
- Sweep actions are logged with reason and operator.
|
||||
- Follow-up rotation and user communication are tracked.
|
||||
|
||||
## Related Patterns
|
||||
|
||||
- Short-lived Credentials.
|
||||
- Dynamic Secrets.
|
||||
- STS Credential Vending.
|
||||
- Incident Runbook Library.
|
||||
@@ -0,0 +1,87 @@
|
||||
# Pattern: Workload Identity
|
||||
|
||||
Status: draft
|
||||
Readiness target: RL3 production
|
||||
Primary owners: Railiance platform, NetKingdom
|
||||
|
||||
## Problem
|
||||
|
||||
Workloads need to authenticate to platform services without inheriting
|
||||
human credentials, static shared secrets, or tenant-ambiguous service
|
||||
accounts.
|
||||
|
||||
## Context
|
||||
|
||||
Use this pattern for Kubernetes workloads, platform services, agents,
|
||||
and background jobs that need access to OpenBao, object storage,
|
||||
databases, queues, or internal APIs.
|
||||
|
||||
## Forces
|
||||
|
||||
- Workloads need stable identity, but credentials should be short lived.
|
||||
- Kubernetes service accounts are useful local identity evidence, but
|
||||
consumers need a NetKingdom-level identity contract.
|
||||
- Tenant context must be explicit for multi-tenant workloads.
|
||||
- OpenBao can issue or broker secrets, but should trust verified
|
||||
workload identity rather than static bootstrap credentials.
|
||||
|
||||
## Solution
|
||||
|
||||
Bind runtime workload identity to the NetKingdom IAM Profile. Validate
|
||||
the Kubernetes service account, namespace, audience, issuer, tenant, and
|
||||
deployment context, then exchange that evidence for scoped credentials,
|
||||
tokens, or policy decisions.
|
||||
|
||||
## Implementation Sketch
|
||||
|
||||
1. Define workload identity subjects and tenant scope in IAM Profile
|
||||
claims.
|
||||
2. Use Kubernetes projected service account tokens or equivalent runtime
|
||||
attestation.
|
||||
3. Map service account, namespace, and deployment labels to protected
|
||||
systems and tenant scope.
|
||||
4. Let OpenBao Kubernetes auth or a credential broker validate runtime
|
||||
evidence.
|
||||
5. Issue scoped, short-lived credentials with audit correlation.
|
||||
6. Deny requests when workload identity and tenant context disagree.
|
||||
|
||||
## Failure Modes
|
||||
|
||||
| Failure | Mitigation |
|
||||
| --- | --- |
|
||||
| Shared namespace account reused across services | require workload-specific service accounts |
|
||||
| Tenant missing from identity evidence | fail closed and require explicit tenant binding |
|
||||
| Long-lived mounted credentials | use short TTLs and rotation |
|
||||
| OpenBao trusts weak Kubernetes metadata | validate issuer, audience, namespace, service account, and bound claims |
|
||||
|
||||
## Related Capabilities
|
||||
|
||||
- Identity and user management.
|
||||
- Secrets, keys, and credentials.
|
||||
- Tenant isolation.
|
||||
- Observability, detection, and audit.
|
||||
|
||||
## Maturity
|
||||
|
||||
Draft. The pattern is well aligned with OpenBao and IAM Profile goals,
|
||||
but it needs a concrete Railiance implementation path and verification
|
||||
fixture before graduation.
|
||||
|
||||
## Verification
|
||||
|
||||
- Workload tokens have expected issuer, audience, subject, and tenant.
|
||||
- OpenBao or broker policy rejects wrong namespace/service account
|
||||
combinations.
|
||||
- Credentials are short lived and auditable.
|
||||
- Tenant mismatch tests fail closed.
|
||||
|
||||
## Research Basis
|
||||
|
||||
Seeded by the initial catalogue entries for service identities, workload
|
||||
secret injection, tenant context propagation, and external secrets.
|
||||
|
||||
## References
|
||||
|
||||
- Initial exploration: Identity and user management.
|
||||
- Initial exploration: Secrets and cryptography patterns.
|
||||
- Railiance OpenBao platform secrets service.
|
||||
@@ -0,0 +1,126 @@
|
||||
# Security Architecture Pattern Catalog
|
||||
|
||||
Status: completed genesis pattern catalog for NK-WP-0010
|
||||
Owner: NetKingdom architecture, maintained in infospace-bench
|
||||
|
||||
## Purpose
|
||||
|
||||
This catalog collects reusable security architecture patterns for
|
||||
NetKingdom-enabled infrastructures. Patterns describe recurring
|
||||
implementation shapes, tradeoffs, failure modes, and verification
|
||||
signals.
|
||||
|
||||
Patterns are not tutorials, ADRs, or vendor docs. A tutorial shows how to
|
||||
do a concrete implementation. An ADR records a decision. A vendor doc
|
||||
describes a product. A pattern captures a reusable architecture idea and
|
||||
how NetKingdom maps it into its platform.
|
||||
|
||||
## Pattern Template
|
||||
|
||||
```text
|
||||
Problem
|
||||
Context
|
||||
Forces
|
||||
Solution
|
||||
Implementation sketch
|
||||
Failure modes
|
||||
Related capabilities
|
||||
Maturity
|
||||
Verification
|
||||
References
|
||||
```
|
||||
|
||||
## Initial Pattern Set
|
||||
|
||||
| Pattern | Capability group | Maturity | Canonical NetKingdom mapping |
|
||||
| --- | --- | --- | --- |
|
||||
| STS credential vending | Secrets, authorization, data access | reviewed | IAM Profile + flex-auth + backend STS, OpenBao broker/audit where useful |
|
||||
| Workload identity | Identity and secrets | draft | Kubernetes service account identity, IAM Profile mapping, OpenBao Kubernetes auth |
|
||||
| Secret zero avoidance | Secrets and bootstrap | reviewed | SOPS/age bootstrap, emergency bundle, OpenBao runtime handoff |
|
||||
| Dynamic secrets | Secrets and credentials | draft | OpenBao dynamic credentials with leases and revocation |
|
||||
| Short-lived SSH certificates | Privileged access | draft | ops-warden issues certificates, ops-bridge consumes and audits |
|
||||
| Delegated authorization | Authorization | reviewed | flex-auth as canonical boundary, Topaz as first delegated PDP |
|
||||
| Break-glass access | Recovery and incident response | reviewed | emergency bundle, limited principals, audit and post-event review |
|
||||
| Tenant isolation | Tenant boundary | draft | tenant ids, tenant-scoped resources, control-plane guardrails |
|
||||
| Central audit ledger | Detection and audit | seed | identity, flex-auth, Topaz, OpenBao, Kubernetes, workload correlation |
|
||||
| Policy-as-code admission | Kubernetes hardening | seed | deployment gates and reviewable policy packages |
|
||||
| Supply-chain provenance | Supply chain | seed | SBOM, signed images, SLSA-style provenance |
|
||||
| Network default deny | Network security | seed | Kubernetes NetworkPolicy and explicit service communication |
|
||||
| Object-level authorization check | Application and API security | draft | every resource access includes tenant/resource/action decision |
|
||||
| Human/agent identity split | Agent access control | draft | agents have explicit identities, scopes, and audit trails |
|
||||
| Tenant context propagation | Tenant isolation | draft | every request and background job carries tenant context |
|
||||
|
||||
## First-Class Pattern Artifacts
|
||||
|
||||
The genesis catalogue now has one first-class artifact per exact pattern
|
||||
name. The authoritative completion matrix is
|
||||
`artifacts/generated/research-pattern-normalization.md`.
|
||||
|
||||
| Family | Exact pattern artifacts |
|
||||
| --- | --- |
|
||||
| Identity and access | Central Identity Provider; Identity Broker; Tenant Membership Boundary; Role Composition; Policy Decision Point / Policy Enforcement Point; Time-boxed Privilege Elevation; Break-glass Access; Human/Agent Identity Split |
|
||||
| Tenant isolation | Namespace-per-Tenant; Cluster-per-Tenant; Cell-based Architecture; Shared Control Plane, Isolated Data Plane; Tenant Context Propagation; Tenant Data Partitioning |
|
||||
| Kubernetes and platform | Secure Cluster Baseline; Policy-as-Code Admission Control; Pod Security Baseline/Restricted; Network Default Deny; Signed Image Admission; GitOps with Guardrails; Runtime Threat Detection |
|
||||
| Secrets and cryptography | External Secrets Operator; Sealed Secret / Encrypted Git Secret; Short-lived Credentials; Key-per-Tenant; Certificate Automation |
|
||||
| Application/API security | API Gateway as Security Boundary; Backend-for-Frontend; Object-Level Authorization Check; Schema-First API Security; Idempotent Command API; Secure File Upload Pipeline |
|
||||
| Supply chain | Protected Main Branch; Dependency Update Bot; SBOM-per-Release; SLSA Build Provenance; Signed Container Images; Quarantined Build Runner |
|
||||
| Detection and response | Security Event Taxonomy; Central Audit Ledger; Tenant Audit Log View; Incident Runbook Library; Kill Switch / Tenant Freeze; Token Revocation Sweep |
|
||||
|
||||
The NetKingdom umbrella artifacts created during NK-WP-0008 remain in
|
||||
the infospace where they describe platform-specific compositions, such
|
||||
as STS credential vending, workload identity, dynamic secrets, delegated
|
||||
authorization, tenant isolation, policy-as-code admission, and
|
||||
supply-chain provenance.
|
||||
|
||||
## Pattern Notes
|
||||
|
||||
### STS Credential Vending
|
||||
|
||||
Problem: applications need object-storage access without holding
|
||||
long-lived root credentials.
|
||||
|
||||
Solution: use IAM Profile tokens to identify the actor, flex-auth to
|
||||
authorize bucket/prefix/action/TTL, provider-native STS or temporary
|
||||
credential APIs to mint credentials, and OpenBao for parent material,
|
||||
lease, broker configuration, and audit where needed.
|
||||
|
||||
Verification: credentials include session token and expiration; deny
|
||||
paths produce stable reason codes; consumers refresh before expiration.
|
||||
|
||||
### Secret Zero Avoidance
|
||||
|
||||
Problem: runtime secret managers need initial trust without creating a
|
||||
worse unmanaged secret.
|
||||
|
||||
Solution: use SOPS/age and emergency bundles for bootstrap and recovery,
|
||||
then hand runtime workload secret authority to OpenBao once initialized,
|
||||
audited, backed up, and governed.
|
||||
|
||||
Verification: OpenBao root and recovery material are treated as
|
||||
platform-root break-glass material; workloads do not consume bootstrap
|
||||
root material.
|
||||
|
||||
### Delegated Authorization
|
||||
|
||||
Problem: identity providers and application code should not become the
|
||||
canonical home for every resource-specific authorization decision.
|
||||
|
||||
Solution: flex-auth owns the canonical request/decision envelope,
|
||||
resource/action vocabulary, CARING descriptors, audit/explain records,
|
||||
and backend adapter boundary. Topaz is the first delegated PDP runtime.
|
||||
|
||||
Verification: policy packages distinguish `tenant:platform` from tenant
|
||||
packages; decision envelopes include tenant, protected-system, resource,
|
||||
action, assurance, obligations, deny reasons, and audit correlation.
|
||||
|
||||
### Break-Glass Access
|
||||
|
||||
Problem: operators need recovery access when normal identity, policy, or
|
||||
cluster services are unavailable.
|
||||
|
||||
Solution: define a minimal emergency path with scoped credentials,
|
||||
separate storage, event logging where possible, and mandatory post-event
|
||||
review.
|
||||
|
||||
Verification: break-glass is tested in drills and never grants ordinary
|
||||
tenant administrators platform-root authority.
|
||||
@@ -0,0 +1,91 @@
|
||||
# Security Capability Catalog
|
||||
|
||||
Status: initial catalog extracted from the genesis exploration
|
||||
Owner: NetKingdom architecture, maintained in infospace-bench
|
||||
|
||||
## Purpose
|
||||
|
||||
This catalog names the security outcomes a NetKingdom-enabled platform
|
||||
must provide before production use. Capabilities describe what must
|
||||
exist; patterns describe how the capability may be implemented.
|
||||
|
||||
The catalog is intentionally platform-oriented. It separates platform
|
||||
responsibility from product/application responsibility and tenant
|
||||
responsibility so security does not become scattered repo-local lore.
|
||||
|
||||
## Capability Template
|
||||
|
||||
Each capability should eventually use this shape:
|
||||
|
||||
```text
|
||||
Intent
|
||||
Scope
|
||||
Threats addressed
|
||||
Required controls
|
||||
Implementation options
|
||||
Platform responsibility
|
||||
Product responsibility
|
||||
Tenant responsibility
|
||||
Readiness criteria
|
||||
Evidence
|
||||
Related patterns
|
||||
Related standards
|
||||
```
|
||||
|
||||
## Capability Groups
|
||||
|
||||
| Group | Intent | Initial readiness focus |
|
||||
| --- | --- | --- |
|
||||
| Security governance and production readiness | Make security decisions, risks, exceptions, and promotion gates explicit | ADRs, risk register, threat models, readiness gates |
|
||||
| Identity and user management | Establish trusted human, service, workload, and agent identities | IAM Profile, key-cape, Keycloak, MFA, lifecycle management |
|
||||
| Authorization and access control | Decide what actors may do to scoped resources | flex-auth, CARING descriptors, Topaz, tenant-aware decisions |
|
||||
| Tenant isolation | Keep tenant identity, runtime, data, and control-plane boundaries explicit | tenant context propagation, data partitioning, control-plane guardrails |
|
||||
| Secrets, keys, and credentials | Prevent scattered static credentials and unsafe bootstrap paths | SOPS/age bootstrap, OpenBao runtime authority, rotation, leases |
|
||||
| Network and edge security | Control public entry points and lateral movement | ingress, TLS, default-deny network policy, egress control |
|
||||
| Platform and Kubernetes hardening | Reduce default platform attack surface | RBAC, pod security, admission control, image provenance |
|
||||
| Application and API security | Make applications safe consumers of platform security services | OIDC integration, object-level authorization, API schemas |
|
||||
| Data protection and privacy | Protect sensitive and tenant data over its lifecycle | classification, encryption, retention, deletion, auditability |
|
||||
| Software supply chain security | Protect source, build, dependency, and artifact integrity | SBOM, signed images, provenance, dependency review |
|
||||
| Observability, detection, and audit | Make security-relevant activity visible and reviewable | central audit, identity logs, policy logs, OpenBao audit, tenant audit |
|
||||
| Incident response and recovery | Contain incidents and recover platform and tenant service safely | runbooks, break-glass, restore drills, post-incident review |
|
||||
|
||||
## Production Readiness Baseline v0.1
|
||||
|
||||
The first NetKingdom production readiness baseline contains these
|
||||
capabilities:
|
||||
|
||||
1. Central identity provider.
|
||||
2. MFA for privileged access.
|
||||
3. Tenant identity and isolation model.
|
||||
4. Kubernetes secure baseline.
|
||||
5. Secrets management and OpenBao runtime handoff.
|
||||
6. Network default-deny and ingress control.
|
||||
7. API authentication and object-level authorization.
|
||||
8. Policy-as-code admission control.
|
||||
9. Container and dependency vulnerability management.
|
||||
10. Central security logging and audit trail.
|
||||
11. Backup and restore verification.
|
||||
12. Incident response runbooks.
|
||||
|
||||
## Standards Mapping Seed
|
||||
|
||||
| Standard or framework | Use in this infospace |
|
||||
| --- | --- |
|
||||
| NIST CSF 2.0 | Governance-level capability grouping: Govern, Identify, Protect, Detect, Respond, Recover |
|
||||
| CIS Controls v8 | Practical control coverage and data protection mapping |
|
||||
| OWASP ASVS | Verifiable application security requirements |
|
||||
| OWASP API Security | API authorization and object-level access risk framing |
|
||||
| SLSA | Build provenance and supply-chain integrity |
|
||||
| OpenSSF Scorecard | Open-source dependency and project-risk signals |
|
||||
| CNCF Cloud Native Security | Kubernetes and cloud-native platform security framing |
|
||||
| NSA/CISA Kubernetes Hardening | Kubernetes hardening checklist and threat focus |
|
||||
|
||||
## NetKingdom-Specific Notes
|
||||
|
||||
- IAM Profile is the canonical identity contract.
|
||||
- flex-auth is the canonical authorization decision boundary.
|
||||
- OpenBao is runtime secret authority, not identity provider or policy
|
||||
decision point.
|
||||
- Railiance owns deployment layers and platform services.
|
||||
- `infospace-bench` owns this catalog as a concrete infospace artifact,
|
||||
not as the canonical deployment source.
|
||||
@@ -0,0 +1,51 @@
|
||||
# Security Readiness Levels
|
||||
|
||||
Status: initial readiness model extracted from the genesis exploration
|
||||
|
||||
## Purpose
|
||||
|
||||
Readiness levels make the catalog operational. They define how strong a
|
||||
capability or pattern must be before it is trusted for a given deployment
|
||||
stage.
|
||||
|
||||
## Levels
|
||||
|
||||
| Level | Name | Suitable for | Minimum expectations |
|
||||
| --- | --- | --- | --- |
|
||||
| RL0 | Experimental | local prototypes | no production data, no external users, no real secrets in code |
|
||||
| RL1 | Internal alpha | internal use | central login preferred, basic access control, secrets not committed, known risks documented |
|
||||
| RL2 | Private beta | selected external users | tenant model defined, isolation tested, backups configured, security logging centralized |
|
||||
| RL3 | Production | paid customers | MFA for privileged users, least privilege, secrets rotation, auditable admin actions, restore tested |
|
||||
| RL4 | Regulated production | high-trust or regulated customers | formal risk management, customer audit logs, artifact provenance, stronger data residency and deletion controls |
|
||||
|
||||
## Pattern Maturity
|
||||
|
||||
Pattern maturity is related to readiness, but not identical:
|
||||
|
||||
```text
|
||||
seed -> draft -> reviewed -> canonical -> deprecated
|
||||
```
|
||||
|
||||
- `seed`: captured from exploration, source notes, or external reading.
|
||||
- `draft`: written in the pattern template with initial mapping.
|
||||
- `reviewed`: checked for threat model, ownership, and verification.
|
||||
- `canonical`: accepted as the recommended NetKingdom pattern.
|
||||
- `deprecated`: retained for history but no longer recommended.
|
||||
|
||||
## Evidence By Level
|
||||
|
||||
| Evidence | RL1 | RL2 | RL3 | RL4 |
|
||||
| --- | --- | --- | --- | --- |
|
||||
| owner named | required | required | required | required |
|
||||
| threat notes | useful | required | required | required |
|
||||
| verification checklist | useful | required | required | required |
|
||||
| operational runbook | optional | useful | required | required |
|
||||
| audit hooks | optional | useful | required | required |
|
||||
| restore or failure drill | optional | useful | required | required |
|
||||
| standards mapping | optional | useful | useful | required |
|
||||
|
||||
## NetKingdom Default
|
||||
|
||||
Patterns that touch identity, authorization, secrets, tenant isolation,
|
||||
or privileged access should not be marked canonical below RL3 unless
|
||||
their production limitations are explicitly documented.
|
||||
Reference in New Issue
Block a user