In giant Google Cloud environments, Shared VPC is a really scalable community design that lets a company join sources from a number of initiatives to a typical Digital Non-public Cloud (VPC) community, in order that they will talk with one another securely and effectively utilizing inside IPs. Usually shared by many software groups, a central crew (or platform crew) usually manages the Shared VPC’s networking configuration whereas software groups use the community sources to create functions in their very own service initiatives.
In some circumstances, software groups wish to handle their very own DNS information (e.g., to create new DNS information to reveal companies, replace current information…). There’s an answer to assist fine-grained IAM insurance policies utilizing Cloud DNS peering. On this article, we discover learn how to use it to offer your software groups autonomy over their DNS information, whereas making certain that the central networking crew maintains fine-grained management over all the atmosphere.
Understanding the Cloud DNS peering resolution
Think about that you simply, as an software crew (service undertaking) proprietor, need to have the ability to handle your individual software (service undertaking) DNS information with out impacting different groups or functions. DNS peering is a sort of zone in Cloud DNS that permits you to ship DNS requests from a particular sub-domain to a different Cloud DNS zone configured in one other VPC—and it permits you to do exactly that!
Cloud DNS peering is to not be confused with VPC peering, and it doesn’t require you to configure any communication between the supply and vacation spot VPC. All of the DNS flows are managed straight within the Cloud DNS backend: every VPC talks to Cloud DNS and Cloud DNS can redirect the queries from one VPC to the opposite.
So, how does DNS peering enable software groups to handle their very own DNS information? Through the use of DNS peering between a Shared VPC and different Cloud DNS zones which are managed by the applying groups.
For every software crew that should handle its personal DNS information, you present them with:
Their very own personal DNS subdomain (for instance <applicationteam>.<env>.<buyer>.gcp.com)
Their very own Cloud DNS zone(s) in a devoted undertaking, plus a standalone VPC with full IAM permissions
You may then configure DNS peering for the precise DNS subdomain to their devoted Cloud DNS zone. On this VPC, software groups have Cloud DNS IAM permissions solely on their very own Cloud DNS occasion and may handle solely their DNS information.
The central crew, in the meantime, manages the DNS peering and decides which Cloud DNS occasion is authoritative for which subdomain, thus permitting software groups to solely handle their very own subdomain.
By default, all VMs within the Shared VPC use Cloud DNS within the Shared VPC as their native resolver. This Cloud DNS occasion solutions for all DNS information within the Shared VPC, makes use of DNS peering to the applying groups’ Cloud DNS situations and VPC peering or forwarding to on-prem for on-prem information.
As detailed above, the circulation is the next:
A VM in any undertaking of the Shared VPC makes use of Cloud DNS as its native DNS resolver.
This VM tries to resolve app1.team-b.gcp.com, which is a DNS file owned by crew B that exposes a neighborhood software (a Compute Engine occasion or a Cloud Load Balancer).
This VM sends the DNS request to the Shared VPC Cloud DNS. This Cloud DNS is configured with DNS peering that sends every little thing below the “team-b.gcp.com” subdomain to Cloud DNS within the DNS undertaking for crew B.
Workforce B is ready to handle its personal DNS information, however solely in its devoted DNS undertaking. It has a non-public zone there for “*.team-b.gcp.com” and an A file for “app1.team-b.gcp.com” that resolves to “10.128.0.10”.
When the VM receives its DNS reply, it tries to achieve 10.128.0.10 utilizing the VPC routing desk. If the corresponding firewall guidelines are open, the request is profitable!
Are you interested by attempting out this resolution for your self? You could find an end-to end-example in Terraform, which provisions the next structure:
This Terraform code ought to assist you to get began shortly and might be reused to combine this design into your Infrastructure as Code deployment.
Within the above instance, we used a standalone undertaking devoted to DNS per software crew.
You can even use the applying crew’s service undertaking by creating a neighborhood VPC within the software undertaking and configuring DNS peering to this native DNS undertaking.
The tradeoffs are the next:
Safety and autonomy
Many organizations want the safety and centralized management that Shared VPC supplies. However with this structure primarily based on Cloud DNS peering, you can even grant software groups the autonomy they should preserve their very own DNS information—liberating the central networking crew from that burden! For extra on managing complicated networking environments, take a look at this doc on DNS best practices.