Levels of Google Cloud Networking
- Projects are used to group resources that share the same trust boundaries. A lot of people map Projects to teams since every Project has its own access policy (IAM) and member list. Projects comprise of Networks which contain Subnetworks, Firewall rules, and Routes.
- Networks directly connect our resources to each other and to the outside world. Networks which use Firewalls house the access policies for incoming and outgoing connections as well. Networks could be Global – which offers horizontal scalability across multiple Regions or Regional – which low-latency within a single Region. Virtual Private Cloud networks consist of one or more IP range partitions called subnetworks or subnets. Each subnet or subnetwork is associated with a region. VPC networks do not have any IP ranges associated with them. IP ranges are defined for the subnetworks. A network must have at least one subnet then only we can use it.
- Subnetworks allow us to group related resources (Compute Engine instances) into RFC1918 private address spaces. Subnetworks are regional resources. Each subnetwork defines a range of IP addresses.
A Sub-network can be in two modes:
Auto mode network: An auto mode network has one subnet per region, each with a predetermined IP range which fit within the 10.128.0.0/9 CIDR block. These subnets are automatically created when the auto mode network is created. Each subnet has the same name as the overall network. We can add more subnets manually to auto mode networks in addition to the automatically created subnets.
Custom mode network: A custom mode network has no subnets at creation giving us full control over subnet creation. In order to create an instance in a custom mode network, we must first create a subnetwork in that region and specify its IP range. A custom mode network has the possibilities of having zero, one, or many subnets per region.
Whenever a new project is created, a default network configuration provides each region with an auto mode network with pre-populated firewall rules. Additionally, we can create up to four additional networks in a project. It is possible to switch a network from auto mode to custom mode, however, this conversion is one-way, custom mode networks cannot be changed to auto mode networks. Additional networks can be either auto subnet networks or custom subnet networks. In addition, each instance which is created within a subnetwork gets assigned to an IPv4 address from that subnetwork range.
Each network has a default firewall rule that blocks all inbound traffic to instances. To allow traffic to an instance, we must create “allow” rules for the firewall. Also, the default firewall allows traffic from instances unless we configure it to block outbound connections using an “egress” firewall configuration. Therefore, by default we can create “allow” rules for traffic we wish to pass ingress, and “deny” rules for traffic which we wish to restrict egress. We can also create a default-deny policy for egress and prohibit external connections entirely.
It is recommended to set the least permissive firewall rule that will support the kind of traffic which we are trying to pass. For example, if we want to allow traffic to reach some instances, but restrict traffic from reaching others, create rules that allow traffic to the intended instances only. We can set priority levels on each rule and the rule with the lowest-numbered priority will be evaluated first if we want to have “deny” rules to override certain “allow” rule. Creating large and complex sets of override rules is not recommended as it can lead to allowing or blocking traffic that is not intended.
The default network has automatically created firewall rules. Manually created networks do not contain the firewall rules that were automatically created. For all networks except the default network, we must create any firewall rules we need.
The ingress firewall rules which are automatically created for the default network are:
- default-allow-internal: Allows network connections of any protocol and port between instances on the network.
- default-allow-ssh: Allows SSH connections from any source to any instance on the network over TCP port 22.
- default-allow-rdp: Allows RDP connections from any source to any instance on the network over TCP port 3389.
- default-allow-icmp: Allows ICMP traffic from any source to any instance on the network.
We cannot SSH into an instance without allowing SSH firewall rule.
Each and every rule of firewall has a Priority value from 0-65535 which is inclusive. Relative priority values determine the precedence of conflicting rules. Lower priority value implies higher precedence. The priority value is set as 1000, when not specified. If a packet is matching with the conflicting rules with the same priority, the deny policy takes precedence.
We can review the default firewall rules using the console through this path: Navigation menu > VPC networks > Firewall rules.
Firewall Rules and IAM
The compute.securityAdmin role of IAM reserves the privilege of creating, modifying, and deleting firewall rules. Users assigned to the compute.networkAdmin roles are able to safely view and list firewall rules that might apply to their projects.
Allow and ingress are values which we can set for the flags —action and –direction while creating the firewall rules. –action can have 2 values. ALLOW and DENY. Previously, only ALLOW action was supported. DENY rules are generally simpler to understand and apply.
–direction can have 2 values. INGRESS and EGRESS. INGRESS refers to inbound and EGRESS refers to outbound connections.
With INGRESS, EGRESS, ALLOW, DENY, and PRIORITY we have maximum control and flexibility for determining connections in and out of our networks.
All networks have routes created automatically to the Internet (default route) and to the IP ranges in the network. The route names are automatically generated and will look different for each project.
We can review the default routes using the console through this path: Navigation menu > VPC network > Routes.
Creating a custom network
When manually assigning subnetwork ranges, we first create a custom subnet network, then create the subnetworks that we want within a region. When we create a new subnetwork, its name must be unique in that project for that region, even across networks. The same name can be repeated in a project as long as each one is in a different region.
We can create a custom network with the console or with the cloud shell. In the console, we have UI so it is easy to create the network. So here I am showing only the cloud shell part. The following command will create a custom mode network named custom-network.
gcloud compute networks create custom-network --subnet-mode custom
The command given below will create a subnet named subnet-us-central for the custom mode network which we have created now.
gcloud compute networks subnets create subnet-us-central \ --network custom-network \ --region us-central1 \ --range 10.0.0.0/16
Adding firewall rules
To allow access to VM instances, we must apply firewall rules. We can use the instance tag to apply firewall rule to the VM instances. The firewall rule will apply to any VM using the same instance tag.
Instance Tags are used by networks and firewalls to apply certain firewall rules to tagged VM instances. For example, if there are several instances that perform the same task, such as serving a large website, we can tag these instances with a shared word or term and then use that tag to allow HTTP access to those instances with a firewall rule. Tags are also reflected in the metadata server, so we can use them for applications running on our instances.
Either a console or cloud shell can be used to create firewall rules. Here we will create using cloud shell.
The following command will create a firewall rule to allow HTTP internet requests.
gcloud compute firewall-rules create allow-http \ --allow tcp:80 --network custom-network \ --source-ranges 0.0.0.0/0 \ --target-tags http
The above command will create a firewall-rule which will allow HTTP internet requests to those instances which have the tag http because we are using the flag –target-tags.
Here is an example command to create an instance which has tags.
gcloud compute instances create us-test-01 \ --subnet subnet-us-central \ --zone us-central1-a \ --tags http
The use of cloud-based networking to manage and deploy network functions across the Cloud is similar to Software-Defined WAN. The trend is broadening, as a wider array of network functions can be deployed using the cloud. The main goal is to free up services from being attached to specific hardware so that services can be deployed more quickly using software over a networking connection.