---
title: "Access and permissions for Grafana Alloy | Grafana Alloy documentation"
description: "Set access and permissions for Grafana Alloy through process identity, network exposure, secrets, and component-level access"
---

> For a curated documentation index, see [llms.txt](/llms.txt). For the complete documentation index, see [llms-full.txt](/llms-full.txt).

# 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.

1. When your components allow it, run Alloy as a non-root user on [Linux](./linux/), [Kubernetes](./kubernetes/), or a dedicated service account on [Windows](./windows/).
2. 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](#network-exposure).
3. Include [`otelcol.processor.memory_limiter`](../reference/components/otelcol/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](#pipeline-resource-limits).
4. Avoid `insecure_skip_verify = true` in production. Refer to the TLS settings in the [component](../reference/components/) reference, for example [`prometheus.remote_write`](../reference/components/prometheus/prometheus.remote_write/).
5. 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](#secrets-and-credentials).
6. On Kubernetes, set RBAC to the permissions your configuration uses. Refer to [Access and permissions on Kubernetes](./kubernetes/).
7. For container deployments on Kubernetes, set `readOnlyRootFilesystem: true` when your volume mounts and components allow it. Refer to [Access and permissions on Kubernetes](./kubernetes/).
8. For container deployments on Kubernetes, set `allowPrivilegeEscalation: false` when your components don’t need privilege escalation. Refer to [Access and permissions on Kubernetes](./kubernetes/).
9. Use a dedicated Alloy instance for components that require elevated access, for example [`beyla.ebpf`](../reference/components/beyla/beyla.ebpf/) and [`pyroscope.ebpf`](../reference/components/pyroscope/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](./linux/): systemd service, file permissions, and the `alloy` user
- [Kubernetes](./kubernetes/): `securityContext`, non-root UID, and RBAC
- [Windows](./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](../reference/config-blocks/http/).

### OpenTelemetry receivers

OpenTelemetry receivers such as [`otelcol.receiver.otlp`](../reference/components/otelcol/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](https://opentelemetry.io/docs/security/config-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](../reference/components/otelcol/) 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](../reference/components/) for the component you configure, such as [`prometheus.remote_write`](../reference/components/prometheus/prometheus.remote_write/) or [`otelcol.exporter.otlp`](../reference/components/otelcol/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](https://opentelemetry.io/docs/security/config-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](../get-started/expressions/types_and_values/) so credentials don’t appear in the UI or component exports.

- [`sys.env()`](../reference/stdlib/sys/#sys.env) loads environment variables in configuration.
- [`remote.vault`](../reference/components/remote/remote.vault/) loads secrets from HashiCorp Vault.
- [`remote.kubernetes.secret`](../reference/components/remote/remote.kubernetes.secret/) loads secrets from the cluster.
- [`remote.s3`](../reference/components/remote/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`](../reference/components/loki/loki.secretfilter/), [`loki.process`](../reference/components/loki/loki.process/), or [`otelcol.processor.transform`](../reference/components/otelcol/otelcol.processor.transform/) to drop or redact sensitive fields before export. Restrict access to observability backends that store log data.

## Next steps

- [Access and permissions on Linux](./linux/)
- [Access and permissions on Kubernetes](./kubernetes/)
- [Access and permissions on Windows](./windows/)
- [OpenTelemetry Collector configuration best practices](https://opentelemetry.io/docs/security/config-best-practices/)