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

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.