DIY Kubernetes Access Management with Dex and KubeLogin

June 16, 2022

As the usage of Kubernetes grows, its complexities and risks also grow. In one of our earlier blog posts, Multi-cluster Kubernetes Management and Access, we spoke about the challenges of managing access to multiple Kubernetes clusters. We discussed how managing access can be a nightmare, especially when you have tens, hundreds, or even thousands of clusters, not to mention the number of people working in them! In such situations, deploying yaml files to manually configure roles for each person or service is a daunting task. You need to have a robust mechanism in place that will help you manage and secure access to your Kubernetes clusters.

In this blog post, we’ll first do a hands-on demo showing you how to leverage open-source tools available to develop your own access management mechanism. Then, we’ll discuss the potential caveats with our solution, and talk about some considerations when scaling access control to multiple clusters.

Security in Kubernetes

Whether you are accessing a local system or leveraging a cloud identity service, the process of authentication and authorization are common across the cloud native landscape. Authentication is the process of verifying the identity of the person trying to access the server. Authorization is the process of verifying that this person has been granted access to the resources they are requesting.

Before we deep dive into our DIY implementation, let’s take a look at the options Kubernetes provides out-of-the-box when it comes to authentication & authorization.

User Accounts

Kubernetes distinguishes between two types of accounts: user accounts and service accounts. User accounts are for humans. Service accounts are for processes. User accounts are managed by a cluster independent service by means of private keys, user key store or even (unfortunately, still) a file with a list of usernames and passwords. Kubernetes doesn't have any objects that represent user accounts. If a user knocks on a cluster’s door with a valid signed certificate, Kubernetes will allow them in, and check against its own RBAC policies to provide or restrict access to appropriate resources. Service accounts are managed via the Kubernetes API. These users are bound to namespaces and can be created/modified by the API server itself, or by other accounts making API calls to it. Service account credentials are usually stored as secrets mounted into pods.

Authentication Strategies

Kubernetes implements a variety of authentication strategies. All HTTP requests made to the API server must be authenticated by either using bearer tokens, client certificates or authenticating proxies. Below are a few authentication methods that Kubernetes supports out of the box:

• X509 Client Certificates: allows you to pass signed certificates by a valid certifying authority by using the –-client-ca-file= flag.
• Static Token File: you can place static tokens in a file and use the –-token-auth-file= flag.
• Bearer Token: the API server expects an Authorization header with a value of Bearer <token>.
• OpenID Connect Tokens: OIDC is an extension of OAuth2 with an additional field called ID Token.
• Authentication Proxy: allows the API server to identify the users from the request header values.

These are just a few ways you can have a custom authentication mechanism in place. Refer to the complete list of Authentication Strategies offered by Kubernetes.

DIY Access Management using DEX and KubeLogin

To demonstrate some Kubernetes authentication strategies in action, we’ll implement a custom access management tool using two open-source projects: Dex and Kubelogin. Dex: an identity service that uses OpenId Connect to handle authentication for applications. Kubelogin: a kubectl plugin that allows the user to login using any of the identity service providers.

How it works

A user fires up the terminal and runs a normal kubectl command, triggering KubeLogin, which opens the browser to authenticate via GitHub.

Setup

GitHub

1. Log in to GitHub and navigate to Settings.
2. Click on Developer Settings and under OAuth Apps, click on New OAuth App.
3. Fill in the application details and register the application.

Kubelogin

Install the Kubelogin plugin on your cluster using krew: kubectl krew install oidc-login

Configuring API Server

Configure the Kubernetes API server with the OIDC parameters using appropriate flags.

Deploying Dex

Ensure SSL is configured for Dex, and deploy it to Kubernetes using a configuration file.

Testing and Running Our Setup

Run kubectl oidc-login setup to test the setup, launching a browser for authentication via Dex and GitHub.

Issues with the DIY Approach

This approach is not scale friendly and can result in errors due to manual configuration. Managing SSL certificates becomes increasingly painful with more clusters. The DIY method works well for single clusters but may not be suitable for enterprise environments.

Conclusion

While a DIY approach for managing K8s access is useful for development, enterprises need robust solutions that provide secure authentication, authorization, and comprehensive support for multi-cluster environments. Rafay is one such modern platform that includes these features.