Skip to content

Explore enabling create_child permissions on VpcSubnets for limited-collaborator users #9328

@charliepark

Description

@charliepark

Situation
In #9299, we ran into an issue: For a user to create a network interface, we had two checks in place:

  1. Can this user create_child on the NIC's parent Instance?
  2. Can this user create_child on 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 a limited-collaborator would be able to create NICs, even though they don't actually have VPC Subnet create_child permissions.

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions