Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
RFC: Implementing RBAC #1333
I wanted to get some feedback on a proposal for implementing simple RBAC into Gophish.
To keep things simple, right now each user in Gophish is completely separate, and has all the same permissions. There’s no such thing as roles, or the ability to limit users from doing certain things.
This worked well enough so far. There’s been the occasional issue filed about wanting RBAC (including one from me!), but it’s never given us enough benefit to make it worth the effort compared to other features.
Now that Gophish is getting more mature, I think it’s time to reconsider adding RBAC- at least, to a limited extent. My goal is to start small and simple, only building out when we need to. To start, I want to create three roles:
Here's a little bit about the goals for each role and what we aim to accomplish.
Right now, every user is pretty much an administrator. This works fine in smaller teams, but for enterprise users there may be a separation between the team that manages the Gophish infrastructure and the team that launches the phishing simulations.
The Administrator role aims to limit system-level administration to a smaller number of users. To start, this would include:
I have to include URL management since URLs will need to be shared amongst all users due to needing consistent TLS settings.
The user role will be able to do everything an administrator can do, with the exception of managing other users or system-wide settings like URLs. They will be able to interact with objects like sending profiles, groups, etc., as well as launching and viewing the campaign output.
The viewer role will be a read-only role. Users with this role will not be able to do any kind of system-management, or create/edit any objects. They will only be able to view objects and campaign information.
I'd love your feedback
This is a simple start, but hopefully it should hopefully take care of quite a few use cases while adding limited complexity. We can always expand this out later, but if anyone has feedback on this initial proposal, I'd love to hear your thoughts!
This is pretty much exactly as I would want it implimenting. I'd had a look at this a while back and I was considering having a crack at it (as there aren't that many direct mentions of the current user that you'd have to change to allow this to work), but this seems to be more comprehensive than my first attempt was going to be :)