Deploying a Secured Kubernetes Dashboard

Kubernetes clusters are made up of more than the API server and the kubelet. Clusters are generally made up of additional applications that need to be secured, such as container registries, source control systems, pipeline services, GitOps applications, and monitoring systems. The users of your cluster will often need to interact with these applications directly.

While many clusters are focused on authenticating access to user-facing applications and services, cluster solutions are not given the same first-class status. Users often are asked to use kubectl's port-forward or proxy capability to access these systems. This method of access is an anti-pattern from a security and user experience standpoint. The first exposure users and administrators will have to this anti-pattern is the Kubernetes Dashboard. This chapter will detail why this method of access is an anti-pattern and how to properly access Dashboard. We'll walk you through...

Technical requirements

To follow the exercises in this chapter, you will require a fresh KinD cluster from Chapter 2, Deploying Kubernetes Using KinD.

You can access the code for this chapter at the following GitHub repository: https://github.com/PacktPublishing/Kubernetes---An-Enterprise-Guide-2E/tree/main/chapter7.

How does the dashboard know who you are?

The Kubernetes Dashboard is a powerful web application for quickly accessing your cluster from inside a browser. It lets you browse your namespaces and view the status of nodes, and even provides a shell you can use to access Pods directly. There is a fundamental difference between using the dashboard and kubectl. The dashboard, being a web application, needs to manage your session, whereas kubectl does not. This means there's a different set of security issues during deployment that are often not accounted for, leading to severe consequences. In this section, we'll explore how the dashboard identifies users and interacts with the API server.

Dashboard architecture

Before diving into the specifics of how the dashboard authenticates a user, it's important to understand the basics of how the dashboard works. The dashboard at a high level has three layers:

• User interface: This is the Angular + HTML frontend that...

Understanding dashboard security risks

The question of the dashboard's security often comes up when setting up a new cluster. Securing the dashboard boils down to how the dashboard is deployed, rather than if the dashboard itself is secure. Going back to the architecture of the dashboard application, there is no sense of "security" being built in. The middle tier simply passes a token to the API server.

When talking about any kind of IT security, it's important to look at it through the lens of defense in depth. This is the idea that any system should have multiple layers of security. If one fails, there are other layers to fill the gap until the failed layers can be addressed. A single failure doesn't give an attacker direct access.

The most often cited incident related to the dashboard's security was the breach of Tesla in 2018 by crypto-miners. Attackers were able to access Pods running in Tesla's clusters because the dashboard wasn&apos...

Deploying the dashboard with a reverse proxy

Proxies are a common pattern in Kubernetes. There are proxies at every layer in a Kubernetes cluster. The proxy pattern is also used by most service mesh implementations on Kubernetes, creating side cars that will intercept requests. The difference between the reverse proxy described here and these proxies is in their intent. Microservice proxies often do not carry a session, whereas web applications need a session to manage state.

The following diagram shows the architecture of a Kubernetes Dashboard with a reverse proxy:

Figure 7.6: Kubernetes Dashboard with a reverse proxy

The reverse proxy shown in Figure 7.6 performs three roles:

• Authentication: The reverse proxy intercepts unauthenticated requests (or stale sessions) and triggers the authentication process with an OpenID Connect identity provider to authenticate the user.
• Session management: Kubernetes' Dashboard is a user-facing application...

Integrating the dashboard with OpenUnison

The topic of how OpenUnison injected identity headers using impersonation was covered in Chapter 5, Integrating Authentication into Your Cluster, but not how OpenUnison injected user's identity into the dashboard with an OpenID Connect integrated cluster. It worked, but it wasn't explained. This section will use the OpenUnison implementation as an example of how to build a reverse proxy for the dashboard. Use the information in this section to get a better understanding of API security or to build your own solution for dashboard authentication.

The OpenUnison deployment comprises two integrated applications:

• The OpenID Connect Identity Provider & Login Portal: This application hosts the login process and the discovery URLs used by the API server to get the keys needed to validate an id_token. It also hosts the screens where you can obtain your token for kubectl.
• The dashboard: A reverse proxy application...

Summary

In this chapter, we explored the security of the Kubernetes Dashboard in detail. First, we walked through the architecture and how the dashboard passes your identity information on to the API server. We then explored how the dashboard gets compromised, and finally we detailed how to correctly deploy the dashboard securely.

With this knowledge, you can now provide a secured tool to your users. Many users prefer the simplicity of accessing the dashboard via a web browser. Adding multi-factor authentication adds an additional layer of security and peace of mind. When your security team questions the security of the dashboard, you'll have the answers needed to satisfy their concerns.

The previous three chapters focused on the security of the Kubernetes APIs. Next, in Chapter 8, Extending Security Using Open Policy Agent, we'll explore securing the soft underbelly of every Kubernetes deployment, nodes!

Questions

1. The dashboard is insecure.
   1. True
   2. False
2. How can the dashboard identify a user?
   1. The options are either no authentication, or a token injected from a reverse proxy
   2. Username and password
   3. ServiceAccount
   4. Multi-factor authentication
3. How does the dashboard track session state?
   1. Sessions are stored in etc
   2. Sessions are stored in custom resource objects called DashboardSession
   3. There are no sessions
   4. If a token is uploaded, it's encrypted and stored in the browser as a cookie
4. When using a token, how often can the dashboard refresh it?
   1. Once a minute
   2. Every thirty seconds
   3. When the token expires
   4. None of the above
5. What's the best way to deploy the dashboard?
   1. Using kubectl port-forward
   2. Using kubectl proxy
   3. With a secret Ingress...