Kubernetes Authentication - Service Accounts and Plugins

In the Kubernetes ecosystem, authentication stands as a cornerstone, ensuring that only valid users can interact with the cluster. This lesson offers a comprehensive look into Kubernetes Authentication with Service Accounts and Plugins, shedding light on the confidential processes that verify user credentials.

Understanding User Types in Kubernetes

When a user request is initiated, Kubernetes immediately starts the authentication process. There are two distinct user types:

1. Regular Users: These are human users, managed externally by a user management system. Kubernetes doesn`t oversee these users. Instead, it communicates with the external system to verify credentials.
2. Service Accounts: Managed natively by Kubernetes, service accounts are unique Kubernetes objects. Each service account is linked to a secret, which contains a token used for authentication.

The Role of User Info

Post-authentication, before proceeding to the authorization phase, user info is appended to every request. For regular users, this information is sourced from the external user management system. In contrast, Kubernetes natively manages the info for service accounts. This includes details like Username, UID, Groups, and other essential fields.

Diving into Authentication Plugins

Kubernetes employs a variety of authentication plugins, including:

• X509 Client Certs
• Static token file
• Bootstrap token
• Service account token
• OpenID connect tokens
• Webhook token authentication
• Authenticating proxy
• Anonymous auth

These plugins not only facilitate authentication but also append user info to the requests.

In summary, whether it's a regular user or a service account, the authentication process verifies the credentials in the request. For regular users, the external user management system plays a pivotal role, while Kubernetes handles service accounts natively.