Assigned
Status Update
Comments
lb...@google.com <lb...@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.
fa...@google.com <fa...@google.com> #3
+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"
se...@myrepublic.net <se...@myrepublic.net> #4
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.
ha...@sap.com <ha...@sap.com> #5
Hello Colleagues ,
We also affected by this . Kindly check on this with priority and let us know when the feature will be done .
We see on all other Clouds , feature of rename on vpc subnets is available and we can do it without much efforts .
Thanks ,
Harirpasath.N
We also affected by this . Kindly check on this with priority and let us know when the feature will be done .
We see on all other Clouds , feature of rename on vpc subnets is available and we can do it without much efforts .
Thanks ,
Harirpasath.N
ha...@sap.com <ha...@sap.com> #6
Hello google colleagues ,
Kindly let us know , what is the ETA for this request , as this issue is open since 2018 .
Thanks ,
Hariprasath.N
Kindly let us know , what is the ETA for this request , as this issue is open since 2018 .
Thanks ,
Hariprasath.N
br...@brettjones.com <br...@brettjones.com> #7
+1 here. Renaming VPCs and subnets should be possible without deconstructing and rebuilding networks, a process which may involve multiple other parties.
br...@cannonballtrading.com <br...@cannonballtrading.com> #8
+1 here. Renaming VPCs and subnets should be possible without deconstructing and rebuilding networks, a process which may involve multiple other parties.
kt...@google.com <kt...@google.com> #9
Hello everyone,
Thank you for your ongoing patience. We know it's been a while since you don't hear back from us.
Be sure that we hear you, all new reports are being shared with the Product team. The Cloud VPC Engineering team is still working on this issue to provide a resolution.
Further updates, including a possible ETA will be posted in this thread.
to...@maxedadiygroup.com <to...@maxedadiygroup.com> #10
+1 here. Is not a nice to have feature; it is a should have functionality.
Thanks & regards, Tom
Thanks & regards, Tom
ro...@softchoice.com <ro...@softchoice.com> #11
this one is still open from 2018. I really can use this feature with my customer to properly follow the naming convention. when is the ETA?
pi...@gmail.com <pi...@gmail.com> #12
any movement here? The ability to have well defined naming convention is the key in the cloud. It's obvious and this feature should be implemented.
cc...@proveedorexterno.com <cc...@proveedorexterno.com> #13
any updates on this??
gu...@ig.com <gu...@ig.com> #14
+1 from me, would be good to be able to rename without destroying
ch...@rewe-group.com <ch...@rewe-group.com> #15
We would also like to know if there is any progress on this case. Can you provide an ETA ?
As said before, naming ressources is a key and we would like to change descriptions without rebuilding everything
Best Regards
Chris
As said before, naming ressources is a key and we would like to change descriptions without rebuilding everything
Best Regards
Chris
lu...@engdb.com.br <lu...@engdb.com.br> #16
+1 from me, deploying a brand new network just to change its name doesn't make sense. We believe it has to be a "should have" functionality.
iv...@ultimatesoftware.com <iv...@ultimatesoftware.com> #17
Bump
Description