Policy enforcing on users

[CDimonaco]

Description

This pr creates the bodyguard policy for user management endpoints.
We create default abilities and attach them to default admin in the release task.
The /api/v1/users endpoints are protected. Only accessible to all:all or users:all

How was this tested?

Automated tests

[arbulu89]

Hey @CDimonaco
The code looks great in general.
My unique real concern is that we don't test the policy completely.
For example, the users:all ability is not tested.
I think we should have pure tests for the policy itself (together with the controller if you want).
They are so easy to test that it doesn't look a big deal.

[arbulu89]

Nice @CDimonaco
Thanks

[arbulu89]

What is this test for? I would expect some refute as the test talks about disallow, but checking it, i think we can just simply remove it

[CDimonaco]

I refactored the test, for some reason I had the working copy not committed lol

[gagandeepb]

I wonder if you've considered having a module attribute as a named constant for the numeric value 1?

[gagandeepb]

A named constant here for the value 1, e.g. ability_id_for_all could be interesting to consider, since the numeric id has a special meaning.

[gagandeepb]

I wonder what were the considerations to make it necessary to load abilities from the db? For instance, I'm curious why can't there be static abilities, i.e. at the code level? (Maybe I'm thinking too much along a role-based approach, and there is a different/more granular approach that has been agreed here for this.)

[arbulu89]

Because using migrations is really convenient to execute/rollback the actions.
Otherwise, we would need to add seeds/release actions to add them. And the same would happen if you want to remove. You would need to explicitily remove them in the code, which would become error prone

[gagandeepb]

I see, thanks for the explanation. My comment was a bit broader, though, on the overall approach of loading/storing abilities in the db in the first place, but I guess maybe that is necessitated due to the access control meta-approach considered (RBAC vs granular ability based, etc.).
On a somewhat side note: I have been reading a bit into Cedar recently, and they have some interesting ideas about checking/validating static policies that are decoupled from the application code completely, using some formal methods/tools that give better assurances. It might be interesting to evaluate too, at some point.