Part 1 – GCP Networking Philosophy

Post • 4 min read

This is a 2-Part Series on GCP Networking.

Part 1 - GCP Networking Philosophy

When working with cloud architecture, it's important to see the world from different perspectives.  In software development, we often use personas, and that works very well for cloud architecture as well. However, I tend to use views from different roles and their perspectives. In this story I will use three views.   

Developer

Developers working against cloud environments are a de facto DevOps in the sense that they need programmable platforms for scaling, testing, availability, deployment etc. However most developers do not have years of system operations experience under their belt so it’s therefore important to remove things like networking from their view.

Network Administrator

The network administrator role in the cloud is extremely important.  At first glance it might seem that the role has become less important since you now can create complex networks with declarative infrastructure as code and the hyperscalers have virtually unlimited capacity. However a network is one unit ( mostly ) and trying to align multiple dev teams on network management is a recipe for failure. It is also not only a single vendor public cloud network, but very often also hybrid and multi-cloud.  The role of the network administrator is to provide networking as a service, that should just be there for every use case.

Security Architect

The final view is that of the security architect.  This view is all about ensuring and proving that all the controls are in place to be compliant with company security policy and standards.

As an example: the company network policy is:

  • Egress traffic to the internet must be filtered
  • Ingress traffic must have some form of DDoS protection
  • Ingress is only allowed to specified ports and protocols ( usually 80,443 )
  • Any traffic crossing our zones must be monitored by IPS/IDS, the following zones exist
    • Production
    • Non Production
    • Internet

Developer view on networking

  1. Should be out of scope
  2. Should not be a blocker
  3. Should provide connectivity to systems your application depend on
  4. Should be secure
  5. Should have ability to control ingress along with DNS and certificates

Network Administrators view on networking

  1. Only my team should touch networking
  2. We  can't spend all our time on service requests
  3. We need visibility

Security Architects view

  1. Have provable compliance
  2. Secure defaults

Shared VPC

A shared VPC makes it possible to separate the network´s control plane into its own project.  This project is called the host project. Your workloads will run in service projects. A VM in a service project can place a NIC in a subnet belonging to a VPC in the host project.  There are three controls that will decide: 

Who in what project can use what subnet.

  • Who is controlled by Cloud IAM. Sufficient permissions in service projects to manage the VM like the Compute Administrator role. In the host project that same principal needs the Network User role on the subnet.
  • A pairing is needed to be done between the host and service project, declaring which one is host and which one is service.  A service project can only have  ONE host project. Pairing requires organization level permission.
  • Organization policy enforces what subnets can be used by what project.  Without this policy a user with access to non-prod and prod subnets via IAM  would be able to put workload in production projects in the non-prod network. Organization policy require organization level permission.

With just the shared VPC we have solved the following requirements.

Developer

  • Should be out of scope - All you need to do is setting the tags on your VM
  • Should not be a blocker - You have full control over your ingress and DNS, all you need to wait for is new firewall configurations
  • Should provide connectivity to systems your application depends on - Network admin ensures that the necessary routes are in place in the host project.
  • Should be secure - Now I can’t make it insecure...
  • Should have ability to control ingress along with DNS and certificates -  That's all done in my service project

Network Administrator

  • Only my team should touch networking - Host project make the separation
  • We can't spend all our time on service requests - Developers can launch VM’s in subnets provisioned for them as well as manage their own public DNS and load balancers. We only need to create firewall rules for them.

Shared VPC Diagram

Learn more at: nordcloud.com/multi-cloud/google-cloud-platform/

Martin Kåberg
Martin KåbergPrincipal R&D Architect

Get in Touch.

Let’s discuss how we can help with your cloud journey. Our experts are standing by to talk about your migration, modernisation, development and skills challenges.

Ilja Summala
Ilja’s passion and tech knowledge help customers transform how they manage infrastructure and develop apps in cloud.
Ilja Summala LinkedIn
Group CTO