Chapter 3. Authentication
If you’ve been using public cloud offerings such as Amazon Web Services (AWS), Microsoft Azure, or Google Cloud Platform, you might have come across the term identity and access management (IAM), which allows you to define access to resources for users and services. In this chapter and in Chapter 4, we discuss how this is realized in Kubernetes.
All components, such as a kubelet running on a node, as well as users issuing kubectl commands, need to communicate with the API server. To process the request, the API server first has to verify who (or what, in the case of machines) is issuing the request; the server has to establish the identity of the caller, or in other words, to authenticate the caller. This chapter covers how authentication in Kubernetes works and the options you have at hand as a cluster operator.
Identity
For the API server to authenticate a request, the request issuer needs to possess an identity. At the time of writing, Kubernetes doesn’t have a first-class notion of a human user, but rather assumes that users are managed outside Kubernetes via a directory service such as Lightweight Directory Access Protocol (LDAP) or single sign-on (SSO) login standards like Security Assertion Markup Language (SAML) or Kerberos. This is the standard approach in production, but if you’re not using such a system, other authentication strategies are available.
User accounts are considered cluster-wide, so make sure that the usernames are unique across ...
Get Kubernetes Security now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
