GCP 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 offers built-in Internal TCP/UDP Load Balancing and proxy systems for Internal HTTP(S) Load Balancing.
- VPC connects to on-premises networks using Cloud VPN tunnels and Cloud Interconnect attachments.
- VPC distributes traffic from Google Cloud external load balancers to backends.
- 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
- 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 subnets of the Shared VPC network.
- VPC Network Peering allow 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 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 resource 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 following subnet creation mode
- Auto mode VPC networks
- create subnets in each region automatically
- adds new subnets automatically, if 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 to production
- cannot be switched to auto mode VPC networks
- Auto mode VPC networks
- Subnet must have a defined primary IP address range, and any resources created within is assigned an IP address from the defined range.
- Subnets can be added secondary IP address range, which are only used by alias IP ranges. This is useful if having multiple services running on a VM and you want to assign each service a different IP address.
- 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 (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
- each VPC network comes with some system-generated routes to route traffic among its subnets and send traffic from eligible instances to the internet.
- custom routes
- are either static routes created manually or dynamic routes maintained automatically by one or more of the Cloud Routers
- system-generated routes
VPC Firewall Rules
- Firewall rules help define allow or deny connections and apply to both outgoing (egress) and incoming (ingress) traffic in the network.
- Firewall rules control traffic even if it is entirely within the network, including communication among VM instances.
- Firewall rules apply to a given project and network and connections are allowed or denied on a per-instance basis.
- Every VPC network has two implied firewall rules
- Implied allow egress rule – allow most egress traffic,
- Implied deny ingress rule – denies all ingress traffic.
- Implied rules cannot be deleted but have the lowest possible priorities and can be overridden
- Firewall Rules Logging enables auditing, verifying, and analyzing the effects of the firewall rules.
- Firewall rules only support IPv4 connections
- Firewall Rule components
- Each firewall rule requires direction of connection and applies to incoming (ingress) or outgoing (egress) connection, not both
- Each firewall rule’s action is either
- Each firewall rule has a priority defined from
65535inclusive, defaults to 1000. Lower integers indicate higher priorities.
- A target, which defines the instances to which the rule applies.
- Ingress (inbound) rule, the target parameter designates the destination VM instances
- Egress (outbound) rule, the target designates the source instances.
- supports the following options
- All instances in the network.
- Instances by target tags.
- Instances by target service accounts
- A source for ingress rules or a destination for egress rules.
- Ingress (inbound) rules, the target parameter specifies the destination instances for traffic; you cannot use the destination parameter. You specify the source by using the source parameter.
- Egress (outbound) rules, the target parameter specifies the source instances for traffic; you cannot use the source parameter. You specify the destination by using the destination parameter.
- supports the following options
- Source IP ranges:
- Source tags:
- Source service accounts:
- Firewall rules has enforcement status, and is enabled by default. They can be disabled and useful for troubleshooting or for maintenance, instead of having to delete them and add again.
- VPC firewall rules are stateful
- GCP associates incoming packets with corresponding outbound packets by using a connection tracking table.
- When a connection is allowed through the firewall in either direction, return traffic matching this connection is also allowed. Firewall rule cannot be configured to deny associated response traffic.
- Return traffic must match the 5-tuple (source IP, destination IP, source port, destination port, protocol) of the accepted request traffic, but with the source and destination addresses and ports reversed.
- Google Cloud implements connection tracking regardless of whether the protocol supports connections.
- A firewall rule’s tracking state is considered active if at least one packet is sent every 10 minutes
Shared VPC – VPC Sharing
Refer blog post GCP Shared VPC
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.
- VPC Flow logs can be used for network monitoring, forensics, real-time security analysis, and expense optimization.
- 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 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. 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