Graylog2 / Graylog2/graylog2-server
Replace wildcard admin role with composite role
- Dominant language
- Java
- Stars
- 8.1k
- Forks
- 1.1k
- Avg merge
- 1d 20h
- Merged PRs (30d)
- 217
Description
The built-in administrator role should be a dynamic combination of all other built-in roles instead of consisting of simply the `*` wildcard permission.
It is a convenient catch-all role for accessing everything in a Graylog cluster. However, it makes it hard to ensure that permission boundaries are correctly set and to break out smaller-scale admin-like roles.
During development and in small clusters, users are almost exclusively working with this wildcard permission role, so these users do not experience any permission checking conflicts (e.g., discrepancies between UI and backend checks, transitive dependencies in permissions, etc).
## Possible Solution
Create the ability to compose roles out of other roles dynamically.
Specifically, the `Administrator` role, and possibly other admin-like roles, should be made up of more dedicated roles, without requiring constant maintenance of dozens of role assignments.
This capability doesn't need to be exposed to users at this point.
The goal is to have feature parity between the current wildcard permission role and a future global admin role that is composed.
Further steps will define a small set of composite roles (the filter criteria to be used is to be determined) for more dedicated roles, e.g., for managing certain aspects of the system.
## Context
Running Graylog with a wildcard permission as the default role masks permission check inconsistencies. Forcing roles to be consistent as development happens will ensure that they will no longer be an afterthought.
Contributor guide
Assessment
This issue has not been assessed yet.