Status Update
No update yet.
Comments
ka...@google.com
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"
wi...@google.com
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.
jh...@google.com
ge...@google.com
Since 297898006 is an issue visible only to Googlers, and since this issue is publicly visible, it's helpful to re-open this so our shared customers and colleagues outside of Google know what's going on. Thank you, Wiktor and John, for bringing clarity to the issue. I wasn't quite sure what
Problem statement
- Suppose an IAM principal (user, group, service account) has been granted the
compute.orgFirewallPolicyAdminrole via binding in the IAM policy of an example folder. Further, suppose that the same IAM principal does not have any bindings which grant it thecompute.globalOperations.getpermission in the IAM policy of the parent organization.- To dispel confusion, if the IAM principal does have a binding which grants it the
compute.globalOperations.getpermission in the IAM policy of the parent organization, there is no problem.
- To dispel confusion, if the IAM principal does have a binding which grants it the
- Suppose that the IAM principal attempts to create a hierarchical firewall policy at the same level of the example folder, using
gcloudor the Terraform module. An examplegcloudcommand is:gcloud compute firewall-policies create --folder=FOLDER_NUMBER --short-name=POLICY_NAME - Because the IAM principal has been granted the
compute.orgFirewallPolicyAdminto the example folder, and because thecompute.orgFirewallPolicyAdminrole includes thecompute.firewallPolicies.createpermission, thegcloudcommand from (2) – or its equivalent by using Terraform – does successfully create the firewall policy.- To dispel confusion, the newly-created hierarchical firewall policy is not "orphaned" – it's fully functional, and can be deleted if desired.
- However, if the IAM principal does not have any bindings which grant it the
compute.globalOperations.getpermission in the IAM policy of the parent organization, there's no way for the IAM principal to interrogate the operation for its status. This leads to an unexpected HTTP 403 Unauthorized error, so unless the IAM principal issues a subsequent command to list hierarchical firewall policies, that principal is likely unaware that the hierarchical firewall policy has been created!
An astute observer would note that the compute.globalOperations.get permission is included in the compute.orgFirewallPolicyAdmin role. The issue in play here is whether the IAM principal has been granted the compute.globalOperations.get permission in the IAM policy of the organization itself. Because creation operations for hierarchical firewall policies are currently scoped to the whole organization, the IAM principal having the compute.globalOperations.get permission on the folder where the hierarchical firewall policy is created is irrelevant.
Next steps
We're discussing this issue internally, thinking about ways we can remove or better explain this unexpected HTTP 403 error. Even though the HTTP error is unexpected, the hierarchical firewall policy is only created if the IAM principal has the permission to do so.
ge...@google.com
We'll use the internal 297898006 issue as the parent of this issue.
Description
- Prerequisites: Using an account that lacks organization level privileges.
--> When creating a firewall policy using the CLI, the command will error with a 403 unauthorized error, which is expected. However, the resource still gets created on GCP without user notice.
result: orphan resources.
What you expected to happen:
If an error occurs, the creation of the firewall policy should be reverted.
Steps to reproduce:
- authenticate as a service account that lacks organization level privileges.
- execute following command "gcloud compute firewall-policies create --short-name=my-policy --folder=123456789"
Solution proposed:
Whether check if the user has enough privileges before the creation, or revert the creation when an error occurs.