Google Cloud Virtual Private Cloud – VPC

Virtual Private Cloud – VPC provides networking functionality for the cloud-based resources and services that is global, scalable, and flexible.

VPC Networks

VPC network is a virtual version of a physical network
A VPC network is a global resource that consists of a list of regional virtual subnets in data centers, all connected by a global wide area network.

VPC networks are logically isolated from each other in Google Cloud.
VPC networks
- provides connectivity for the VMs and products built on it like GKE
- offers built-in Internal TCP/UDP Load Balancing and proxy systems for Internal HTTP(S) Load Balancing.
- connects to on-premises networks using Cloud VPN tunnels and Cloud Interconnect attachments.
- distributes traffic from GCP external load balancers to backends

Specifications

VPC networks are global resources, including the associated routes and firewall rules, and are not associated with any particular region or zone.
Subnets are regional resources and each subnet defines a range of IP addresses
Network firewall rules control the Traffic to and from instances. Rules are implemented on the VMs themselves, so traffic can only be controlled and logged as it leaves or arrives at a VM.

Resources within a VPC network can communicate with one another by using internal IPv4 addresses, subject to applicable network firewall rules.
Private access options for services allow instances with internal IP addresses can communicate with Google APIs and services.
Network administration can be secured by using IAM roles.

An organization can use Shared VPC to keep a VPC network in a common host project. Authorized IAM members from other projects in the same organization can create resources that use Shared VPC network subnets.
VPC Network Peering allows VPC networks to be connected with other VPC networks in different projects or organizations.
VPC networks can be securely connected in hybrid environments by using Cloud VPN or Cloud Interconnect.

VPC networks only support IPv4 unicast traffic. They do not support broadcast, multicast, or IPv6 traffic within the network; VMs in the VPC network can only send to IPv4 destinations and only receive traffic from IPv4 sources.

VPC Subnets

VPC networks do not have any IP address ranges associated with them.
Each VPC network consists of one or more useful IP range partitions called subnets and IP ranges are defined for the subnets.

Subnets are regional resources and each subnet is associated with a region.
A network must have at least one subnet before it can be used.
More than one subnet per region can be created

VPC Network supports the following subnet creation mode
- Auto mode VPC networks
  - create subnets in each region automatically
  - adds new subnets automatically, if a new region becomes available
  - can be switched to custom mode VPC networks
- Custom mode VPC networks
  - start with no subnets, giving full control over subnet creation.
  - are more flexible and are better suited for production
  - cannot be switched to auto mode VPC networks

Subnet must have a defined primary IP address range, and any resources created within are assigned an IP address from the defined range.
Subnets can be assigned a secondary IP address range, which is only used by alias IP ranges. This is useful if you have multiple services running on a VM and want to assign each service a different IP address.
Primary IP range of an existing subnet can be expanded by modifying its subnet mask, setting the prefix length to a smaller number.

VPC Routes

Routes define paths for packets leaving instances (egress traffic), either inside the network or outside of Google Cloud
A route consists of
- a single destination prefix in CIDR format (0.0.0.0/0) and
- a single next hop (for e.g Internet Gateway)
When an instance in a VPC network sends a packet, GCP delivers the packet to the route’s next hop if the packet’s destination address is within the route’s destination range.
Routes are defined at the VPC network level but implemented at each VM instance level.

Each VM instance has a controller that is kept informed of all applicable routes from the network’s routing table. Each packet leaving a VM is delivered to the appropriate next hop of an applicable route based on a routing order. When a route is added or deleted, the set of changes is propagated to the VM controllers by using an eventually consistent design.
Routes are divided into two categories: system-generated and custom.
- system-generated routes
  - default – send traffic from eligible instances to the internet and can be removed or replaced
  - subnet routes – route traffic among its subnets and updated automatically by Google Cloud
  - are applied at the VPC level to all the instances
- custom routes
  - are either static routes created manually or dynamic routes maintained automatically by one or more of the Cloud Routers
  - can be applied to all the instances or specific instance using network tag

VPC Firewall Rules

Refer blog post @ Google Cloud VPC Firewall Rules

VPC Private Access Options

Google Cloud provides several private access options which allow VM instances with internal IP addresses to reach certain APIs and services
Private Google Access
- allows VMs to connect to the set of external IP addresses used by Google APIs and services by enabling Private Google Access on the subnet used by the VM’s network interface.
- allows access to the external IP addresses used by App Engine, including third-party App Engine-based services.
- configured on a subnet by subnet basis
- provides following routing options
  - use default route with its next-hop being the default internet gateway, and it provides a path to the default domains, private.googleapis.com, and restricted.googleapis.com.
  - use custom static routes, each having a more specific destination, and each using the default internet gateway next hop.
- Use this option to connect to Google APIs and services without giving the Google Cloud resources external IP addresses.
Private services access
- is a private connection between the VPC network and a network owned by Google or a third party i.e. service producers
- enables VM instances in the VPC network and the accessed services to communicate exclusively by using internal IP addresses.
- VM instances don’t need Internet access or external IP addresses to reach services that are available through private services access.
- Use this option to connect to specific Google and third-party services without assigning external IP addresses to the Google Cloud and Google or third-party resources.

Refer blog post GCP Shared VPC

VPC Peering

Refer blog post GCP VPC Peering

VPC Flow Logs

VPC Flow Logs records a sample of network flows sent from and received by VM instances, including instances used as GKE nodes.

Flow Logs can be used for network monitoring, forensics, real-time security analysis, and expense optimization.
Flow logs are enabled on the VPC subnet level.
Flow logs only record TCP and UDP connections.

With GCP Shared VPC, all Flow logs are in the host project.
Cloud Logging can be used to view the flow logs and it can be exported to any destination that Cloud Logging export supports.
Flow logs are aggregated by the connection from Compute Engine VMs and exported in real-time.

Flow logs can be analyzed using real-time streaming APIs by subscribing to Pub/Sub.
Flow logs are collected for each VM connection at specific intervals (sampling period). All packets collected for a given interval for a given connection are aggregated for a period of time (aggregation interval) into a single flow log entry

GCP Certification Exam Practice Questions

Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).

GCP services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.

GCP exam questions are not updated to keep up the pace with GCP updates, so even if the underlying feature has changed the question might not be updated

Open to further feedback, discussion and correction.

Your VMs are running in a subnet that has a subnet mask of 255.255.255.240. The current subnet has no more free IP addresses and you require an additional 10 IP addresses for new VMs. The existing and new VMs should all be able to reach each other without additional routes. What should you do?
1. Use gcloud to expand the IP range of the current subnet.
2. Delete the subnet, and recreate it using a wider range of IP addresses.
3. Create a new project. Use Shared VPC to share the current network with the new project.
4. Create a new subnet with the same starting IP but a wider range to overwrite the current subnet
An IT company has a set of compute engine instances hosted in a VPC. They are not exposed to the internet. These instances now need to install an important security patch. How can the security patch be installed on the instances?
1. Upload to Cloud Storage and enable VPC peering
2. Upload to Cloud Storage and whitelist instance IP address
3. Upload to Cloud Storage and enable Private Google Access
4. Upload to Cloud Source Repository and enable VPC peering
Your security team wants to be able to audit network traffic inside of your network. What’s the best way to ensure they have access to the data they need?
1. Disable flow logs.
2. Enable flow logs.
3. Enable VPC Network logs
4. Add a firewall capture filter.

References

GCP_Virtual_Private_Cloud

Shared VPC allows an organization to connect resources from multiple projects to a common VPC network to communicate with each other securely and efficiently using internal IPs from that network.

requires designating a project as a host project and attach one or more other service projects to it.
allows organization administrators to delegate administrative responsibilities, such as creating and managing instances, to Service Project Admins while maintaining centralized control over network resources like subnets, routes, and firewalls.

allows you to
- implement a security best practice of least privilege for network administration, auditing, and access control.
- apply and enforce consistent access control policies at the network level for multiple service projects in the organization while delegating administrative responsibilities
- use service projects to separate budgeting or internal cost centers.

Shared VPC Concepts

GCP Shared VPC - Multiple host projects

Shared VPC connects projects within the same organization. Participating host and service projects cannot belong to different organizations

Linked projects can be in the same or different folders, but if they are in different folders the admin must have Shared VPC Admin rights to both folders
Each project in Shared VPC is either a host project or a service project
- A host project contains one or more Shared VPC networks. A Shared VPC Admin must first enable a project as a host project. After that, a Shared VPC Admin can attach one or more service projects to it.
- A service project is any project that has been attached to a host project by a Shared VPC Admin. This attachment allows it to participate in Shared VPC.
A project cannot be both a host and a service project simultaneously. Thus, a service project cannot be a host project to further service projects.
Multiple host projects can be created; however, each service project can only be attached to a single host project.

A project that does not participate in Shared VPC is called a standalone project.
VPC networks in the host project are called Shared VPC networks. Service projects resources can use subnets in the Shared VPC network
Shared VPC networks can be either auto or custom mode, but legacy networks are not supported.

Host and service projects are connected by attachments at the project level.
Subnets of the Shared VPC networks in the host project are accessible by Service Project Admins
Organization policies and IAM permissions work together to provide different levels of access control.

Organization policies enable setting controls at the organization, folder, or project level.

IAM Roles

Administrator (IAM role)	Purpose
Organization Admin	Organization Admins nominate Shared VPC Admins by granting them appropriate project creation and deletion roles, and the Shared VPC Admin role for the organization. These admins can define organization-level policies, but specific folder and project actions require additional folder and project roles.
Shared VPC Admin	Shared VPC Admins have the Compute Shared VPC Admin and Project IAM Admin roles for the organization or one or more folders. They perform various tasks necessary to set up Shared VPC, such as enabling host projects, attaching service projects to host projects, and delegating access to some or all of the subnets in Shared VPC networks to Service Project Admins. A Shared VPC Admin for a given host project is typically its project owner as well. A Shared VPC Admin can link projects in two different folders only if the admin has the role for both folders.
Service Project Admin	A Shared VPC Admin defines a Service Project Admin by granting an IAM member the Network User role to either the whole host project or select subnets of its Shared VPC networks. Service Project Admins also maintain ownership and control over resources defined in the service projects, so they should have the Instance Admin role in the corresponding service projects. They may have additional IAM roles to the service projects, such as project owner.

Cloud Interconnect with Shared VPC

Shared VPC can help share the VLAN attachment in a project with other VPC networks.
Shared VPC is preferable if you need to create many projects and would like to prevent individual project owners from managing their connectivity back to the on-premises network.

Host project contains a common Shared VPC network that VMs in service projects can use. Because VMs in service projects use this network, Service Project Admins don’t need to create other VLAN attachments or Cloud Routers in the service projects.
VLAN attachments and Cloud Routers for an Interconnect connection must be created only in the Shared VPC host project.
The combination of a VLAN attachment and its associated Cloud Router is unique to a given Shared VPC network.

Service Project Admins can create VMs in subnets that exist in a host project’s Shared VPC network based on the permissions that they have to the host project.
VMs that use the Shared VPC network can use the custom dynamic routes for VLAN attachments available to that network.

GCP Certification Exam Practice Questions

Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).

GCP services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.

GCP exam questions are not updated to keep up the pace with GCP updates, so even if the underlying feature has changed the question might not be updated

Open to further feedback, discussion and correction.

Your company is building a large-scale web application. Each team is responsible for its own service component of the application
and wants to manage its own individual projects. You want each service to communicate with the others over the RFC1918 address
space. What should you do?
1. Deploy each service into a single project within the same VPC.
2. Configure Shared VPC, and add each project as a service of the Shared VPC project.
3. Configure each service to communicate with the others over HTTPS protocol.
4. Configure a global load balancer for each project, and communicate between each service using the global load balancer IP
  addresses.
Where should you create the Cloud Router instance in a Shared VPC to allow connection from service projects across a new Dedicated Interconnect to your data center?
1. VPC network in all projects
2. VPC network in the IT Project
3. VPC network in the Host Project
4. VPC network in the Sales, Marketing, and IT Projects