Skip to content
KubeGlass

Installation

KubeGlass is one binary. Pick whichever way of getting it suits you.

On your machine

Section titled “On your machine”
Terminal window
brew install kubeglass/tap/kubeglass
kubeglass

kubeglass opens localhost:8090 in your browser; with Docker, open it yourself. Run kubeglass --demo to try it with sample data instead of a cluster.

When KubeGlass runs with the default local auth mode it listens only on 127.0.0.1, because anyone who can reach it gets your cluster access. The container image listens on all interfaces so that -p 8090:8090 works.

In a cluster

Section titled “In a cluster”

Installed in a cluster, KubeGlass uses its own ServiceAccount and shows only that cluster. To see several clusters in one list, run it on your machine with a kubeconfig.

To try it, install it in local mode and reach it through a port-forward:

Terminal window
helm install kubeglass oci://ghcr.io/kubeglass/charts/kubeglass \
  --namespace kubeglass --create-namespace \
  --set config.authMode=local


kubectl -n kubeglass port-forward svc/kubeglass 8090:8090

In local mode nobody signs in, and anyone who reaches KubeGlass gets its own access to the cluster: read access, Secrets included, a shell in any pod (the chart’s ClusterRole has pods/exec in this mode only), and creating and expiring Alertmanager silences. So in this mode the chart’s NetworkPolicy lets in only the pod helm test runs and what networkPolicy.ingressFrom names; kubectl port-forward still works. Don’t expose it any other way. If the chart exposes it anyway, with ingress.enabled or a LoadBalancer or NodePort Service, and ingressFrom is empty, the NetworkPolicy lets every source in, and the install notes warn and show how to name who may reach it: the ingress controller’s namespace, or an ipBlock with the addresses of clients outside the cluster. With networkPolicy.enabled false they warn in the same way, also when the chart doesn’t expose KubeGlass, since every pod in the cluster can then reach it, and show how to turn the NetworkPolicy on. Once on, it also limits KubeGlass’s own connections to DNS and ports 443 and 6443; for a Prometheus or Alertmanager on another port, add a rule to networkPolicy.additionalEgress. For an ipBlock, set service.externalTrafficPolicy to Local: with Cluster, the Service’s default, the NetworkPolicy often sees a node’s address in place of a client’s, and with Local it sees the client’s. With Local, a node that runs no KubeGlass pod drops connections to its node port, so clients of a NodePort Service have to use the address of a node a KubeGlass pod runs on, which the install notes give and which changes when the pod moves. A load balancer that proxies connections, such as AWS’s Classic ELB, shows the NetworkPolicy its own addresses whatever the policy, so there the ipBlock has to name the load balancer’s addresses (see Using Source IP in the Kubernetes docs).

For a team, let KubeGlass sign people in with your identity provider (config.authMode=oidc, see Sign-in), or keep the default impersonation mode. In that mode a reverse proxy in front of KubeGlass signs people in and names them in X-Forwarded-User and X-Forwarded-Groups. The proxy must replace those headers when a client sends them. KubeGlass believes them from the addresses in config.trustedProxies, and networkPolicy.ingressFrom says who can reach KubeGlass. The install fails until you set both:

Terminal window
helm install kubeglass oci://ghcr.io/kubeglass/charts/kubeglass \
  --namespace kubeglass --create-namespace \
  --set config.trustedProxies=10.244.0.0/16 \
  --set-json 'networkPolicy.ingressFrom=[{"namespaceSelector":{"matchLabels":{"kubernetes.io/metadata.name":"ingress-nginx"}}}]'

Here the proxy is the ingress controller in the ingress-nginx namespace, and 10.244.0.0/16 is the range its pods get addresses from; where your proxy has a fixed address, name only that. A pod range alone, or a wider one such as 10.0.0.0/8, isn’t enough: every pod in the cluster has an address in it, and without ingressFrom any of them could send the headers and act as anyone.

Read Running for a team first. values-production.yaml in the chart is a starting point for a production install, and values.yaml lists the ingress, persistence, ServiceMonitor and NetworkPolicy options.

From source

Section titled “From source”
Terminal window
git clone https://github.com/kubeglass/kubeglass.git
cd kubeglass
make build
./bin/kubeglass

You need Go 1.27 and Node.js 22.22.2 or a later 22.x, 24.15 or a later 24.x, or 26 and later. make build builds the UI first, gzips it and embeds it, so the binary has no other files to ship.

Check that it is running

Section titled “Check that it is running”
Terminal window
curl -s http://localhost:8090/healthz
# {"status":"ok"}

Next steps

Section titled “Next steps”