Secure Public Ingress

Andi Lamprecht ·2026-05-11· 8 min read· Draft

Secure Public Ingress

Context

The Secure Sandbox requires a scalable ingress architecture that meets ITAR and FedRAMP Moderate requirements. The system is designed to eventually reside within a GCP Assured Workloads boundary. To minimize transition risk and technical debt, all infrastructure decisions made in the Sandbox must be inherently compatible with the “U.S. Person” and “Sovereign Boundary” constraints of the restricted production environment.

The selection of the public ingress stack was based on compliance, technical, and operational pillars:

Compliance Requirements

Technical Requirements

Decision

We will utilize the GCP-Native Edge Stack (Cloud DNS, Cloud Armor, Certificate Manager, and Cloud CDN) for the Secure Sandbox. The decision was driven by nature of the data, which must satisfy FedRAMP Moderate/High and ITAR requirements. A critical component of these frameworks is the protection of “Technical Data,” which includes not only payload data but also the network metadata (IP patterns, system fingerprints, and security logs) that reveals the design or operational capacity of the system. Cloudflare cannot guarantee U.S.-only support to meet that requirement.

Consequences

Positive

1. By avoiding vendors that cannot guarantee U.S. Person support, we simplify the NIST SA-9 (External Services) and AC-4 (Information Flow) documentation. GCP meets the compliance requirements for the restricted protection environment with Assured Workloads.

2. Since the WAF and DNS services are native to the GCP project:

   1. Network metadata (IP logs, DNS queries, security events) never leave the boundary.
   2. Don’t have to “punch holes” for an external IP range in the VPC Service Control policy.
   3. The logs are already in the same format and flow into the same Cloud Logging buckets. Sending to the chosenSIEM is a single “sink” configuration.

3. By maintaining architectural parity between the Sandbox and the restricted production environment, we ensure that security controls validated during the development phase are functionally equivalent upon deployment. This eliminates ‘Architectural Drift’ and ensures that the NIST CM-6 (Configuration Settings) applied in the restricted environment have been pre-vetted for operational stability, without requiring non-U.S. persons to access the production boundary.

4. TLS termination on the GCLB utilizes FIPS 140-3 validated cryptographic modules (BoringCrypto). This provides native compliance with SC-13.

5. Direct ingress via the Global External Application Load Balancer (GCLB) reduces round-trip latency by removing the third-party proxy layer.

6. Telemetry enters the Google network at the nearest Edge Point of Presence and travels over Google’s private fiber backbone, minimizing jitter and ensuring CP-8 (Availability) for real-time streams.

7. Cloud DNS satisfies CP-8 by providing a 100% uptime SLA through a global anycast network, ensuring endpoint resolution even during regional outages or large-scale DDoS events.

8. GCP Certificate Manager automates the rotation and management, as well as, can be integrated with the GCP Private CA Service for a strictly internal, U.S.-only root of trust for all identities, if required.

9. Using GCP native tools allows the team to utilize a single Customer Responsibility Matrix for operational efficiency.

Negative

1. Cloud Armor may require more manual tuning of the OWASP Core Rule Set (CRS).
2. While Cloud Armor Enterprise has adaptive protection, there may be more manual work to define what a “normal” request looks like compared to a “malicious” one.
3. Configurations for

Alternatives Considered

Cloudflare (Commercial & Government)

Cloudflare, our current standard for non-regulated products, was evaluated as a potential Edge Security and CDN provider due to its reputation for ease of use and advanced bot management capabilities. A third-party edge provider like Cloudflare offers the potential for “Cloud Agnostic” portability. Theoretically, this would allow DroneUp to move the telemetry backend to another CSP (Cloud Service Provider) without reconfiguring the global entry point, DNS, or WAF rules. However, to meet federal requirements, this would have required a separate account in the Cloudflare for Government offering under an Enterprise plan.

• Sovereignty & U.S. Person Constraint (ITAR / NIST SA-9): Cloudflare for Government offers a secure environment but can’t ensure a fully “U.S. Person-only” support chain for all account and operational metadata. Metadata like connection logs and support interactions are sensitive. Using a provider with global support poses an unacceptable “Deemed Export” risk.
• Architectural Parity & Testing Fidelity (NIST CP-8): Using Cloudflare in Sandbox but GCP-Native in Production causes “Dual Architecture” friction. Sandbox tests won’t match Production for latency, WAF tuning, or VPC-SC enforcement. Sticking to GCP-Native ensures “tested code is production code,” reducing deployment outage risks.
• Audit Fragmentation (NIST AU-2 / SC-23): A hybrid stack splits the session audit trail. Linking a Keycloak identity in GKE to a Cloudflare request log needs manual “log stitching.” The GCP-Native stack offers a unified identity-to-edge audit trail for real-time tracking of Authority User access to ITAR-protected map assets.
• Security Perimeter Complexity (NIST SC-7): A third-party WAF requires maintaining manual IP-based “allowlists” and punching holes in the VPC-SC perimeter. By staying native, we utilize Identity-based trust, which is more secure and reduces the “operational toil.”

Formal Impact

ATOMx

Compliance Traceability Matrix (NIST 800-53 Moderate/ITAR)