Running for a team
One KubeGlass deployment can serve many people. Each person signs in, and everything they do runs as them.
Sign-in
Section titled “Sign-in”Choose the auth mode with KUBEGLASS_AUTH_MODE (config.authMode in the chart):
| Mode | How people sign in | Notes |
|---|---|---|
impersonation |
A reverse proxy (OAuth2 Proxy, Pomerium and so on) signs them in and sends X-Forwarded-User and X-Forwarded-Groups |
Set KUBEGLASS_TRUSTED_PROXIES (config.trustedProxies in the chart) to the addresses the proxy’s requests come from, and in the chart networkPolicy.ingressFrom to the proxy’s namespace: every pod has an address in the pod range, so the NetworkPolicy is what keeps other pods from sending the headers. KubeGlass won’t start in this mode without the first, and a new install of the chart fails without the second |
oidc |
KubeGlass’s sign-in page sends them to your identity provider (Dex, Keycloak, Okta, Entra ID, Google and others) | Register KubeGlass at the provider and set the issuer, client and redirect URL. See Sign-in |
token |
They paste a Kubernetes token on the sign-in page | KubeGlass sends the token to the API server instead of impersonating. See Sign-in |
local |
Nobody signs in | For one person. Every visitor gets KubeGlass’s own access, so outside a cluster it listens only on 127.0.0.1 unless you set KUBEGLASS_BIND_ADDRESS. In a pod it listens on all interfaces, so reach it only through kubectl port-forward |
Cloudflare Access sends its own headers, not X-Forwarded-User, and Cloudflare passes on the headers a visitor sends, so behind a Cloudflare Tunnel use oidc or token mode, with Access in front if you like (see deploy/cloudflare in the repository).
In oidc and token modes Sign out in the user menu ends KubeGlass’s session. Behind a proxy, KUBEGLASS_LOGOUT_URL sets where Sign out goes, for example the proxy’s sign-out endpoint.
Every request runs as the person
Section titled “Every request runs as the person”KubeGlass impersonates the signed-in user and their groups on every Kubernetes call (in token mode it sends their token instead): lists and watches as well as changes, exec, logs, port-forwards, Helm and GitOps actions. Kubernetes RBAC decides the result, so a person sees the namespaces and resources they could see with kubectl, and an action they aren’t allowed to take fails with “forbidden”.
Data that KubeGlass gathers once and shares is filtered per person:
- Search results only include resources the person may list.
- Metrics come from metrics-server as the person. Prometheus, which can see the whole cluster, is used only for people with cluster-wide read access.
- Alertmanager alerts and PromQL queries are limited to people with cluster-wide read access.
- The change history is recorded once per cluster, as KubeGlass. Each change is shown only to people who may list that kind in its namespace.
Each person also chooses their own cluster and namespace. Switching doesn’t affect anyone else.
If someone can’t list namespaces at all, they can enter the namespaces they work in under Settings › Clusters › Allowed namespaces, and KubeGlass will query each one directly.
Act as another user
Section titled “Act as another user”“Act as…” in the user menu shows the cluster as another user, group or ServiceAccount (system:serviceaccount:<namespace>:<name>), the way kubectl --as does. It is useful for checking what a new RoleBinding grants. Lists, watches, logs, terminals and the permission checks that hide buttons all switch to that identity on the current cluster until you stop or switch to another cluster. Other clusters are read and changed as you: the cluster switcher, Other clusters on the Overview and Clusters, lists that show several clusters, the search across clusters, the cross-cluster compare and diff, and a terminal opened on another cluster.
Because KubeGlass’s ServiceAccount can impersonate anyone, KubeGlass first asks the API server whether you yourself may impersonate that user and each group. If you may not, requests fail with act_as_forbidden. To allow it, grant the impersonate verb on users, groups or serviceaccounts, ideally limited with resourceNames. In local mode your kubeconfig’s credentials do the impersonating, so the API server checks them directly. A change made while acting as someone is in the audit log under your name and theirs, such as “alice as bob”, and the server log’s audit line has act_as_user and act_as_groups.
Admins
Section titled “Admins”A few things change the server for everyone, or show data gathered with KubeGlass’s own identity across users and clusters. Only admins can:
- add clusters (Clusters › Add cluster) and remove them (Clusters › All clusters),
- change server settings in Settings,
- see Timeline › Audit log, everyone’s actions through KubeGlass,
- use drift policies (Clusters › Drift policies), which read each cluster’s inventory as KubeGlass.
List admins with KUBEGLASS_ADMIN_USERS and KUBEGLASS_ADMIN_GROUPS (config.adminUsers and config.adminGroups in the chart), comma-separated. When both are empty there are no admins, and you manage clusters and settings through Helm values instead. In local mode the one user is the admin.
What KubeGlass’s ServiceAccount needs
Section titled “What KubeGlass’s ServiceAccount needs”The chart’s ClusterRole lets KubeGlass impersonate users, groups and ServiceAccounts, plus read access for the shared views above. Anyone who can change KubeGlass’s configuration or reach it without the proxy could use that impersonation right, so protect the namespace and the proxy accordingly. To limit whom it may impersonate, list them in rbac.impersonation.resourceNames, including every group the proxy sends for a user. In local mode the chart leaves the impersonation rule out.
The read access includes getting, listing and watching Secrets. Listing returns their contents, so get exposes nothing more. Helm keeps its release records in Secrets: drift detection’s inventory lists them to find Helm releases, and the change history reads them for each release’s revisions, which is how a problem can name a helm upgrade as the change before it. The history also watches Secrets to note which keys change; it keeps hashes, never values. Set rbac.readSecrets=false to remove it; drift detection then doesn’t compare Helm releases, and the change history leaves out Secrets and Helm releases.
Per-person settings
Section titled “Per-person settings”Each person’s cluster settings (a cluster’s name, default namespace, production and read-only marks, color and allowed namespaces) are kept on the server under their user name, so they follow them to any browser. Theme, density, language, time format, pinned clusters and namespaces, notification choices and terminal preferences are saved in each person’s browser. See Settings.