Update documentation of required RBAC permissions

[arielshaqed]

docs/security/rbac.md contains a description of required permissions but some calls are missing. AFAIK it is manually generated, so naturally it is out of date.

Update it to current state. If possible, refactor controller.go and somehow auto-generate it.

One way to refactor would be to use a map of permissions to pass to c.authorize. Then write code to generate a nice Markdown table from a new lakeFS command.

[Crossbears]

i would like to pick up this one.

[itaiad200]

All yours @Crossbears - feel free to ask here if you need any guidance

[itaiad200]

@Crossbears are you still on it?

[tkalir]

@arielshaqed what map did you have in mind?

If I understand correctly we need to extract the mapping between operation handler and the permissions they require, in a way that can be used by both code and documentation.

I thought of creating a map that maps operation handler (or operationId) to a structure like permission node, with Resource being an enum (for arn type) or function pointer that can be used to generate the arn according to input. Then this structure can be used to generate the permission node that authorize() requires.

Anyway, input will be appreciated.

[arielshaqed]

Sorry, @tkalir , dropped this one.

I think your suggestion is great, it definitely aligns with the little text I did write! So here's a detailed suggestion (doesn't need to happen like this).

• Create a map from operation name to a special NeededPermissions object. (A bit tricky, this object needs placeholders for things like "the repository" and "the user" and "the path"!).
• In every action in controller.go, extract operationName to a const. For instance, for CreateRepository this appears as a literal in the operation log. But also keep (or discover?) the OpenAPI operation name.
• Use that operationName to index the map, then get it to authorize the operation. (For instance method NeededPermissions.Authorize might take an additional struct parameter with fields Repository, Path, User, etc., each of which can be nil - and use the fields it needs for its placeholders).
• ALSO add a controller method that generates MarkDown describing required permissions by OpenAPI operation name. The hardest part here will probably be sorting it correctly; perhaps use the ordering in swagger.yaml?

[tkalir]

Hi @arielshaqed I created a small draft in the form of a PR get feedback on what I intend to do.

If this direction looks good, I noticed that the information in objects like the one returning from CopyObjectPermissions could be represented in a YAML file. Theoretically, each item in the YAML can have the swagger operationId, the operation name and a permissions section which is basically the permission template in text form. This would allow us to use code generation for functions like CopyObjectPermissions and the permission factory map. But if you think it should be left as code first, I can write these functions manually.