GCP Non GKE Subnets
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
- Large shared subnet per environment
- 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
- IAM tags must be implemented to protect inter-league communication
- 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