Access and permissions for Grafana Alloy on Grafana Labs

Access and permissions for Grafana Alloy on Linux

Tue, 30 Jun 2026 15:02:01 +0000

Access and permissions for Grafana Alloy on Linux

Alloy requires read access to /proc, /sys, the systemd journal, application log files, and credentials for observability backends. DEB and RPM packages for Alloy provide a dedicated alloy user and systemd unit file. Set filesystem permissions, systemd restrictions, and read access to match the components in your configuration.

Note
If you installed from a binary instead of a package, create the alloy user and systemd unit yourself. Refer to Install Alloy on Linux for setup steps, and adapt paths to match your layout.

Run as the `alloy` user

Verify the service runs as the alloy user:

ps aux | grep alloy

The output should show alloy in the user column, not root.

If the process runs as root, check the User= directive in the unit file:

systemctl cat alloy | grep User

The package sets User=alloy but doesn’t set Group=alloy. If User=alloy isn’t set, or you want to set the group explicitly, create a drop-in file. Don’t edit the unit file directly.

sudo systemctl edit alloy

Add this configuration:

[Service]
User=alloy
Group=alloy

Reload and restart the service:

sudo systemctl daemon-reload
sudo systemctl restart alloy

Restrict file and directory permissions

The alloy user needs read access to the configuration file and read/write access to the data directory. It shouldn’t have access to anything else.

The package sets /etc/alloy and /var/lib/alloy to mode 770 at install time when it creates those directories. Use tighter permissions for production:

Path	Owner	Permissions	Notes
`/etc/alloy/config.alloy`	`root:alloy`	`640`	Group-readable by `alloy`, not world-readable
`/etc/alloy/`	`root:alloy`	`750`	`alloy` can read directory contents
`/var/lib/alloy/`	`alloy:alloy`	`750`	Write-ahead log and data storage

Apply the permissions after installation:

sudo chown -R root:alloy /etc/alloy
sudo chmod 750 /etc/alloy
sudo chmod 640 /etc/alloy/config.alloy
sudo chown -R alloy:alloy /var/lib/alloy
sudo chmod 750 /var/lib/alloy

If the configuration file contains credentials, confirm it isn’t world-readable:

stat /etc/alloy/config.alloy

Set systemd service permissions

The systemd unit in the package doesn’t include security directives by default. Add them with a drop-in file so they survive package upgrades. If you use eBPF components, for example beyla.ebpf or pyroscope.ebpf, check their component references before you set NoNewPrivileges=yes or run as the alloy user.

sudo systemctl edit alloy

Add these directives:

[Service]
# Block new privileges from setuid or capabilities
NoNewPrivileges=yes

# Make the entire filesystem read-only except for explicitly allowed paths
ProtectSystem=strict

# Block access to /home, /root, and /run/user
ProtectHome=yes

# Give the service a private /tmp, isolated from other services
PrivateTmp=yes

# Block writes to kernel variables in /proc/sys and /sys
ProtectKernelTunables=yes

# Block kernel module loads
ProtectKernelModules=yes

# Block access to the kernel log
ProtectKernelLogs=yes

# Give the service its own network namespace if it only needs to reach specific hosts
# Remove this line if Alloy needs to listen on a host network interface
# PrivateNetwork=yes

# Allow write access to the data directory only
ReadWritePaths=/var/lib/alloy

Reload and restart the service:

sudo systemctl daemon-reload
sudo systemctl restart alloy

Confirm the service starts cleanly and review the logs for permission errors:

sudo journalctl -u alloy -n 50

Grant access to the systemd journal

If you use loki.source.journal, the alloy user needs membership in the adm and systemd-journal groups. The package installer adds the user to both groups when they exist on the system. If you installed via binary or removed the user from either group, add them back:

sudo usermod -aG adm,systemd-journal alloy
sudo systemctl restart alloy

When you use ProtectSystem=strict, add journal paths to ReadOnlyPaths in the systemd drop-in:

ReadOnlyPaths=/var/log/journal
ReadOnlyPaths=/run/log/journal

Grant access to application log files

If you use loki.source.file for log files owned by other users or services, grant read access with ACLs. Don’t expand the alloy user’s group membership to reach those files.

sudo setfacl -R -m u:alloy:rx /var/log/myapp
sudo setfacl -R -d -m u:alloy:rx /var/log/myapp

The -d flag sets a default ACL so new files in the directory inherit the permission.

Restrict the HTTP server

By default, Alloy binds its HTTP server to 127.0.0.1:12345. Change the bind address only when you need to expose the UI or metrics endpoint to other machines.

To expose /metrics for Prometheus scrape while you keep the UI private, put a reverse proxy in front of Alloy and restrict access at the proxy. Refer to the http block for TLS and authentication options.

Next steps

Access and permissions for Grafana Alloy on Kubernetes

Tue, 30 Jun 2026 15:02:01 +0000

Access and permissions for Grafana Alloy on Kubernetes

Alloy requires read access to Kubernetes API resources, node and container telemetry, and credentials for observability backends. The Alloy container image runs as root by default and defines a non-root alloy user with UID 473 and GID 473. Set securityContext, RBAC, and network settings to match the components in your configuration.

The Alloy Docker container image defines two users:

A root user.
A non-root user named alloy with UID 473 and GID 473.

Note
Components like beyla.ebpf and pyroscope.ebpf need root or additional Linux capabilities. Don’t set capabilities.drop: [ALL] when these components are in your configuration. Refer to the component references for required capabilities and Pod settings.

Run as a non-root user

To run Alloy as a non-root user, configure a security context for the Alloy container. If you use the Grafana Helm chart, add this to values.yaml:

alloy:
  securityContext:
    runAsUser: 473
    runAsGroup: 473

global:
  podSecurityContext:
    fsGroup: 473

configReloader:
  securityContext:
    # this is the UID of the "nobody" user that the configReloader image runs as
    runAsUser: 65534
    runAsGroup: 65534

This configuration runs the Alloy binary with UID 473 and GID 473 instead of as root. It also runs the config reloader sidecar as UID 65534 and GID 65534.

Set container permissions

Set securityContext at the Pod and container level to limit filesystem writes, privilege escalation, and Linux capabilities:

spec:
  securityContext:
    runAsUser: 473
    runAsGroup: 473
    fsGroup: 473
    runAsNonRoot: true
  containers:
    - name: alloy
      securityContext:
        readOnlyRootFilesystem: true
        allowPrivilegeEscalation: false
        capabilities:
          drop:
            - ALL

runAsNonRoot: true causes Kubernetes to reject the Pod if the image tries to run as root.
readOnlyRootFilesystem: true blocks writes to the container filesystem except on mounted volumes.
allowPrivilegeEscalation: false blocks privilege escalation beyond the parent process, regardless of file capabilities or setuid bits.
capabilities.drop: [ALL] removes all Linux capabilities from the container.

When you set readOnlyRootFilesystem: true, mount a writable volume at that path or change alloy.storagePath to a mounted volume.

Note
If you use components that need elevated host access, for example beyla.ebpf or pyroscope.ebpf, add the capabilities those components need. Don’t drop all capabilities when these components are in your configuration. Refer to the component references for required capabilities and volume mounts.

Restrict the HTTP server

The Grafana Helm chart sets alloy.listenAddr to 0.0.0.0 by default so other Pods can reach the container on port 12345. Set alloy.listenAddr to 127.0.0.1 in values.yaml or restrict access with a NetworkPolicy when you don’t need cross-Pod access to the UI or /metrics endpoint. The container image uses the binary default of 127.0.0.1:12345 when you don’t pass --server.http.listen-addr. Refer to the http block for TLS and authentication options.

Kubernetes RBAC

Alloy needs RBAC permissions to interact with Kubernetes APIs. The Helm chart creates a ClusterRole and ClusterRoleBinding when rbac.create is true. The Helm chart sets rbac.rules and rbac.clusterRules in values.yaml. Refer to the Grafana Helm chart values.yaml or README for the default rule blocks and the components each one supports.

To limit permissions, set rbac.rules and rbac.clusterRules to only the rule blocks your configuration uses. Helm replaces each array in full, so copy the defaults and remove the blocks you don’t need. Set rbac.create to false if you manage RBAC outside the chart.

Review the RBAC resources the Helm chart creates:

helm template alloy grafana/alloy --show-only templates/rbac.yaml

Next steps

Access and permissions for Grafana Alloy on Windows

Tue, 30 Jun 2026 15:02:01 +0000

Access and permissions for Grafana Alloy on Windows

Alloy requires read access to Windows Event Logs, performance counters, application log files, and credentials for observability backends. The Windows installer registers the Alloy service to run as LOCAL SYSTEM. Set the service account, security group membership, and filesystem permissions to match the components in your configuration.

Run as a dedicated service account

Create a dedicated Windows service account and assign it to the Alloy service.

Required user rights

The service account needs the Log on as a service user right. Windows requires this right for any account that runs a service.

Assign the right in the Local Security Policy editor at secpol.msc under Security Settings > Local Policies > User Rights Assignment.

Assign the service account

Stop the service, assign the account, and start the service again.

Run these commands in an elevated Command Prompt or PowerShell session:

cmd

powershell

sc stop Alloy
sc config Alloy obj= "DOMAIN\username" password= "password"
sc start Alloy

Stop-Service Alloy
sc.exe config Alloy obj= "DOMAIN\username" password= "password"
Start-Service Alloy

Replace DOMAIN\username and password with the service account credentials. For a local account, use COMPUTERNAME\username or .\username.

You can also open Services (services.msc), open Grafana Alloy properties, select the Log On tab, and choose This account.

If you haven’t installed Alloy yet, you can set the service account during a silent install with /USERNAME and /PASSWORD. Refer to Install Alloy on Windows for those options.

Windows security groups

Add the service account to Windows security groups based on what you collect:

Event Log Readers: Read Application, System, Security, and custom event logs. Required for Windows Event Log collection.
Performance Monitor Users: Read performance counter data for CPU, memory, disk I/O, and network usage. Required for Windows performance metrics.
Performance Log Users: Manage Data Collector Sets and performance counter logs. Required for advanced or historical data collection.

File system and network permissions

Grant read, write, and modify permissions on %PROGRAMDATA%\GrafanaLabs\Alloy\data, where Alloy stores its write-ahead log and runtime data.

If Alloy reads application log files from disk, grant the service account read access to those files and their parent directories through Access Control Lists or a custom group.

Alloy needs outbound network access to its telemetry endpoints, for example Prometheus remote write, Loki, and OTLP. Allow outbound connections from the host on the ports your configuration uses.

The service account may need read access to HKEY_LOCAL_MACHINE\SOFTWARE\GrafanaLabs\Alloy to read environment variables and command-line arguments. Refer to Registry key security and access rights for details.

If you enable the Alloy UI, the service account needs permission to listen on the configured port. The default port is 12345.

Some components write temporary files in the system temp directories. If you use the process or service collectors in the integrated Windows Exporter, the service account also needs permission to enumerate processes and services.

Restrict the HTTP server

By default, Alloy binds its HTTP server to 127.0.0.1:12345. Expose the endpoint only when you need remote access to the UI or metrics, and add authentication or TLS when you do. Refer to the http block for configuration options.

Access and permissions for Grafana Alloy on Grafana Labs

Access and permissions for Grafana Alloy on Linux

Access and permissions for Grafana Alloy on Linux

Run as the alloy user

Restrict file and directory permissions

Set systemd service permissions

Grant access to the systemd journal

Grant access to application log files

Restrict the HTTP server

Next steps

Access and permissions for Grafana Alloy on Kubernetes

Access and permissions for Grafana Alloy on Kubernetes

Run as a non-root user

Set container permissions

Restrict the HTTP server

Kubernetes RBAC

Next steps

Access and permissions for Grafana Alloy on Windows

Access and permissions for Grafana Alloy on Windows

Run as a dedicated service account

Required user rights

Assign the service account

Windows security groups

File system and network permissions

Restrict the HTTP server

Next steps

Run as the `alloy` user