Integrating Authentication into Your Cluster

Once a cluster has been built, users will need to interact with it securely. For most enterprises, this means authenticating individual users and making sure they can only access what they need in order to do their jobs. With Kubernetes, this can be challenging because a cluster is a collection of APIs, not an application with a frontend that can prompt for authentication.

In this chapter, you'll learn how to integrate enterprise authentication into your cluster using the OpenID Connect protocol and Kubernetes impersonation. We'll also cover several anti-patterns and explain why you should avoid using them.

In this chapter, we will cover the following topics:

• Understanding how Kubernetes knows who you are
• Understanding OpenID Connect
• Configuring KinD for OpenID Connect
• How cloud Kubernetes knows who you are
• Configuring your cluster for impersonation
• Configuring impersonation without...

Technical requirements

To complete the exercises in this chapter, you will require the following:

• An Ubuntu 20.04 server with 8 GB of RAM
• A KinD cluster running with the configuration 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/chapter5.

Understanding how Kubernetes knows who you are

In the 1999 sci-fi film The Matrix, Neo talks to a child about the Matrix as he waits to see the Oracle. The child explains to him that the trick to manipulating the Matrix is to realize that "There is no spoon."

This is a great way to look at users in Kubernetes, because they don't exist. With the exception of service accounts, which we'll talk about later, there are no objects in Kubernetes called "User" or "Group." Every API interaction must include enough information to tell the API server who the user is and what groups the user is a member of. This assertion can take different forms, depending on how you plan to integrate authentication into your cluster.

In this section, we will get into the details of the different ways Kubernetes can associate a user with a cluster.

External users

Users who are accessing the Kubernetes API from outside the cluster will usually do so using...

Understanding OpenID Connect

OpenID Connect is a standard identity federation protocol. It's built on the OAuth2 specification and has some very powerful features that make it the preferred choice for interacting with Kubernetes clusters.

The main benefits of OpenID Connect are as follows:

• Short-lived tokens: If a token is leaked, such as via a log message or breach, you want the token to expire as quickly as possible. With OIDC, you're able to specify tokens that can live for 1-2 minutes, which means the token will likely be expired by the time an attacker attempts to use it.
• User and group memberships: When we start talking about authorization, we'll see quickly that it's important to manage access by group instead of managing access by referencing users directly. OIDC tokens can embed both the user's identifier and their groups, leading to easier access management.
• Refresh tokens scoped to timeout policies: With short-lived tokens...

Configuring KinD for OpenID Connect

For our example deployment, we will use a scenario from our customer, FooWidgets. FooWidgets has a Kubernetes cluster that they would like integrated using OIDC. The proposed solution needs to address the following requirements:

• Kubernetes must use our central authentication system, Active Directory
• We need to be able to map Active Directory groups into our RBAC RoleBinding objects
• Users need access to the Kubernetes Dashboard
• Users need to be able to use the CLI
• All enterprise compliance requirements must be met
• Additional cluster management applications need to be managed centrally as well

Let's explore each of these in detail and explain how we can address the customer's requirements.

Addressing the requirements

Our enterprise's requirements require multiple moving parts, both inside and outside our cluster. We'll examine each of these components and how they relate...

Introducing impersonation to integrate authentication with cloud-managed clusters

It's very popular to use managed Kubernetes services from cloud vendors such as Google, Amazon, Microsoft, and DigitalOcean (among many others).

When it comes to these services, they are generally very quick to get up and running, and they all share a common thread: they mostly don't support OpenID Connect (Amazon's EKS does support OpenID Connect now, but the cluster must be running on a public network and have a commercially signed TLS certificate).

Earlier in this chapter, we talked about how Kubernetes supports custom authentication solutions through webhooks and that you should never, ever, use this approach unless you are a public cloud provider or some other host of Kubernetes systems. It turns out that pretty much every cloud vendor has its own approach to using these webhooks that uses their own identity and access management implementations. In that case, why not just...

Configuring your cluster for impersonation

Let's deploy an impersonating proxy for our cluster. Assuming you're reusing your existing cluster, we'll upgrade our existing orchestra Helm deployment with an updated openunison-values.yaml file:

1. First, delete the current TLS secret for OpenUnison since it doesn't have the right configuration for Impersonation. When we update the orchestra Helm chart, the operator will generate a new certificate for us.

   kubectl delete secret ou-tls-certificate -n openunison
   

2. Next, update our Helm chart to use impersonation. Edit the openunison-values.yaml file, update network.api_server_host as shown in the following snippet, and set enable_impersonation to true:

   network:
     openunison_host: "k8sou.apps.192-168-2-131.nip.io"
     dashboard_host: "k8sdb.apps.192-168-2-131.nip.io"
     api_server_host: "k8sapi.apps.192-168-2-131.nip.io"
     session_inactivity_timeout_seconds...

Configuring Impersonation without OpenUnison

The OpenUnison operator automated a couple of key steps to get impersonation working. There are other projects designed specifically for Kubernetes, such as Jetstack's OIDC proxy (https://github.com/jetstack/kube-oidc-proxy), that are designed to make using Impersonation easier. You can use any reverse proxy that can generate the correct headers. There are two critical items to understand when doing this on your own.

Impersonation RBAC policies

RBAC will be covered in the next chapter, but for now, the correct policy to authorize a service account for Impersonation is as follows:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: impersonator
rules:
- apiGroups:
  - ""
  resources:
  - users
  - groups
  verbs:
  - impersonate

To constrain what accounts can be impersonated, add resourceNames to your rule.

Default groups

When impersonating a user, Kubernetes does not add the...

Authenticating from pipelines

This chapter so far has focused exclusively on authentication to Kubernetes by users. Whether an operator or a developer, a user will often interact with a cluster to update objects, debug issues, view logs, and so on. This doesn't quite handle all use cases, though. Most Kubernetes deployments are partnered with pipelines, a process by which code is moved from source to binaries to containers and ultimately into a running cluster. We'll cover pipelines in more detail in Chapter 14, Provisioning a Platform. For now, the main question is "How will your pipeline talk to Kubernetes securely?"

If your pipeline runs in the same cluster as being updated, this is a simple question to answer. You would grant access to the pipeline's service account via RBAC to do what it needs to do. This is why service accounts exist, to provide identity to processes inside the cluster.

What if your pipeline runs outside of the cluster? Kubernetes...

Summary

This chapter detailed how Kubernetes identifies users and what groups their members are in. We detailed how the API server interacts with identities and explored several options for authentication. Finally, we detailed the OpenID Connect protocol and how it's applied to Kubernetes.

Learning how Kubernetes authenticates users and the details of the OpenID Connect protocol is an important part of building security into a cluster. Understanding the details and how they apply to common enterprise requirements will help you decide the best way to authenticate to clusters, and also provide justification regarding why the anti-patterns we explored should be avoided.

In the next chapter, we'll apply our authentication process to authorizing access to Kubernetes resources. Knowing who somebody is isn't enough to secure your clusters. You also need to control what they have access to.

Questions

1. OpenID Connect is a standard protocol with extensive peer review and usage.
   1. True
   2. False
2. Which token does Kubernetes use to authorize your access to an API?
   1. access_token
   2. id_token
   3. refresh_token
   4. certificate_token
3. In which situation is certificate authentication a good idea?
   1. Day-to-day usage by administrators and developers
   2. Access from external CI/CD pipelines and other services
   3. Break glass in case of emergency when all other authentication solutions are unavailable
4. How should you identify users accessing your cluster?
   1. Email address
   2. Unix login ID
   3. Windows login ID
   4. An immutable ID not based on a user's name
5. Where are OpenID Connect configuration options set in Kubernetes?
   1. Depends on the distribution
   2. In a ConfigMap object
   3. In...