I’m currently trying to come up with an “enterprise-friendly” way to organise my hosts. I’m well aware of (super) groups, permissions, roles and object ownership but I’m struggling to put it all together.
How do I organise a 1000+ hosts properly to map them to departments, teams and admins - all with their corresponding sets of permissions to view/edit/execute?
Can this be done using the Community Edition or does the Enterprise Edition provide some additional features to accomplish this? Or maybe am I looking at this problem all wrong and the Greenbone use case is totally different from what I’m trying to set up?
I’d appreciate any insights or real world examples if there are any!
unfortunately I wasn’t able to map Greenbone’s data structure to my needs. I ended up running all the scans from a single account and sharing everything read-only with my team members.
I kind of got around the whole problem by exporting all the findings via python-gmp and bringing them into our Checkmk site where I can set up alerts, visibility and everything according to our internal structures.
But in terms of an Greenbone-only solution I’m sorry to disappoint.
For anyone wondering how to get around this:
solution was to
setup one web-admin via the greenbone ~cli interface
login to web with that web-admin
setup more users (e.g. user-specific-logins)
create a group e.g. see-all-objects (note this needs to be a special group
for each users-specific-login repeat 5.X
5.1. enter details page for the user-specific-login
5.2. copy GUID out of URl https://example.com/user/
5.3. Go to permissions https://example.com/permissions
5.4. add a new permission
Name: Super (has super access)
Subject: Group “see-all-objects”
Resource Type: User
user ID:
Add all users to the group see-all-objects
Logout of web-admin
Login to one user-specific-login
setup & run a scan
logout & login with different user-specific-login
see all the created assets/reports/etc.
Background: this works, because the users that are the owners of the tasks/targets/assets/etc. are NOT ~system-admins (as the web-admin) is
And stuff owned by ~system-admins is not visible to ~lower tier admins aka. admins created via the web-interface.
Therefore: modus operandi: use the cli-created accounts only for setup of user-accounts, but not for anything else.