Why Graylog roles decide who sees which logs
Least-privilege access in Graylog starts from one question: which logs should each team be able to search, and which actions should it be allowed to take on them? When logs from several systems land in one Graylog, the default position of giving every analyst broad search is rarely acceptable. A payroll system, a domain controller and a public web tier may carry different sensitivity, and the people who troubleshoot one should not automatically read the others. Least-privilege access combines three things: roles that grant specific actions, sharing that exposes particular streams and dashboards to particular users, and teams in Graylog Enterprise that group people so access is managed once rather than user by user. Each layer answers a different part of the question, so a gap in one is easy to miss.
Plan this work before go-live, while the stream layout and the list of data owners are still changing. Once dashboards, saved searches and alerts exist and people have been working in a shared view for months, untangling who can see what is slower and riskier. It becomes urgent when a new source with restricted data is onboarded, when a team changes or a contractor needs temporary access, or when an auditor asks who could read a given log. Decide who owns each data source and what each group needs to do with it before anyone builds a role.
Role, permission and sharing names change between releases, and the current documentation covers version 7.2. Confirm the exact role names, permission strings, sharing options and any Enterprise-only team features in the Graylog version you run before writing an access matrix or automation. Test each role with a non-administrative account in a staging environment, because an access model that looks correct on paper often grants more than intended through a shared dashboard or a stream a user was never meant to reach.
Which access model fits each team
This table compares the ways a Graylog team can control who searches which logs, including what each mechanism controls, the edition it needs and when it fits. Read each row against your directory, identity provider and license before choosing a model, because most organizations combine two or three of these mechanisms.
| Mechanism | What it controls | Edition needed | When it fits |
|---|---|---|---|
| Built-in user roles | Actions a user can take in Graylog, such as searching, editing dashboards or managing inputs, assigned per account | Graylog Open | Small teams with few administrators, or a lab where directory integration is not yet in place |
| Active Directory or LDAP group mapping | Graylog roles assigned from directory group membership, so access follows joiners, movers and leavers in the directory | Graylog Open | Organizations that already manage access through AD or LDAP groups and want one source of truth |
| Trusted header authentication | Identity passed to Graylog by a reverse proxy or gateway in a request header, with roles then set inside Graylog | Graylog Open | Environments where a front-end proxy already authenticates users, and where the proxy is locked down so headers cannot be spoofed |
| SSO group mapping (Okta, OpenID Connect, SAML) | Graylog roles derived from identity provider groups or claims at sign-in | Graylog Enterprise | Organizations standardizing workforce sign-in on one identity provider and needing SSO for Graylog |
| Stream and dashboard sharing | Which users or roles can view or edit a given stream or dashboard, limiting the logs they reach | Confirm for your version | Splitting access by data owner, such as one team's application logs without another team's security logs |
| Teams | Grouping users so that shared content and permissions can be granted to a team in one step | Graylog Enterprise | Larger deployments where many users join and leave teams and manual per-user sharing becomes hard to review |
| Input creation restriction | Which roles can create or change inputs that receive log data | Confirm for your version | Keeping data source onboarding with platform administrators while analysts search only |
How to set up least-privilege access in Graylog
This sequence turns a flat Graylog instance into one where each team sees only the streams, dashboards and inputs it needs, with a non-admin test confirming the boundaries hold before anyone relies on them.
Inventory log sources and the teams that need them
Start by listing every log source Graylog will receive, such as firewalls, Linux hosts, application logs and cloud audit feeds, and the teams that investigate each one. Record which sources contain regulated or sensitive data, since those are the ones where access needs the tightest grant. Done when every source has a named owning team and a short list of readers, reviewed by the team leads who will approve access.
Map each team to the stream set it needs
Translate the inventory into a matrix of teams and streams, marking which team needs search, dashboard or alert access on each stream. Keep the matrix small by grouping sources that share a sensitivity level into one stream where your routing allows it. Done when every stream has at least one owning team and no team's proposed grant includes a stream it has no documented need for.
Decide which identities are local and which come from a directory
Decide which accounts are created directly in Graylog and which come from Active Directory, LDAP or another identity source. Graylog Open supports Active Directory and LDAP as well as trusted header authentication, while Graylog Enterprise adds Okta, generic OpenID Connect and SAML single sign-on, so confirm your edition before designing around SSO. Keep a small set of break-glass local administrator accounts outside the directory. Done when each user population has one documented source of truth and a tested sign-in path.
Create roles and map them to permissions
Create roles that match the matrix from the earlier step, granting only the actions each team needs, such as reading search results or viewing dashboards, and keep administrative permissions in a separate role. Map directory groups to these roles where the identity source supports it, so membership changes flow from the directory. Done when each role lists its permissions in the Graylog interface and an administrator can explain why each permission is there.
Share streams and dashboards by team
Where your edition supports sharing with teams, grant access to streams and dashboards through the team rather than to individual users, so that a new analyst inherits the right view on joining. If your edition does not offer teams, share to the smallest set of named users and record that as a known gap to revisit. Done when each stream and dashboard shows only the teams or users in your matrix as sharing targets.
Restrict input creation to platform administrators
Limit the ability to create and edit inputs to platform administrators, since an input can accept data from any network source and change what reaches the index. Remove input permissions from every other role, including dashboard and search roles. Done when a non-administrator account opens the inputs page and cannot create, edit or start an input.
Test access with a non-admin account
Create a test user holding only one team's role and sign in with it. Confirm it can search and view the granted streams and dashboards, and confirm it cannot see a stream outside its grant, even by searching across all streams or opening a shared link to a dashboard it was not given. Repeat for one user from each team, and record the results. Done when every test account behaves as the matrix predicts, and any mismatch is fixed and retested before go-live.
Schedule periodic access reviews
Set a recurring review in which each team lead confirms the members, roles and shared streams they own, and removes access that no longer matches the matrix. Keep the review record with the matrix so an auditor can trace who could see which logs at a given time. Done when the first review is signed off and the next review date is recorded with the owner who runs it.
Where least privilege usually breaks
Least privilege in Graylog rarely fails in the role model itself. It fails in the places around it: convenience grants, broad sharing, input creation, stale accounts, stream routing and shared logins. Each card names the check to run and the team that usually owns it.
Administrator roles granted for convenience
Administrator access is often handed out to speed up a change, then never removed. Review which accounts hold the Admin role and ask whether each one needs to change configuration or only search and read. Most analysts need search and dashboard access, not the ability to alter inputs, users or system settings. The platform team usually owns this check, with the security lead approving exceptions in writing.
Dashboards shared broadly
A dashboard shared with a wide group can expose fields and widgets that the viewer was never meant to see, even when the underlying streams are restricted elsewhere. Check each shared dashboard for widgets that display user identifiers, source addresses, tokens or customer records, and confirm who sees it. The dashboard owner and the data owner should agree on sharing before it is widened.
Users who can create inputs
A user who can create an input can point a source at any stream the input routes to, which lets that person inject records into the wrong place or flood a stream with noise. Confirm that only the platform team holds the permission to create and edit inputs, and that other roles can only view them. The platform team owns the input inventory and reviews it on a regular schedule.
Leavers with active accounts or groups
When someone leaves, the account may remain active, or it may keep roles inherited from a directory group that was never removed. Compare the Graylog user list and role assignments with the current directory roster, including service accounts and API tokens. The identity team usually owns the offboarding step, and the Graylog administrator confirms that removal has taken effect in Graylog.
Stream routing that exposes sensitive logs
Sensitive logs can end up in a shared stream because the routing rule matched a broad field or because the stream was created for convenience. Check which streams hold authentication, payment or personal data, and list every role that can read each one. Routing should be reviewed alongside stream permissions, since a correct role model cannot protect records sent to the wrong stream. The log owner and the Graylog administrator usually share this review.
Shared accounts that erase accountability
A shared login hides which person ran a search, changed a dashboard or edited an alert, so reviewers cannot tie actions to individuals. Identify any accounts used by more than one person, then assign each person a named account with the narrowest role that fits their work. Reviewers should be able to trace each change to one user. Ask the identity team to confirm that each named account is tied to a single person in the directory.
How directory and single sign-on groups feed Graylog access
The first decision for this section is where access lives. You can manage users and their group memberships in your directory and map those groups into Graylog, or you can create and maintain users locally inside Graylog. The authentication documentation lists Active Directory and LDAP, along with trusted header authentication, as the options available in Graylog Open. Graylog Enterprise adds Okta, generic OpenID Connect and SAML single sign-on. Directory-driven access ends a common failure pattern, where a departed engineer keeps a local Graylog account with search rights to production logs. It also gives your identity team one place to approve, review and remove access. Local accounts remain useful for a break-glass administrator, which should be documented, rarely used and monitored.
Group mapping is where least privilege either holds or fails, so confirm its behavior in the version you run before you design around it. Check how Graylog maps directory groups to its roles, whether a user in several groups receives the union of their roles, and whether mapping happens at login only or is refreshed on each session. Confirm which attribute carries the group names for your directory and how it is referenced in the configuration, and test with a dedicated account in a non-production environment. For trusted header authentication, confirm which header your reverse proxy sets, that clients cannot inject it, and how the header value maps to a Graylog user. Ask your Graylog contact to confirm each point in writing for your edition and release.
Deprovisioning is the step most often assumed rather than tested. Removing a user from a directory group or disabling the account does not automatically end an active Graylog session or remove roles that were stored locally. Confirm whether a disabled directory account is refused at the next login, how long an existing session or API token remains valid, and whether any Graylog-side user records persist after the directory change. Include a test in your access review where you disable a test account and confirm that searches, dashboard views and API calls fail. Record the result as evidence for your review cycle.
Access patterns for security, application and audit teams
Security operations teams need broad search across many sources during triage and investigation, but they rarely need to change how the platform itself is configured. The access shape is therefore wide on data and narrow on administration: analysts can query the streams that hold security-relevant events, while the power to create inputs, change index sets or manage users stays with a small group. Sharing works best when saved searches and dashboards are shared with the analyst group rather than with individuals, so that investigation views survive staff changes.
- Broad read on security streams: Grant search access to the streams that carry authentication, network and endpoint events, not to every stream in the cluster.
- Separate investigation from administration: Keep analysts out of input, index set and user administration so that a compromised analyst account cannot change collection.
- Shared saved searches: Share investigation searches and dashboards with the analyst group so that queries remain available to the next shift.
- Alert ownership: Decide who can edit event definitions and notifications, since changing an alert can silence the detection it is meant to provide.
- Risk to watch: Analysts often receive more data access than their cases need. Review stream access against the sources the team actually investigates.
Confirm the exact permission names and the stream-level sharing options in your Graylog version before you write the role model.
Application teams usually need to find errors and events from their own services, and nothing from other applications. The access shape is narrow on data: each team sees only the streams that carry its service logs, and it has no reason to search shared infrastructure or other teams' traffic. Sharing is usually scoped to the team's own dashboards and saved searches, which the owners can maintain without involving a platform administrator for every change.
- Stream-scoped access: Map each application or service to its own stream, or to a routing rule that places its logs in a stream, so access can follow ownership.
- Team-owned dashboards: Let each team manage dashboards for its services and share them only within the team or with the on-call group.
- No input or index changes: Application teams should request new sources through the platform team, since a new input can expose data to the wrong readers.
- Log content risk: Application logs often contain user identifiers, tokens or request bodies. Ask developers to avoid logging secrets, and confirm which fields the team can see.
- Risk to watch: Routing rules that send logs from several services into one shared stream can give a team access to data it does not own. Test the routing with sample messages.
Check that each service's logs land in a stream the owning team can read and no other team can, using a test account.
Auditors and compliance reviewers need to examine evidence without changing it. The access shape is read-only, scoped to the log sources and time ranges relevant to the review, and should not include the ability to alter searches shared with other teams, change retention or export data beyond what the review requires. Sharing here is about giving reviewers a stable view of the evidence, such as a saved search or dashboard that another team maintains, rather than broad rights over the platform.
- Read-only reviewer role: Give reviewers search access without administrative rights, so that they cannot change streams, pipelines, index sets or users.
- Scoped evidence views: Provide saved searches limited to the systems in scope for the review, so reviewers do not browse unrelated data.
- Named, time-limited access: Record who had access and when, and remove accounts when the review closes.
- Log of changes: Confirm how access changes and configuration edits are recorded before relying on them as review evidence.
- Risk to watch: Reviewers who receive administrator accounts for convenience can change the evidence they are reviewing. Keep reviewer accounts separate from operator accounts.
Ask your auditor which evidence format and access method they expect, and confirm with the vendor how your Graylog version records access changes. DeployOpen does not issue audit reports or attestations.
Platform administrators manage the parts of Graylog that affect everyone: inputs, index sets, users, roles and the storage behind them. The access shape is administrative and should be held by a small, named group, with its activity recorded. Because an administrator can change where data goes and who can see it, this group needs the most review, and its accounts should be separate from everyday analyst accounts.
- Small administrator group: Limit full administrative rights to a few named people, and give everyone else the narrowest role that does the job.
- Controlled input creation: Restrict who can create or change inputs, since a new input can accept untrusted data or route sensitive logs to the wrong place.
- Index set ownership: Assign index sets to a team and review retention settings, because index sets decide how long each team's data is kept.
- Separate admin accounts: Use dedicated administrator accounts for platform work and avoid using them for routine searching.
- Risk to watch: Administrators who manage their own roles can grant themselves access without review. Require a second person for changes to administrative roles.
Confirm which of these actions your Graylog edition and version allow to be delegated, and which require full administrator rights.
Questions teams ask before changing Graylog access
Can we build least-privilege Graylog access ourselves on Graylog Open?
Yes, many teams do, because Graylog Open includes users, roles and stream and dashboard sharing controls within the open edition, and you can configure them in the web interface or through the API. The work is mostly design: deciding which teams need which streams, which actions each role allows, and who may create inputs. Where teams usually struggle is keeping the design consistent over time, since roles drift when people add ad hoc shares. Before you start, check the current permission and sharing options against the Graylog Open product page and your planned version, because the feature set differs by edition. Graylog Open is licensed under SSPL-1.0, which is not an OSI-approved license, so confirm that license terms fit your internal policy.
What skills does our team need to design and run Graylog access?
Your team needs someone who understands your directory (Active Directory, LDAP or an identity provider), someone who knows which log sources hold sensitive data, and a Graylog administrator who can configure roles, streams and dashboards. Access design also needs a data owner for each log category who can approve who sees what. If you plan to connect single sign-on, the group names in your directory must map cleanly to Graylog roles, so identity staff should be involved early. Confirm which authentication methods your edition supports in the Graylog user authentication documentation before you choose a model.
What makes a Graylog access project take more effort?
Effort rises with three main drivers. The first is the number of teams and roles, since each added team multiplies the combinations of streams, dashboards and permitted actions. The second is directory complexity, such as nested groups, multiple domains or inconsistent naming, which slows mapping and testing. The third is the sensitivity of log sources, because sources like authentication logs, customer data or privileged activity usually need tighter separation, extra approvals and documented exceptions. Projects also grow when existing sharing is messy and must be inventoried before anything changes. Ask any provider to break effort down by these drivers in the written scope.
Does Graylog Enterprise add a per-user fee for team access?
No. According to the Graylog pricing page, Graylog licensing is based on processed data with no per-user or per-device fees. Graylog Enterprise starts at 15,000 US dollars per year, with a minimum of 10 GB per day or 100 Graylog Compute Units, and Graylog Security starts at 18,000 US dollars per year on the same basis. Adding teams and users therefore does not change the license count, but adding volume or a higher tier does. Confirm current figures and minimums with Graylog, since pricing can change. Enterprise is also where teams in the platform are available, so check the feature list against the access model you need.
How long does a first Graylog access design take?
The duration depends on scope: how many teams and log sources are in play, how clean the directory is, and whether the design includes a review of existing shares. DeployOpen does not publish a price list or fixed timeline. Most engagements are fixed-scope, so the scope, deliverables and timeline are agreed in writing before work starts, and a quote follows from that written scope. Ask for a breakdown covering discovery of current roles and shares, the role and stream model, testing with real team members, and handover of the documented model.
How do we prepare Graylog access for a compliance review?
Start by producing a current inventory: every user, role, group mapping, stream, dashboard and share, with the owner who approved it. Then document the rule behind each permission so an assessor can trace a person's access to a business need. Record how joiners, movers and leavers are handled, and keep evidence of periodic reviews where each owner confirms or removes access. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports or certifications; independent auditors and certification bodies do that. Ask your assessor which evidence format they expect before you collect it.
Should we restrict who can create inputs in Graylog?
Usually yes, because inputs control what enters the platform and can expose listening ports on your network. Limiting input creation to a small administrator group reduces the chance of unreviewed sources, misconfigured parsing or unexpected network exposure. The trade-off is operational speed, since teams that onboard new log sources need a request path with a named approver. Define that workflow in the access design, record each input's owner, and review the list during periodic access reviews. Confirm the exact permission names in your Graylog version's documentation before you map them to roles.
What to confirm in your environment before you rely on this design
The role and sharing model in this design only holds if your Graylog version, edition and identity setup behave the way the plan assumes. Each card below is a check to complete with your own deployment and vendor documentation before you grant access to production logs.
Role capabilities in your version
Confirm which role capabilities and sharing options exist in the Graylog version you run, since the permission model changes between releases. List each action your teams need, such as viewing streams, editing dashboards or managing inputs, and test it against a non-production account. Do not assume a capability from an older guide applies to your version. Current documentation covers Graylog 7.2, but your installed release is what counts.
Teams and SSO in your edition
Teams depend on your license, so confirm whether your edition includes them before you design around them. Also confirm which single sign-on options you need. Graylog Open supports Active Directory, LDAP and trusted header authentication, while Okta, generic OpenID Connect and SAML require Enterprise. If your identity provider is outside these options, the design changes before any build starts.
Directory group mapping and removals
Map each directory group to a Graylog role and document the mapping. Then test how a removal propagates: when a user leaves a group or is disabled in the directory, confirm whether Graylog revokes access at the next login, at a sync interval, or only after a manual change. Former staff with lingering access is the most common gap in this area, so run this test with a departing account before go-live.
Stream restrictions against data classification
Check whether stream-level restrictions meet your data classification. Streams route messages, but a user who can search a stream may still see sensitive fields in the messages it holds. Compare each stream's contents with the classes of data your policy allows each group to read. If one stream mixes classes, split the source or the routing before you rely on sharing alone.
Audit trails of access changes
Decide how changes to roles, sharing and team membership will be recorded and kept. Confirm whether your edition provides audit logging for these changes and how long entries persist before they expire. The separate audit log topic covers how to keep these records, so plan that work alongside this design rather than after it.
Version support in the compatibility matrix
Confirm that your Graylog version is supported with your MongoDB and search backend in the compatibility matrix. Graylog 7.0 to 7.2 list MongoDB 7.x up to 8.2.x, and OpenSearch 1.1.x up to 3.7.x, with Graylog Security needing OpenSearch 2.0 or later. OpenSearch 1.x is deprecated since Graylog 7.0 and is removed in Graylog 8.0, so check this before you plan an access model that depends on a specific backend.
Reviewing access for compliance evidence
A recurring access review turns least-privilege settings into evidence you can show an assessor. Each review period, export or list the Graylog users, their roles, their team memberships (Enterprise) and the streams, dashboards and saved searches that have been shared, then compare that snapshot with your approved access matrix. Every difference is either an approved exception, a grant that should be removed, or a missing approval that needs a decision. Record each outcome with the reviewer's name, the date and the ticket or change record that authorized or removed the access. Confirm with your own administrators which listing method (the web interface, the REST API or a scripted export) gives you a complete, repeatable view of users, roles and shares in your Graylog version, and test it before the first formal review.
Keep the review output with the change record rather than in a separate spreadsheet that no one can trace back. Store the exported snapshot, the reviewed matrix, the list of removals and the sign-off together, and protect them as you would other records that describe who can see sensitive logs. Pay particular attention to accounts that can create inputs, change pipelines or read log data across many streams, because those rights reach the most data. Also review service and automation accounts, which often hold broad API access and are easy to miss in a manual review. Graylog's own audit trail, covered in its dedicated section, should be used to confirm that removals actually happened and when.
DeployOpen prepares the controls, procedures and evidence that a compliance assessment will ask for, including the access review procedure, the matrix template and the review checklist. DeployOpen does not issue audit reports, attestations or certifications. Those are issued by independent auditors or certification bodies. Before you design the review, confirm with your compliance lead, legal team or assessor which framework requirements apply to your organization and how often they expect access to be reviewed, because the cadence and the level of detail differ between frameworks and between regulators. Ask for the review evidence format that your auditor will accept before the first cycle begins.
How DeployOpen works on this
DeployOpen plans, implements, documents and supports self-hosted Graylog inside your own infrastructure, including the roles, sharing and team model that decides who can search which logs. Each engagement starts from a written scope, so the access design is agreed before any role or share is created.
How we scope
- Map which teams, applications and log sources need access, and which must stay restricted to a small group.
- Agree the role model in writing, including which actions each role may take on streams, dashboards and inputs.
- Define who may create inputs and who approves changes, with the review cadence your compliance owner expects.
How we build
- Configure roles, stream and dashboard sharing, and team structures, then test them with named test accounts for each role.
- Verify that restricted streams stay invisible to users outside the granted scope, using search and dashboard checks.
- Where your edition supports teams, set team membership and sharing so access follows your directory groups, not individual grants.
How we hand over
- Deliver a written access matrix that lists each role, its permissions, and the streams and dashboards it covers.
- Document the change procedure for adding users, creating shares and granting input rights, with an owner for each step.
- Provide an access review checklist your team can run on a schedule and keep as compliance evidence.
How we support
- Offer ongoing support, upgrades and access reviews as a retainer after handover, scoped in writing.
- Re-test role and sharing behavior after each Graylog upgrade, since permission changes can ship with new releases.
- Confirm with your team which edition and identity features apply before any access rule depends on them.
