Access and permissions for Grafana Alloy

Grafana Alloy collects telemetry from hosts, containers, and APIs, then forwards it to observability backends. That telemetry collection requires read access to logs, process data, and cluster resources, plus credentials for remote write and similar endpoints. Your configuration determines which permissions Alloy needs, and your deployment platform determines how you enforce them.

The following settings are common permission options. Not every item applies to every configuration or platform. Use only what matches your components and environment.

When your components allow it, run Alloy as a non-root user on Linux, Kubernetes, or a dedicated service account on Windows.
Restrict network exposure: bind the HTTP server and OpenTelemetry receivers to localhost when remote access isn’t required, and use TLS and authentication when you expose listeners or connect to remote backends. Refer to Network exposure.
Include otelcol.processor.memory_limiter after OpenTelemetry receivers, and configure exporter queue, retry, and timeout settings to protect against memory exhaustion under traffic spikes. Refer to Pipeline resource limits.
Avoid insecure_skip_verify = true in production. Refer to the TLS settings in the component reference, for example prometheus.remote_write.
Store credentials outside configuration files when you can, and review collected telemetry for accidental secret exposure before you export it. Refer to Secrets and credentials.
On Kubernetes, set RBAC to the permissions your configuration uses. Refer to Access and permissions on Kubernetes.
For container deployments on Kubernetes, set readOnlyRootFilesystem: true when your volume mounts and components allow it. Refer to Access and permissions on Kubernetes.
For container deployments on Kubernetes, set allowPrivilegeEscalation: false when your components don’t need privilege escalation. Refer to Access and permissions on Kubernetes.
Use a dedicated Alloy instance for components that require elevated access, for example beyla.ebpf and pyroscope.ebpf. Refer to each component reference for required capabilities and privileges.

Process identity and privilege

Create a dedicated service account or user on your deployment platform:

Linux: systemd service, file permissions, and the alloy user
Kubernetes: securityContext, non-root UID, and RBAC
Windows: service accounts, Windows security groups, and filesystem ACLs

Network exposure

Alloy exposes network listeners through its HTTP server and through OpenTelemetry receivers. Review bind addresses, TLS, and authentication before you expose an endpoint beyond localhost.

HTTP server

Alloy runs an HTTP server for its UI, API, and /metrics endpoint. The binary binds to 127.0.0.1:12345 by default, which limits exposure to the local machine. The Grafana Helm chart sets alloy.listenAddr to 0.0.0.0 by default so other Pods can reach the container on port 12345. Review what you expose before you change either default. When you must expose the HTTP server beyond localhost, enable TLS with the http block.

OpenTelemetry receivers

OpenTelemetry receivers such as otelcol.receiver.otlp accept incoming telemetry on network interfaces. otelcol.receiver.otlp binds to 0.0.0.0 by default on ports 4317 and 4318. Many other HTTP-based receivers default to localhost. Confirm the endpoint default in the component reference before you deploy.

If all clients are on the same host as the receiver, set endpoint to 127.0.0.1 or localhost instead of 0.0.0.0. An unauthenticated receiver that’s reachable from other hosts lets anyone push metrics, logs, and traces into your pipeline.

Because Alloy implements these endpoints with OpenTelemetry Collector components, the same binding and authentication recommendations apply. For the full upstream guidance, refer to OpenTelemetry Collector configuration best practices.

TLS and authentication

When you must expose a listener beyond localhost, enable TLS on the receiver’s http, grpc, or equivalent block, or on an exporter’s client block. Set the auth attribute on that block and reference an otelcol.auth.* component’s handler export for credentials. Not every auth component supports server-side authentication. Refer to the otelcol component reference for compatible options and component-specific TLS settings.

Don’t set insecure_skip_verify = true in production on outbound connections. Refer to the TLS settings in the component reference for the component you configure, such as prometheus.remote_write or otelcol.exporter.otlp.

Pipeline resource limits

OpenTelemetry receivers can accept sudden traffic spikes large enough to exhaust process memory. The upstream OpenTelemetry Collector security guidance recommends memory limits, exporter queues, and timeout and retry limits as safeguards for resource utilization.

Place otelcol.processor.memory_limiter immediately after each receiver in the pipeline. It drops telemetry and triggers garbage collection when memory use exceeds configured soft and hard limits. For each exporter that supports them, configure sending_queue, retry_on_failure, and timeout settings so backend failures don’t accumulate too much data in memory. Some exporters also support sending_queue > batch settings to batch data before export.

Refer to OpenTelemetry Collector configuration best practices for related guidance on queue sizes, filters, and exporter timeouts.

Secrets and credentials

Secrets require different controls depending on where they appear. Protect credentials that Alloy uses to access other systems, and protect sensitive data that applications write into telemetry.

Configuration credentials

Store authentication tokens, passwords, and similar values outside plain configuration when you can. The following patterns load secrets at runtime. Pair them with the secret type described in Types and values so credentials don’t appear in the UI or component exports.

sys.env() loads environment variables in configuration.
remote.vault loads secrets from HashiCorp Vault.
remote.kubernetes.secret loads secrets from the cluster.
remote.s3 loads configuration or secrets from AWS S3.

Secrets in collected data

Log lines can contain API keys, tokens, and passwords that applications print to stdout or write to log files. Runtime loading and the secret type don’t apply to those values because they travel with the telemetry to your backends.

Prevent secrets from appearing in logs at the application source where you can. When source-level controls aren’t enough, you can use components such as loki.secretfilter, loki.process, or otelcol.processor.transform to drop or redact sensitive fields before export. Restrict access to observability backends that store log data.