SC-07 Boundary Protection
Control statement
a. Monitor and control communications at the external managed interfaces to the system and at key internal managed interfaces within the system;
b. Implement subnetworks for publicly accessible system components that are [Selection: physically; logically] separated from internal organizational networks; and
c. Connect to external networks or systems only through managed interfaces consisting of boundary protection devices arranged in accordance with an organizational security and privacy architecture.
Guidance
Managed interfaces include gateways, routers, firewalls, guards, network-based malicious code analysis, virtualization systems, or encrypted tunnels implemented within a security architecture. Subnetworks that are physically or logically separated from internal networks are referred to as demilitarized zones or DMZs. Restricting or prohibiting interfaces within organizational systems includes restricting external web traffic to designated web servers within managed interfaces, prohibiting external traffic that appears to be spoofing internal addresses, and prohibiting internal traffic that appears to be spoofing external addresses. SP 800-189 provides additional information on source address validation techniques to prevent ingress and egress of traffic with spoofed addresses. Commercial telecommunications services are provided by network components and consolidated management systems shared by customers. These services may also include third party-provided access lines and other service elements. Such services may represent sources of increased risk despite contract security provisions. Boundary protection may be implemented as a common control for all or part of an organizational network such that the boundary to be protected is greater than a system-specific boundary (i.e., an authorization boundary).
Implementation
Talos node
No public address and no inbound port on any node; nodes only dial out to Cloudflare. hostNetwork pods are allowed only in kube-system, flux-system and spire-system; spire-system because SPIRE requires it (spire-agent node attestation and the Workload API served on the host). Partial: proven on the lab clusters only; no node-level egress filtering yet.
Status: partial.
Evidence:
Cloudflare Tunnel and WARP access
The cluster boundary is the tunnel: the only ingress rule is the catch-all http_status:404, so nothing is published; the only route is the cluster's /24 to WARP clients of the org.
Status: partial. Configured as described, but the only evidence is a configuration file; no Lula validation or assessment result proves it on the lab clusters yet. Raise to implemented when one exists.
Evidence:
All controls. Source: OSCAL component definition reti-platform and NIST SP 800-53 Rev 5 (public domain).