Why Identity and Access Management in Kubernetes are so Important to get Right

Identity is one of the cornerstones of cyber security. Without a concept of identity, it is impossible to make decisions about access, permissions, or privileges in a system. But identities, and the “rights” attached to them, require management. Doing that within the context of Kubernetes is one of the recurring themes we hear in our conversations with customers. This article pulls together several themes we’ve written about before into a high-level guide on identity and access management within Kubernetes: what is it, what are its challenges, and why does it matter?

There are four critical pieces to any identity and access management scheme:

1. Authentication: how you know who a purported user is
2. Authorization: how you decide what a user should be allowed to do
3. Auditability: how you validate that a user is doing what they should be doing
4. Non-Repudiation: how you connect observed actions to a particular user

We’re going to consider each of these in turn.
‍

Authentication to a Kubernetes Cluster

What’s Easy:

Kubernetes comes out of the box with several methods for authenticating users, including using X.509 certificates and integrating with OIDC providers. Additionally, managed Kubernetes offerings from cloud services may integrate with existing cloud provider authentication systems. This means there are several options to choose from, and those options are, by design, meant to accommodate your existing authentication workflows.

What’s Hard:

Kubernetes doesn’t actually have a concept of a “human user” as an object within the cluster/API. That is because Kubernetes is expecting your authentication to be handled by an external system (see above), but it means that there isn’t a native “source of truth” about who the users in the cluster are. Instead, that job also falls to whatever external authentication system you are using. That means you need to control which users can access a cluster through that external system, not the cluster itself.

Furthermore, Kubernetes doesn’t have its own concept of a “session”: there is no built-in expiration time on user authentication. Instead, it relies on the authentication material provided by the external authentication system. For example, if that is an X.509 certificate, the user will be able to access the cluster as long as that certificate is valid. That makes a strong argument for using token-based authentication systems (such as OIDC) which have relatively short session lifetimes.