Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Check permission "auditing" #1414

Open
mworzala opened this issue Jun 28, 2023 · 0 comments
Open

Check permission "auditing" #1414

mworzala opened this issue Jun 28, 2023 · 0 comments
Labels
kind/proposal Something fundamentally needs to change state/gauging interest This needs to be championed before being worked on state/needs discussion This can't be worked on yet

Comments

@mworzala
Copy link

Started from this Discord thread.

I would like to implement an audit log when particular administrator permissions are used. Starting from the global permissions example, this would mean recording every time a permission check resolves using the platform->super_admin permission.

Some potential solutions and drawbacks summarized are:

  1. Using the explain API to check the evaluation of a permission on every call. This has a performance implication (calling explain for every check), and the permission check is not deterministic so will not consistently indicate that the super permission was used if the user has access to the resource in addition to the super permission.
  2. Check both the resource permission and platform->super_admin in parallel, if the user has super_admin then log. This does not allow avoiding the log if the user has permission for the resource directly.
  3. Adding a caveat which never has a value to the platform administrator relation. This way, when the super_admin branch is incountered, spicedb is forced to evaluate the other (direct access) branch. If the user has direct access, the check will return HAS_PERMISSION, otherwise it will return MAYBE_HAS_PERMISSION because of the unfilled caveat.

There is an incomplete proposal here to add some marker in the schema indicating that a field is "auditable", which would include it in the check response if matched. Unfortunately, this idea is unhelpful as long as the permission check is not deterministic. Perhaps an auditable branch must be resolved in every check, however I am not knowledgeable to say how problematic this is with regard to performance.

@josephschorr josephschorr added the state/needs discussion This can't be worked on yet label Aug 4, 2023
@josephschorr josephschorr added the state/gauging interest This needs to be championed before being worked on label Sep 1, 2023
@jzelinskie jzelinskie added the kind/proposal Something fundamentally needs to change label Mar 6, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/proposal Something fundamentally needs to change state/gauging interest This needs to be championed before being worked on state/needs discussion This can't be worked on yet
Projects
None yet
Development

No branches or pull requests

3 participants