--- title: "Single Sign-On for Kubernetes: Dashboard Experience" source: "https://wordpress-1075849-4005834.cloudwaysapps.com/blog/single-sign-on-for-kubernetes-dashboard-experience/" --- [Technical Blog](https://wordpress-1075849-4005834.cloudwaysapps.com/category/technical-blog/) # Single Sign-On for Kubernetes: Dashboard Experience By [Joel Speed](https://wordpress-1075849-4005834.cloudwaysapps.com/blog/author/joel-speed/) on Oct 02, 2019 • 6 min read Over my last two posts ([part 1](/blog/single-sign-on-for-kubernetes-an-introduction/) and [part 2](/blog/single-sign-on-for-kubernetes-the-command-line-experience/)), I have investigated user authentication in Kubernetes and how to create a single sign-on experience within the Kubernetes ecosystem. So far I have explained how Open ID Connect (OIDC) works, how to get started with OIDC and how to perform a login from the command line. The final piece of this puzzle is the Kubernetes dashboard, often used by our engineers alongside kubectl. To complete our move to SSO, we wanted to ensure that, when using the Dashboard, our engineers logged in to the same account they used for kubectl. ## Login page issues Since Kubernetes version 1.7.0, the dashboard has had a login page. It allows users to upload a kubeconfig file or enter a bearer token. If you have already logged into the command line, this allows you to copy the OIDC id-token from your kubeconfig file into the bearer token field and login. There are, however, a couple of problems with this: - The login page has a skip button — If you aren’t using any authorization (RBAC) then this would permit anyone to access the dashboard with effective admin rights. - Copy and pasting a token from a file isn’t user-friendly. Alternatively, the dashboard supports the use of authorization headers to supply bearer tokens (Authorization: Bearer ). This allows for pre-generation of the OIDC id-token and injecting the header before the dashboard is loaded. If we could ensure that every request to the Dashboard contained this header, then we could skip the dashboards login screen and avoid the aforementioned problems. ## Authentication Proxy At [Pusher](http://www.pusher.com), we had already been using the Bitly OAuth2 Proxy to protect some of our internal sites. It supports OIDC and is therefore compatible with Dex. Initially, it looked as though I could use it to generate the authorization headers for the dashboard. Unfortunately, though, it wasn’t quite ready for this use case: - While it could connect to Dex and authenticate users, the proxy did not expose the id-token needed for the authorization header. With this PR, the OAuth2 Proxy can expose an authorization header compatible with the Kubernetes dashboard when running in both proxy mode and in its Nginx Auth Request mode. - **Running the proxy centrally:** We wanted to design our system to be as scalable as possible. If we were to run a copy of the OAuth2 Proxy on each of our Kubernetes clusters, then our Dex configuration would need updating every time we added a new cluster, a new callback URI would be required to point to each cluster. With this PR, the OAuth2 Proxy can accept a redirect request to subdomains of a whitelisted domain. By whitelisting the domain that our Kubernetes clusters belong to, we can host a central OAuth2 Proxy that doesn’t need any reconfiguration when we add new clusters. With these additions to the OAuth2 Proxy, we added it to our existing Dex cluster and configured it as a client of Dex. I’ve included a snippet of the proxy configuration relevant to the above the PRs for example: ``` `# Subdomains of kube.pusherplatform.io are allowed for redirection --whitelist-domain=.kube.example.com # Cookie needs to cover all whitelisted domains --cookie-domain=.kube.example.com # Set an Authorization header in the auth response --set-authorization-header=true` ```   ## Injecting the Headers With the OAuth2 Proxy configured on our authentication cluster, it is now time to connect the dashboard to it. To do this, we take advantage of Nginx’s Auth Request module within our Ingress Controller. By adding the following snippet to the Ingress object for the dashboard, we can use Nginx to check with the OAuth2 Proxy (in turn checking with Dex and Google) to determine whether the user is logged in or not, before it allows access to the dashboard. ``` `# For an OAuth2 Proxy hosted at http://auth.example.com/oauth2 # Configure Nginx Auth Request Module ingress.kubernetes.io/auth-url: "http://auth.example.com/oauth2/auth" ingress.kubernetes.io/auth-signin: "http://auth.example.com/oauth2/start?rd=http://$host$request_uri$is_args$args" # Proxy Authentication header to Dashboard ingress.kubernetes.io/configuration-snippet: | # adds authorization header for kubernetes-dashboard auth_request_set $token $upstream_http_authorization; proxy_set_header Authorization $token;` ``` With this configuration, on a request to the dashboard, the following happens: - Nginx sends a request to the auth-URL, the auth endpoint of the OAuth2 Proxy - The OAuth2 Proxy returns a 202 if the user is logged in and a 401 if the user isn’t logged in. - If Nginx receives a 202, it allows the request to the dashboard and proxies the authorization header in the auth response to the Dashboard. - If Nginx received a 401, it redirects the user to the auth-signin endpoint which then starts the login flow. When a user first visits the dashboard, they are transparently redirected via Dex to Google to log in. Once they log in with Google, they are then redirected back to where they were. At this point they will be faced with the Dashboard, skipping the login screen since they are now authenticated using an authorization header. ## Conclusion With the above system, we can now ensure that every request to the Kubernetes Dashboard is authenticated. Our engineers tend to be signed in to Google already and they often don’t even notice the dashboard login flow, their browser just redirects them straight through and back to the dashboard. In combination with the command line experience discussed in my last post, we have migrated Pusher’s Kubernetes authentication to a Single Sign-On system. Each engineer logs into the clusters individually and importantly, we don’t have and extra user accounts to manage. While the initial single sign-on setup took some time, we are very pleased with the outcome and the user-friendly experience our engineers now have. This article originated from [http://thenewstack.io/single-sign-on-for-kubernetes-dashboard-experience/](http://thenewstack.io/single-sign-on-for-kubernetes-dashboard-experience/) [Joel Speed](http://www.linkedin.com/in/joel-speed/) is a Tigera guest blogger. He is a DevOps engineer currently building a Kubernetes platform on AWS and also a syndicated blogger with recent posts on InfoQ and The New Stack. ————————————————- [**Free Online Training**](https://wordpress-1075849-4005834.cloudwaysapps.com/events/) Access Live and On-Demand Kubernetes Training [**Calico Enterprise – Free Trial**](https://www.calicocloud.io/home) Network Security, Monitoring, and Troubleshooting for Microservices Running on Kubernetes [How-To](https://wordpress-1075849-4005834.cloudwaysapps.com/tags/how-to/)[Products](https://wordpress-1075849-4005834.cloudwaysapps.com/tags/products/) Add Tigera as a preferred source on Google to see more of our content in your search results. [![Add as a preferred source on Google](https://wordpress-1075849-4005834.cloudwaysapps.com/app/themes/tigera2021/dist/img/google-preferred-source-light.png)](https://www.google.com/preferences/source?q=tigera.io) ## Related posts [![AI Assistant for Calico: Troubleshooting at the Speed of Thought](https://wordpress-1075849-4005834.cloudwaysapps.com/app/uploads/2026/03/Blog-Mar-20-AI-Assistant-for-Calico.png)](https://wordpress-1075849-4005834.cloudwaysapps.com/blog/ai-assistant-for-calico-troubleshooting-at-the-speed-of-thought/) #### [AI Assistant for Calico: Troubleshooting at the Speed of Thought](https://wordpress-1075849-4005834.cloudwaysapps.com/blog/ai-assistant-for-calico-troubleshooting-at-the-speed-of-thought/) By [Veronika Smolik](https://wordpress-1075849-4005834.cloudwaysapps.com/blog/author/veronika-smolik/) on Mar 19, 2026 Despite the wealth of data available, distilling a coherent narrative from a Kubernetes cluster remains a challenge for modern infrastructure teams. Even with powerful visualization tools like the Policy Board, Service Graph, and specialized dashboards,... [Read more](https://wordpress-1075849-4005834.cloudwaysapps.com/blog/ai-assistant-for-calico-troubleshooting-at-the-speed-of-thought/) [![What Your EKS Flow Logs Aren’t Telling You](https://wordpress-1075849-4005834.cloudwaysapps.com/app/uploads/2026/03/Blog-Mar-18-What-Your-EKS-Flow-Logs-Arent-Telling-You.png)](https://wordpress-1075849-4005834.cloudwaysapps.com/blog/what-your-eks-flow-logs-arent-telling-you/) #### [What Your EKS Flow Logs Aren’t Telling You](https://wordpress-1075849-4005834.cloudwaysapps.com/blog/what-your-eks-flow-logs-arent-telling-you/) By [Phil DiCorpo](https://wordpress-1075849-4005834.cloudwaysapps.com/blog/author/phil-dicorpo/) on Mar 18, 2026 If you’re running workloads on Amazon EKS, there’s a good chance you already have some form of network observability in place. VPC Flow Logs have been a staple of AWS networking for years, and AWS... [Read more](https://wordpress-1075849-4005834.cloudwaysapps.com/blog/what-your-eks-flow-logs-arent-telling-you/) [![Kubernetes Network Observability: Comparing Calico, Cilium, Retina, and Netobserv](https://wordpress-1075849-4005834.cloudwaysapps.com/app/uploads/2026/02/Blog-Feb-11-Comparing-Calico-Cilium-Retina-and-Netobserv-1.png)](https://wordpress-1075849-4005834.cloudwaysapps.com/blog/kubernetes-network-observability-comparing-calico-cilium-retina-and-netobserv/) #### [Kubernetes Network Observability: Comparing Calico, Cilium, Retina, and Netobserv](https://wordpress-1075849-4005834.cloudwaysapps.com/blog/kubernetes-network-observability-comparing-calico-cilium-retina-and-netobserv/) By [Reza Ramezanpour](https://wordpress-1075849-4005834.cloudwaysapps.com/blog/author/rezar/) on Feb 11, 2026 Calico, Cilium, Retina, and Netobserv: Which Observability Tool is Right for Your Kubernetes Cluster? Network observability is a tale as old as the OSI model itself and anyone who has managed a network or even... [Read more](https://wordpress-1075849-4005834.cloudwaysapps.com/blog/kubernetes-network-observability-comparing-calico-cilium-retina-and-netobserv/)