-
Notifications
You must be signed in to change notification settings - Fork 63
Description
Situation
In #9299, we ran into an issue: For a user to create a network interface, we had two checks in place:
- Can this user
create_childon the NIC's parent Instance? - Can this user
create_childon the Subnet where it will be attached (and where the IP address will come from)?
This was a problem, because we were trying to create a situation where alimited-collaboratorwould be able to create NICs, even though they don't actually have VPC Subnetcreate_childpermissions.
We updated the second check, to confirm that the user has read permissions on the Subnet.
Complication/Context
@davepacheco noted that that isn't a problem for now, as our permissions model isn't fine-grained enough to handle different permissions for different subnets. But a future permissions model likely will allow for per-subnet permissions, and in that world, we'll want to think about how to address the permissions for NIC creation by limited-collaborators.
His full comment:
I think the idea behind the original check was that you need to be able to allocate IPs on the subnet. That is: imagine a world where you might have privileges to use some subnets but not others. You'd need a privilege check that you can actually create an allocation in this subnet.
This cannot come up today since we don't support that level of granularity. But this code isn't supposed to be assuming that -- it's supposed to check the privileges it truly needs and let the policy deal with whether it should always have it or what.
I guess the right fix is to tweak the Polar rules for VpcSubnet to allow CreateChild even for limited collaborator. I imagine that's not worth doing right now given the urgency. This isn't a huge deal since it doesn't affect behavior right now and may not ever even come up, but it would be a surprising oversight if/when we ever did make this more fine-grained. Maybe file an issue?
So no action needs to happen right now, but as we evolve our permissions models around networking resources in the future, we should revisit this. And, even before then, as Dave says, we might want to adjust the Polar rules around VpcSubnets.