Add security architecture pattern infospace

infospaces/patterns-of-it-securita-architecture/artifacts/entities/pattern-network-default-deny.md

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