KCSA — Authentication & Authorization
Chapter 4 — Authentication & Authorization
Welcome to Chapter 4 of the KCSA preparation series. This chapter covers identity and access control in Kubernetes — how the API server verifies who is making a request and what they are allowed to do.
KCSA Domain: Kubernetes Cluster Security — 22 % of the exam.
Authentication and authorization sit at the core of every Kubernetes security model. Every kubectl command, every pod-to-API-server call, and every webhook invocation passes through the API server’s authentication and authorization chain before anything happens in the cluster.
What You Will Learn
| # | Topic | Description |
|---|---|---|
| 1 | Authentication Methods | Client certs, tokens, OIDC, service accounts |
| 2 | Role-Based Access Control (RBAC) | Roles, ClusterRoles, RoleBindings, ClusterRoleBindings |
| 3 | Service Accounts & Token Security | Default SA risks, token projection, audience-bound tokens |
| 4 | User & Group Management | Human users, groups, identity providers, OIDC integration |
| 5 | Authorization Modes & Best Practices | RBAC, ABAC, Node, Webhook — why RBAC is the standard |
After completing all five topics, test yourself with the Practice Questions.
Why This Chapter Matters for the KCSA
The KCSA is a multiple-choice, conceptual exam. You will not be asked to write RBAC manifests from scratch, but you will be expected to:
- Identify the correct authentication method for a given scenario.
- Understand the four RBAC resources and how they relate to each other.
- Recognize insecure defaults (e.g., auto-mounted service account tokens).
- Know the difference between authorization modes and which combination is recommended.
- Apply the principle of least privilege to real-world role designs.
Exam Tip: Questions often present a scenario and ask you to pick the most secure or recommended option. Knowing why RBAC is preferred over ABAC, or why projected tokens replaced legacy tokens, is more important than memorizing YAML fields.
The Authentication → Authorization → Admission Flow
Every request to the Kubernetes API server passes through three gates:
Client Request
│
▼
┌──────────────┐
│ Authentication│ ← "Who are you?"
└──────┬───────┘
│
▼
┌──────────────┐
│ Authorization │ ← "What can you do?"
└──────┬───────┘
│
▼
┌──────────────────┐
│ Admission Control │ ← "Should this be modified or rejected?"
└──────┬───────────┘
│
▼
etcd / Action
This chapter focuses on the first two gates. Admission control is covered in a later chapter.
Prerequisites
Before starting this chapter, make sure you have completed:
- Chapter 1 — Cloud-Native Security Foundations
- Chapter 2 — Kubernetes Architecture & Security
- Chapter 3 — Threat Modeling & Compliance
These chapters establish the security vocabulary and architectural context you need to understand authentication and authorization in depth.
Ready to Begin?
Start with the first topic in this chapter:
Or jump directly to any topic using the table above.
