generated from coulomb/repo-seed
77 lines
2.3 KiB
Markdown
77 lines
2.3 KiB
Markdown
# 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.
|