Assigned
Status Update
No update yet.
Comments
ch...@google.com
ch...@google.com
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.
ge...@google.com
+1 for Canva, they'd like to do this.
Labels for metadata would help consumers of a shared vpc understand what subnets are for "proxy subnet for load balancers, etc"
sc...@recursion.com
I agree with the previous commenters regarding the utility of subnetwork tags.
Currently our network engineering team sends a list of all shareable VPC subnetworks from the the host project to a central security team for whitelisting under Organization Policies. Although the network engineering team does not create new subnetworks often, it does add an extra step for them if they wish to share the new subnetwork. If we can allow VPC subnetworks to be taggable by the network engineering team, they would be able to enable the sharing of the new subnetwork conditionally based on the application of the policy tag.
Currently our network engineering team sends a list of all shareable VPC subnetworks from the the host project to a central security team for whitelisting under Organization Policies. Although the network engineering team does not create new subnetworks often, it does add an extra step for them if they wish to share the new subnetwork. If we can allow VPC subnetworks to be taggable by the network engineering team, they would be able to enable the sharing of the new subnetwork conditionally based on the application of the policy tag.
Description
Please describe your requested enhancement. Good feature requests will solve common problems or enable new use cases.
What you would like to accomplish:
Transitivity between VPC peering.
How this might work:
When creating a hub & spoke infrastructure using VPC peering, we find some issues when trying to expose managed services like Apigee, Cloud SQL, etc.
Having transitive peering could make it easy to connect all the infrastructure in a hub & spoke design.
If applicable, reasons why alternative solutions are not sufficient:
At this moment some solutions are:
- Using Cloud VPN. Depending on the traffic, security policies, etc. this solution might be not a right solution.
- Creating a peering between the hub VPC and a VPC with all the Google Managed services. This will solve the transitivity issue, but can change some components on the initial infrastructure.
- Creating a network appliance. You could use a router appliance between the 2 peerings in order to route the traffic. This is not a Cloud native solution and you need to take care of your VM's, licenses, etc.