Skip to content
GCP Non GKE Subnets

GCP Non GKE Subnets

Andi Lamprecht Andi Lamprecht ·· 2 min read· Accepted
ADR-0018 · Author: Sybil Melton · Date: 2025-02-07 · Products: platform
Originally ADR-0038 GCP_Non-GKE_Subnets (v4) · Source on Confluence ↗

GCP Non-GKE Subnets

Status: Accepted

Deciders: ryan.cullison@droneup.com, sybil.melton@droneup.com, eric.brookman@droneup.com

Date: July 17, 2023

Technical Story

Document subnetting outside of GKE(Google Kubernetes Engine) and the process for leagues to use it.

Context and Problem Statement

  • In GCP, some non-GKE services require the use of private subnets.
  • Leagues require the ability to use these services.
  • Due to the Shared VPC, PSC(private service connection)1 is needed between the host project and service project. This requires additional subnet ranges outside of the already allocated ranges for each league.
  • Note: Some GCP services use 172.17.0.0/16 for internal use (Filestore2, AlloyDB3)

Decision Drivers

  • Automation through Terraform - Provide ability to use services without submitting an IT ticket
  • Scalability - Design for the future
  • Ease of Configuration Management - reduce (or eliminate) manual configuration steps to make the subnet useable

Considered Options

  1. Large shared subnet per environment
  2. Small subnet per league per environment

Decision Outcome

Large (/16) shared subnet per environment

Knowledge base article only needs outline how to use the subnet. No additional IP subnet request will be required.

  • Good, because IAM security tags can secure inter-league communication

  • Good, because Cato rules will be easier to configure

  • Good, because GCP services only reserve small ranges at a time, so this provides a lot of ranges (a /16 provides: 4,096 /28 or 512 /24)

  • Good, because leagues only need to choose the Shared VPC and PSC subnet

  • Good, because routing table will be smaller

  • Bad, because IAM controls for some services may not be as fine-grained as we’d like; i.e. Memorystore for Redis does not limit the ability to connect to an instance, it only controls what actions are allowed

    • IP connectivity only available through Cato
    • GCP-Break-Glass functionality can help limit this as well

Consequences/Tech Debt Incurred

  1. IAM tags must be implemented to protect inter-league communication
  2. GCP Break-Glass must be implemented to protect user-to-GCP Prod communication

Pros and Cons of the Options

Small subnet per league per environment

  • Good, because firewall rules can be more restrictive, especially with Cato

  • Bad, because each time a new service needs to be configured, an IP subnet will need to be requested from IT and configured in GCP

    • This can be automated with the introduction of IPAM and integrating it with Terraform

Links/Supporting Information

Private Services Access

Last updated on