feat: Add initial AuthzQuerier implementation
- Adds package database/dbauthz that adds a database.Store implementation where each method goes through AuthZ checks
- Implements all database.Store methods on AuthzQuerier
- Updates and fixes unit tests where required
- Updates coderd initialization to use AuthzQuerier if codersdk.ExperimentAuthzQuerier is enabled
* chore: Implement standard rbac.Subject to be reused everywhere
An rbac subject is created in multiple spots because of the way we
expand roles, scopes, etc. This difference in use creates a list
of arguments which is unwieldy.
Use of the expander interface lets us conform to a single subject
in every case
* chore: Authz should support non-named roles
Named roles are a construct for users to assign/interact with roles.
For authzlayer implementation, we need to create "system" users.
To enforce strict security, we are making specific roles with
the exact required permissions for the system action.
These new roles should not be available to the user. There is a
clear code divide with this implementation that allows a RoleNames
implemenation for users to user, and system users can create their
own implementation
* feat: Implement allow_list for scopes for resource specific permissions
Feature that adds an allow_list for scopes to specify particular resources.
This enables workspace agent tokens to use the same RBAC system as users.
- Add ID to compileSQL matchers
* Plumb through WithID on rbac objects
* Rename Scope -> ScopeName
* Update input.json with scope allow_list
Co-authored-by: Cian Johnston <cian@coder.com>
* chore: More complete tracing for RBAC functions
* Add input.json as example rbac input for rego cli
The input.json is required to play with the rego cli and debug
the policy without golang. It is good to have an example to run
the commands in the readme.md
* Add span events to capture authorize and prepared results
* chore: Add prometheus metrics to rbac authorizer
* test: Unit test to assert role permissions
This unit test allows for asserting which roles can perform
actions on various objects. This is much easier than making
unit tests to hit the api.
