---
title: "Run Alloy as a non-root user in Kubernetes | Grafana Cloud documentation"
description: "Learn how to run the Alloy Docker container as a non-root user in Kubernetes"
---

# Run Alloy as a non-root user in Kubernetes

The [Alloy Docker image](https://hub.docker.com/r/grafana/alloy) 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](/docs/grafana-cloud/send-data/alloy/reference/components/beyla/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](/docs/grafana-cloud/send-data/alloy/reference/components/beyla/beyla.ebpf) that require root rights.

To run Alloy as a non-root user, configure a [security context](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/) for the Alloy container. If you are using the [Grafana Helm chart](/docs/grafana-cloud/send-data/alloy/configure/kubernetes/#configure-the-helm-chart) you can add the following snippet to `values.yaml`:

YAML ![Copy code to clipboard](/media/images/icons/icon-copy-small-2.svg) Copy

```yaml
alloy:
  securityContext:
    runAsUser: 473
    runAsGroup: 473

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

This configuration makes the Alloy binary run with UID 473 and GID 473 rather than as root. It also runs the config reloader sidecar as UID 65534 and GID 65534.

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