Skip to main content
An authenticating proxy, like oauth2-proxy or Pomerium, signs people in and names them in request headers. Lumovi reads those headers on every request and acts as whoever they name, impersonating them in the cluster so their RBAC applies. Use this when you already sign people in to internal tools with a proxy, or your provider isn’t one Lumovi can talk to directly.
Lumovi trusts the proxy’s headers completely. Anyone who can reach Lumovi without going through the proxy can name themselves anyone. Make sure nothing but the proxy can reach it.

​
Set it up

1

Put the proxy in front of Lumovi

Point your proxy at the lumovi Service, port 80, and have it pass on who signed in, and their groups. The proxy must pass WebSockets through: each page keeps one open.With oauth2-proxy, --pass-user-headers sends the person’s email address in X-Forwarded-Email, and their groups in X-Forwarded-Groups.If the proxy sends Lumovi a different Host header than the address people open (the Service’s name, say), also set url to that address. Lumovi accepts pages’ connections only from its own origin, and url tells it which that is. See Security.
2

Configure Lumovi, and keep everything else out

values.yaml
The network policy lets only the proxy’s pods reach Lumovi. A podSelector on its own matches pods in Lumovi’s namespace, so this works when the proxy runs there too; for a proxy in another namespace, see below. Your cluster’s network plugin has to enforce network policies for it to work. Leave the chart’s ingress off: your ingress sends people to the proxy, and the proxy sends them on to Lumovi.
With networkPolicy.enabled and an empty from, the policy lets anything in on Lumovi’s port. Always name the proxy.
3

Give people roles

Bind roles to the names the proxy sends, with the prefixes you chose:

​
A proxy in another namespace

When the proxy runs in a namespace of its own, name that namespace and the proxy’s pods in the same entry of from. Kubernetes labels every namespace with its name, in kubernetes.io/metadata.name:
values.yaml
In one entry, both have to match: the proxy’s pods, in that namespace. As two entries (a - before each), either would do, so every pod in the proxy’s namespace could reach Lumovi.

​
The headers

​
string
default:"X-Forwarded-User"
The request header that names the person. A request without it gets a page that says Lumovi doesn’t know who you are, and asks people to have whoever runs Lumovi check the proxy.
​
string
default:"X-Forwarded-Groups"
The request header that lists their groups, separated by commas.
​
string
Where signing out of the proxy is, like https://lumovi.example.com/oauth2/sign_out. Lumovi has no session of its own behind a proxy, so signing out means signing out of the proxy.
Lumovi never acts as one of Kubernetes’ own users or groups (system:…), whatever the proxy says. It leaves out groups whose names start with system:, and refuses a user whose name does.

​
What it means for the cluster

Behind a proxy, Lumovi impersonates people, so the chart gives its service account permission to impersonate users and groups, cluster-wide. Whoever can reach Lumovi’s pod, or read its service account’s token, can act as anyone. Keep Lumovi in a namespace only cluster administrators can exec into. See Security. There are no Lumovi sessions behind a proxy: it reads the headers on every request. Restarting Lumovi doesn’t sign anyone out, and how long people stay signed in is up to the proxy.

Security

Hardening Lumovi when it impersonates people.

Single sign-on

Or let Lumovi talk to your provider directly.