"Inherited" permissions not included in policy response

[david-crespo]

When a user has read access on an org (for example) they get read access on projects under that org. But when you pull the policy on a project, they will not show up in there because their role is on the org, not on the project. That means the Access & IAM page in the console for that project can be empty, even while the current user can clearly see the project because they're looking at it.

Not sure what the right solution is here, but it's a big problem on the frontend. The client could pull the org and silo permissions and merge them somehow, but that really feels like API logic. Since a given resources has a pretty short chain of parent resources, pulling the policy on each resource in the chain (e.g., project, org, and silo) might not be too bad and could be done in a single query. Maybe more interesting is figuring out how to represent that in the response in a reasonable way.

[davepacheco]

Yeah, this gets a little gnarly: when you PUT the policy, do you have to include those inherited role assignments? Do we allow the PUT resource to look very different than the GET one? Or maybe we make it a separate top-level property ("inherited_role_assignments") and model this like a PUT with whatever content-type means "if I leave a property out then I'm not changing it", and we don't allow you to change that property?

I had assumed the API would report the low-level facts and the console would be responsible for synthesizing this view but I can see why that might not be great. I'm curious what other systems do here.

[david-crespo]

True, the PUT is a bigger problem.

Just like the console is now pretending role assignment is an exclusive choice between read, write, and admin, we can have the console do that aggregation to see how it feels and then think about pulling it into the API.

[david-crespo]

Perhaps of interest:

Example

For project Access & IAM page, instead of only pulling <...>/projects/:projectId/policy and showing that, we also pull the policy for the org and the silo, and combine them somehow. This is a bit of design challenge because we want to indicate where a given permission came from, and if a given user has entries at multiple levels we need to show that somehow too. This complexity hints at why all this might be better as API logic — the API can use the same logic it uses to actually resolve the permissions when it decides how to aggregate them into a synthetic policy.

oxidecomputer/console#1024

[davepacheco]

This complexity hints at why all this might be better as API logic — the API can use the same logic it uses to actually resolve the permissions when it decides how to aggregate them into a synthetic policy.

It seems likely that the console will want to know which permissions came from where in order to display it usefully, right? With separate endpoints, it's clear where each permission came from. Of course, we can also add the source information to the response, too, but that solution feels more complex to me on both sides.

Relatedly: right now, effective role assignments can come from the Project, Organization, Silo, or Fleet. Would we want to show Silo- and Fleet-level permissions here? Even though users don't necessarily even know about Fleets? Maybe this is moot after #1340. Although you might still have Silo admins that can see a Project, and I'm not sure if we want to show them. I ask because having the console make separate requests makes it easy to choose which sources it wants to show. (I guess it could also just filter those out of the aggregated endpoint. But this choice affects API users, too: an ordinary user using the API would see all this stuff about Silo and Fleet admins.)

[david-crespo]

Closing as #1573 and oxidecomputer/console#1113 have us handling this on the client for now.