oxidecomputer / oxidecomputer/omicron
Explore enabling create_child permissions on VpcSubnets for limited-collaborator users
Nobody has claimed this yet.
- Dominant language
- Rust
- Stars
- 572
- Forks
- 97
- Avg merge
- 2d 12h
- Merged PRs (30d)
- 96
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.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the permission checks and Polar rules discussed in #9299, especially the VpcSubnet create_child behavior for limited collaborators. Determine whether the permissions model now supports the needed distinction, then document or implement the agreed policy and validate the network-interface creation path.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust
- Domain
- authorization, networking
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100