Add security architecture pattern infospace

infospaces/patterns-of-it-securita-architecture/artifacts/entities/pattern-namespace-per-tenant.md

@@ -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.