Graylog 4.0 introduced a completely new way of assigning permissions to users. The new version splits up the various sections of the permission and authentication system:
There are five different parts to it:
Teams and Sharing provides organizations with large user groups and multiple teams accessing Graylog to manage their own content on a day-to-day basis more efficiently. By giving individual teams and users control over their own content needs, these features reduce the time administrators spend responding to access and dashboard requests.
First, Graylog syncs with your organization’s authoritative identity source, such as Active Directory or LDAP, so that users are automatically provisioned into Graylog with the appropriate rights and permissions. Then, Graylog auto-populates access using the current roles and AD or LDAP groups, reflecting the organizational permissions structure. However, organizations can still manually manage access and permissions if necessary.
Second, Graylog Enterprise users can create Teams that can be easily found through a natural language search. For example, you can create teams such as “Security Team,” making it easier to find users with similar data needs. Graylog Enterprise leverages your authoritative identity source to populate Teams. The Teams functionality allows you to separate users into smaller groups within the organization, containing dashboards and reports to those assigned Teams and reducing informational noise generated from an excess of reports.
For smaller teams, the lack of Group Mapping has little impact. Group Mapping and Teams primarily prevent an overabundance of reports showing up in Users’ streams and dashboards. For smaller organizations using Open Source, removing this functionality has little impact. For Enterprise customers, Group Mapping and Teams enables them to reduce the proliferation of reports across all users, confining information to those who need it, reducing noise, and enhancing security.
Graylog had pluggable authentication providers for a long time, but we have updated them for 4.0. In 4.0 only one external authentication provider can be active. We have removed the UI around changing the order these providers run, as there was practically no usage of this feature and it made reasoning about what happened in the background very difficult for the user.
Both LDAP and Active Directory continue to be available out of the box for Graylog Open Source and we have no plans on changing this. We believe that user access control is an essential feature of a logging solution. We have also added the “trusted HTTP header” authentication method to Graylog. This feature, in conjunction with a proxy server, is sometimes used to enable authentication providers that Graylog does not have support for, such as keycard systems, Kerberos, and others.
Both LDAP and Active Directory now support the synchronization of teams. Because teams are only available in Graylog Enterprise, the Open Source product no longer has Group Mapping.
In Enterprise Graylog will synchronize chosen LDAP/AD groups to teams when an authentication service is activated. Graylog will then keep the team members up to date as they log into the system.
Teams created in this way cannot be manually managed in Graylog, they have to be managed in the original identity provider. This means you cannot add or remove members from the team, but you can (and should) configure the roles the team brings with it.
The User section shows a list of existing users including additional information that is useful to get a quick overview.
There is a new user view screen, that was not present in earlier versions. It shows basic profile information, the assigned roles, team membership for this user, and the “entities” that the user has been granted access to. Entities are things like Streams, Saved Searches, Dashboards, Alert Definitions, and Notifications.
The corresponding “Edit User” screen contains the same information but allows changes to profile information according to the permissions the user has (e.g. they cannot add themselves to arbitrary groups etc).
In 4.0, Roles have a more central position. While Graylog still has some of the same Roles, such as Administrator and Reader, it also includes some new ones. Since roles no longer contain information about which access is granted, it makes no sense to map LDAP/AD groups to them, and without Teams, there is no way to automatically group users.
Starting in 4.0, roles in general only describe capabilities. For example, you can now assign Roles like “Dashboard Creator”, “Event Definition Creator”, and “Event Notification Creator”. These Roles are now actions that users can take within Graylog. This permission system is based on grants, like in a database, where it records access to entities based on user access levels. This shift enhances an organization’s security posture by enabling organizations to limit access more precisely within the Graylog platform, reducing excess access risk.
Additionally, since Graylog 4.0 now supports “sharing” functionality, granting access to streams and dashboards is no longer part of the “edit Roles” capability. Standard out-of-the-box roles are:
Event Definition Creator
Event Notification Creator
With Graylog 4.0, Roles no longer define what entities a user can see, but the types of actions they can take. With this update, organizations no longer have the need to create custom roles.
For organizations upgrading to Graylog 4.0, the server will look at each user’s capabilities and access levels then migrate that to the new sharing system.
The information which specific entity a user or team has access to is managed through “sharing” on the entity itself, not through a role.
As an example, in earlier versions of Graylog, to give access to a stream containing windows logs and the corresponding dashboard visualizing them, an administrator had to create a role: “Windows Logs”, having “Stream Windows Logs” as “Allow Reading”, and “Dashboard Windows Logs” as “Allow Reading”. This role was then assigned to a user, either manually or via a group mapping.
In 4.0, there is no special role necessary for this access. Instead, the Administrator grants access to the stream, and either the Administrator or another owner of the dashboard shares access to the entities with a specific user or team. For most of the process, the user sharing the access does not have to have administrator-level access.
Roles now only govern what actions someone can take, but do not themselves state on which entities these actions can take place. The latter is done through the sharing dialog. (see the later section for details)
In 4.0 the UI does not allow defining new roles, even though this is still possible through the API. As there is much less need to create custom roles, we believe this is acceptable initially, but we plan on making custom roles possible in future releases.
Providing Dashboard Creation Access¶
Before users can create their own Dashboards, you need to provide them the appropriate level of access.
Under the “System” dropdown menu located in the top menu, click on the “Users and Teams” option. Choose the User record that you want to update.
In the “Assign Roles” menu, you can change the individual user’s permissions to better align with their job function. In this case, the user, Alice, needs to be able to create Dashboards. Click on “Dashboard Creator,” then click “Assign Role.” Graylog automatically updates the user’s account, granting the necessary access immediately.
After providing “Dashboard Creator” access to users, they will be able to see the “Create a Dashboard” button on the upper right-hand side of their Dashboards view.
Teams join users and roles together. Users can be in any number of teams, from zero to multiple teams. Each team can be assigned any number of roles, from zero to multiple many roles, which are added to the team’s members when checking for permissions.
Currently, team management requires an Administrator account. Now that Roles have transitioned to defining capabilities, Administrators can use Teams as a way to provide Roles to multiple users at once, rather than providing the capabilities individually. For large organizations, this reduces the amount of time spent managing individual user access.
Creating a team requires minimal information about it and allows assigning roles and members directly:
For example, if an organization has 10 Teams with 5 people on each Team, the Administrator can change Roles in bulk rather than having to manage all 55 users individually. Additionally, Administrators spend less time focusing on Role and Permissions within Graylog as they can apply unique sets of Roles to each Team without worrying that one User will have too much or too little access to engage in their job function.
AD/LDAP Synchronization with Teams¶
Enterprise organizations can leverage AD/LDAP synchronization, using their authoritative identity source to populate Teams. When a new user is added to the identity source of record, that user is automatically provisioned to the appropriate Graylog Team with all the Permissions everyone else in the Team has.