GCP-Cloud VPC Firewall With Service Accounts
VPC firewall rules let you allow or deny connections to or from virtual machine (VM) instances in your VPC network. While firewall rules are defined at the network level, connections are allowed or denied on a per-instance basis. You can think of the VPC firewall rules as existing not only between your instances and other networks but also between individual instances within the same network.
Service Account vs Network Tag Filtering
- Firewall rules support source and target filtering by Service Account and Network Tags
- Service Accounts and Network Tags cannot be mixed and matched in any firewall rule.
- Use service accounts instead of network tags for strict control over how firewall rules are applied to VMs, as network tags can be inferred while using a service account would require access to it as well.
- A network tag is an arbitrary attribute. One or more network tags can be associated with an instance by any IAM member who has permission to edit it. IAM members with the Compute Engine Instance Admin role to a project have this permission. IAM members who can edit an instance can change its network tags, which could change the set of applicable firewall rules for that instance.
- A service account represents an identity associated with an instance. Only one service account can be associated with an instance. Access to the service account can be controlled by controlling the grant of the Service Account User role for other IAM members. For an IAM member to start an instance by using a service account, that member must have the Service Account User role to at least use that service account and appropriate permissions to create instances
Where do we need a VPC firewall with Service Account?
Firewalls provide the network defense for any infrastructure. Google Cloud VPC firewalls provide controlling network access to and between all the instances in your VPC. Firewall rules determine who is allowed to talk to whom and more importantly who can not. Configuring and managing IP-based firewall rules is a complex and manual process that can lead to unauthorized access if done incorrectly.
While running a complex application in a production environment, you must be familiar with service accounts in Cloud Identity and Access Management that provide an identity to applications running on virtual machine instances. The simplification of the application management lifecycle by providing mechanisms to manage authentication and authorization of applications provided by service account. They provide a flexible and secure mechanism to group virtual machine instances with similar applications and functions with a common identity. Security and access control are provided at the service account level.
when migrating any application to the cloud it scales up or down, and new VMs are automatically created from an instance template and assigned the correct service account identity. when the VM starts up, it gets the right set of permissions within the relevant subnet, so firewall rules are automatically configured and applied by using service accounts.
In this demo, I will create a Custom VPC network(VPC1) with two different subnetworks (subnet1 and subnet2). We will also create compute engine VM in each subnet to conduct the ICMP connectivity between them. To accomplish the connectivity between these VMs, we need to create a firewall rule in the ingress direction but there are three options when selecting the targets:
- All instances in the network.
- Specified network tags
- Specified Service Account
We will cover this demo with the last option with Specified Service Account and establish connectivity between the VMs. So to do this, I have already created a VPC with two subnets in the Mumbai region. I have also launched two VMs, one in each subnet. By default, the VMs are not reachable from the internet nor they can ping each other. So we will have to open some firewall rules to make it happen.
Step 1: Create a VPC and two subnets. I have already created it.
Step 2: Launch computes engine VMs in each subnet. I already provisioned it.
Step 3: Create a firewall rule to allow SSH connectivity from the internet so that we can log into each machine. you can create it manually or with the Gcloud command. Named this firewall rule “allow-ssh1”
gcloud compute - project=tcb-project-371706 firewall-rules create allow-ssh1 - direction=INGRESS - priority=1000 - network=vpc1 - action=ALLOW - rules=tcp:22 - source-ranges=0.0.0.0/0
Once done, your firewall rule looks like this:
Step 4: Create a firewall rule to allow ICMP (ping) between the VMs using the source and target as service accounts. “A VPC firewall rule is allowing traffic between source/targets based on the same service account”. Named this firewall rule “allow-icmp-vms”.
gcloud compute --project=tcb-project-371706 firewall-rules create allow-icmp-vms --direction=INGRESS --priority=1000 --network=default --action=ALLOW --rules=icmp --source-service-accounts=67822352893-compute@developer.gserviceaccount.com --target-service-accounts=67822352893-compute@developer.gserviceaccount.com
Once done, your firewall rule looks like this:
if everything is perfectly set, we should be able to see the VMs talking to each other. Let’s verify it.
To verify the connectivity:
- SSH to instance-1 from the console and then send a ping request to instance-2. You should be able to get a ping response.
2. SSH to instance-2 from the console and then send a ping request to instance-1.You should be able to get a ping response.
You can use service accounts to create firewall rules that are more specific in nature. Firewall rules that use service accounts to identify instances apply to both new instances created and associated with the service account and existing instances if you change their service accounts. Changing the service account associated with an instance requires that you stop and restart it. You can associate service accounts with individual instances and with instance templates used by managed instance groups.
Conclusion: VPC firewall with a service account ensures authenticated network separation between the different tiers of the application. This process is more manageable than maintaining IP address-based firewall rules, which can neither be automated nor templated for transient VMs