Assigned
Status Update
Comments
ha...@google.com <ha...@google.com>
ge...@google.com <ge...@google.com> #2
I would like to add on to this
It would be great to have tags be applied at the VPC subnet level as stated. I have two major reasons as to why this would be an excellent addition.
1. When using a Shared VPC design, one of the key sellers is that admins can maintain rules and networking all from the Host project. The flaw with no subnet tags is that users in service must create their own tags. This causes an issue at point 2..
2) Using network tags in firewall rules is the best way to make granular rules. However if a user can control the network tags from their service project that causes an issue with consistency amongst the org. Having subnet level tags can enforce that I continue to use the network tag option in firewall rules as the target and network admins maintain that control and consistency. Also if I have many subnetworks in a VPCs i can have a firewall rule for a specific subnet instead of instance tags which is a problem when service account users have that control.
It would be great to have tags be applied at the VPC subnet level as stated. I have two major reasons as to why this would be an excellent addition.
1. When using a Shared VPC design, one of the key sellers is that admins can maintain rules and networking all from the Host project. The flaw with no subnet tags is that users in service must create their own tags. This causes an issue at point 2..
2) Using network tags in firewall rules is the best way to make granular rules. However if a user can control the network tags from their service project that causes an issue with consistency amongst the org. Having subnet level tags can enforce that I continue to use the network tag option in firewall rules as the target and network admins maintain that control and consistency. Also if I have many subnetworks in a VPCs i can have a firewall rule for a specific subnet instead of instance tags which is a problem when service account users have that control.
Description
What you would like to accomplish:
Select subnet route exchange on VPC peering and not peer all subnets.
How this might work:
When we create a VPC peering have the option to select the subnets that we want to peer.
If applicable, reasons why alternative solutions are not sufficient:
Alternative solution is to use a NAT instance, but this can be a performance issue.
Other information (workarounds you have tried, documentation consulted, etc):
This will help on managing IPs for GKE cluster, since with this we can have a isolated VPC for GKE clusters and then do a vpc peering with a shared vpc where only we route exchange the node ip subnet.