This is documentation for the next version of Alloy. For the latest stable release, go to the latest version.

DocumentationGrafana AlloyTasksRun Alloy as a non-root user in Kubernetes

Run Alloy as a non-root user in Kubernetes

The Alloy Docker image contains two users:

• A root user.
• A non-root user named alloy with uid 473 and gid 473.

By default, the alloy binary runs as root. This is because some Alloy components like beyla.ebpf require root permissions.

You can configure a non-root user when you deploy Alloy in Kubernetes.

Configure Alloy to run as a non-root user in Kubernetes

To run Alloy as a non-root user, configure a security context for the Alloy container. If you are using the Grafana Helm chart you can add the following snippet to values.yaml:

yaml Copy

alloy:
  securityContext:
    runAsUser: 473
    runAsGroup: 473

This configuration makes the Alloy binary run with UID 473 and GID 473 rather than as root.

Is the root user a security risk?

Not really. The Linux kernel prevents Docker containers from accessing host resources. For example, Docker containers see a virtual file system rather than the host filesystem, a virtual network rather than the host network, a virtual process namespace rather than the host’s processes. Even if the user inside the Docker container is root it can’t break out of this virtual environment.

However, if there was a bug in the Linux kernel that allowed Docker containers to break out of the virtual environment, it would likely be easier to exploit this bug with a root user than with a non-root user. It’s worth noting that the attacker would not only need to find such a Linux kernel bug, but would also need to find a way to make Alloy exploit that bug.