As we know the vpc firewall in GCP is a distributed firewall which means it is enforced at host/ vm level so I wanted to understand the benefits or use of creating multiple subnets in GCP.
Related
Is there an alternative to AWS's security groups in the Google Cloud Platform?
Following is the situation which I have:
A Basic Node.js server running in Cloud Run as a docker image.
A Postgres SQL database at GCP.
A Redis instance at GCP.
What I want to do is make a 'security group' sort of so that my Postgres SQL DB and Redis instance can only be accessed from my Node.js server and nowhere else. I don't want them to be publically accessible via an IP.
What we do in AWS is, that only services part of a security group can access each other.
I'm not very sure but I guess in GCP I need to make use of Firewall rules (not sure at all).
If I'm correct could someone please guide me as to how to go about this? And if I'm wrong could someone suggest the correct method?
GCP has firewall rules for its VPC that work similar to AWS Security Groups. More details can be found here. You can place your PostgreSQL database, Redis instance and Node.js server inside GCP VPC.
Make Node.js server available to the public via DNS.
Set default-allow-internal rule, so that only the services present in VPC can access each other (halting public access of DB and Redis)
As an alternative approach, you may also keep all three servers public and only allow Node.js IP address to access DB and Redis servers, but the above solution is recommended.
Security groups inside AWS are instance-attached firewall-like components. So for example, you can have a SG on an instance level, similar to configuring IP-tables on regular Linux.
On the other hand, Google Firewall rules are more on a Network level. I guess, for the level of "granularity", I'd say that Security Groups can be replaced to instance-level granularity, so then your alternatives are to use one of the following:
firewalld
nftables
iptables
The thing is that in AWS you can also attach security groups to subnets. So SG's when attached to subnets, are also kind of similar to google firewalls, still, security groups provide a bit more granularity since you can have different security groups per subnet, while in GCP you need to have a firewall per Network. At this level, protection should come from firewalls in subnets.
Thanks #amsh for the solution to the problem. But there were a few more things that were required to be done so I guess it'll be better if I list them out here if anyone needs in the future:
Create a VPC network and add a subnet for a particular region (Eg: us-central1).
Create a VPC connector from the Serverless VPC Access section for the created VPC network in the same region.
In Cloud Run add the created VPC connector in the Connection section.
Create the PostgreSQL and Redis instance in the same region as that of the created VPC network.
In the Private IP section of these instances, select the created VPC network. This will create a Private IP for the respective instances in the region of the created VPC network.
Use this Private IP in the Node.js server to connect to the instance and it'll be good to go.
Common Problems you might face:
Error while creating the VPC Connector: Ensure the IP range of the VPC connector and the VPC network do not overlap.
Different regions: Ensure all instances are in the same region of the VPC network, else they won't connect via the Private IP.
Avoid changing the firewall rules: The firewall rules must not be changed unless you need them to perform differently than they normally do.
Instances in different regions: If the instances are spread across different regions, use VPC network peering to establish a connection between them.
I have three separate GCP accounts. One account for productA, one account for productB and one account for devops monitoring. Each account has currently 1 project (more to be added in the future) which has multiple VMs. I want to monitor the VMs (for productA/project and productB/project) from the devops GCP account so I can consolidate the monitoring. The monitoring products are Promethesus, Grafana and Graylog (not GCP).
I am not using organisations at the moment (don't use gsuite or cloud identity)
Do I need VPC networking peering or shared VPC?
Any advice or recommendations on how to do this would be much appreciated.
Shared VPC allows an organization to connect resources from multiple projects to a common Virtual Private Cloud (VPC) network. If your resources are already in different projects, but using the same VPC, the shared VPC concept is already in place.
However, in your case it seems like your resources are using different VPC’s specifically to their own project. Here the concept for VPC peering can be used regardless of whether they belong to the same project or the same organization. It is possible to set up VPC Network Peering between two Shared VPC networks. Here is the Example on VPC Network Peering setup.
On Google cloud, I have setup new three projects - dev, research and prod. So, then created an Shared VPC Host and three Service Projects as listed above. Also intend to have separate VPCs for each of these service projects (to add more security layer), hence also intend to use now VPC Peering. But confused here can we configure both Shared VPCs and VPC Peering on same set of Projects?. If so then i do not find any links on this and also is this an right thing to do?
Peering and Shared have their own usage. With peering, you are limited to 25 per project and the transitivity isn't possible.
For example, with peering, if you set up a peering between dev and research and between research and prod; dev can't reach the prod (transitivity is forbidden), you have to set up a peering between dev and prod for this. The peering can be interesting when you want to share a VPN or Interconnect endpoint. You perform a peering between the interconnect project and these that want to reuse this connexion.
With share VPC, you don't have the transitivity limitation, all the VM can be in the same VPC, even if they are in different projects.
However, with this config, you break the project strong isolation, your dev project can access to the prod without limitation!
Thereby I recommend you to set up VM network with at least "2 legs": 1 in the shared VPC, the other in a project dedicated VPC. And then to set up the correct firewalls rules on your VPC network for limiting interactions in the shared VPC, but by keeping an unrestricted limitation at project level with the leg in the VPC project.
Peering:
Peering allows internal IP address connectivity across two Virtual Private Cloud (VPC) networks regardless of whether they belong to the same project or the same organization. you are limited to 25 per project and the transitivity isn't possible.
VPC sharing:
Shared VPC allows an organization to connect resources from multiple projects to a common Virtual Private Cloud (VPC) network, so that they can communicate with each other securely and efficiently using internal IPs from that network. When you use Shared VPC, you designate a project as a host project and attach one or more other service projects to it. The VPC networks in the host project are called Shared VPC networks. Eligible resources from service projects can use subnets in the Shared VPC network.
Q1: Is a hub & spoke model with vpc peering better compared to using a shared vpc. See below tenancy design in AWS, we are trying to bring a similar structure.
Q2: Is there any native service/virtual appliance(Firewall) or feature available to route traffic between spokes without spoke to spoke peering?
Q3: Cross account access – Is it possible to have cross-account access
Q4: Do we use Subnet to create zones in GCP, refer diagram above
Q5: Is there randomization of the zones in GCP as in AWS (Zone a in one account would be Zone b in another)
Q2: Is there any native service/virtual appliance(Firewall) or feature available to route traffic between spokes without spoke to spoke peering?
No, the VPC peering is not transitive in nature. This means that VPC A peered with VPC B, VPC A peered with VPC C would mean that VPC B cannot see or send ICMP traffic to VPC C.
Q3: Cross account access – Is it possible to have cross-account access
Yes, as long as there is a peering is established between all communicating accounts
Q4: Do we use Subnet to create zones in GCP, refer diagram above
Availability zones in AWS and Zones in GCP are comparable. Subnet's are further slicing down the VPC to create dedicated areas for inbound/outbound traffic management and resources placements
Q5: Is there randomization of the zones in GCP as in AWS (Zone a in one account would be Zone b in another)
Yes the zones are randomized in GCP and do not represent fixed or known locations all the times.
Q1: Is a hub & spoke model with vpc peering better compared to using a shared vpc. See below tenancy design in AWS, we are trying to bring a similar structure.
Regarding Q1, the merits of the solution depend on the features accounted for the suitability of the solution, that would be different for each case.
There are two approaches for this hub-and-spoke architecture: shared VPC and peered VPC.
Shared VPC [1] allows one organization to connect resources from multiple projects to a common VPC network, so that they can communicate with each other securely and efficiently using internal IPs from that network. There will be:
A host project
One or more other service projects attached to it
VPC Network Peering [2] allows private connectivity across two VPC networks which may belong to one or multiple projects or organizations.
[1] https://cloud.google.com/vpc/docs/shared-vpc
[2] https://cloud.google.com/vpc/docs/vpc-peering
I know it's old but needs a correction:
Q2 - yes, you can route between spokes via hub VPC if you have a routing VM in hub and a proper custom route via that VM. Hub needs to export custom routes and spokes need to import. Pretty standard design for threat inspection between VPCs.
Why can't we implement multiple network interface on a single VPC (Which has multiple subnets) in GCP? Where as it is possible in AWS and Azure.
I came across with a problem where I had to implement multiple network interface in GCP. But in my case, all the subnets was present in the single VPC network, I read GCP documentation and got to know that, in GCP it is not possible to have multiple network interface in a single VPC network, in order to implement multiple network interface, all the subnets must be in a different VPC network, where as its completely opposite in AWS and Azure.
In AWS - all network interface must be available in the same VPC, and cannot at network interface from other VPC network.
In Azure vNet - all network interface must be available in the same VPC, and cannot at network interface from other vNet.
Of course, VPC in google cloud is little different from AWS, as an example, Azure vNet and AWS VPC's are regional in nature where as in GCP it is global in nature. And there are several other difference as well.
Was just curious to know about this limitation in GCP which I got.
Your assumption is wrong. You cannot attach more than one network interface to the same subnet, but you can to different subnets in the same VPC.