This is documentation for the next version of Alloy. For the latest stable release, go to the latest version.
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 uid473
and gid473
.
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
Note
Running Alloy as a non-root user won’t work if you are using components like beyla.ebpf that require root rights.
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
:
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.