Kubernetes Cluster Component Security for the KCSA Exam: Securing the API Server, etcd, Kubelet, Controller Manager & Scheduler

Introduction

Kubernetes Cluster Component Security is the single heaviest domain on the KCSA exam, weighing in at 22% of your score — tied with Kubernetes Security Fundamentals. It’s also the domain that separates people who use Kubernetes from people who understand how it’s built. The questions here rarely ask “what does the API server do?” They ask “the API server accepts an anonymous request — what went wrong, and which flag would have stopped it?”

That framing matters. To answer cluster-component questions well, you need a mental model of every process that makes up a cluster, what each one trusts, and where each one can be attacked. This guide walks through the control plane and node components exactly the way the KCSA tests them: component by component, risk by risk, with the configuration that hardens each one. Every flag and manifest here is something you can verify against the official Kubernetes documentation and the CIS Kubernetes Benchmark.

If you’re still mapping the whole exam, start with the KCSA exam guide for 2026 and the KCSA study plan. This article is the deep dive on the cluster-components domain; the 4Cs of Cloud Native Security and the Kubernetes threat model cover two of the other domains.

The Cluster Component Map

Before securing anything, you have to know what’s running. A Kubernetes cluster is a set of cooperating processes split across the control plane and the worker nodes.

Component	Runs on	Job	Why attackers want it
kube-apiserver	Control plane	Front door for all cluster operations	Full cluster control if access is gained
etcd	Control plane	Stores all cluster state, including Secrets	Cluster’s source of truth; secrets live here
kube-controller-manager	Control plane	Runs control loops; signs service account tokens	Holds the SA signing key
kube-scheduler	Control plane	Assigns Pods to nodes	Can influence where workloads land
kubelet	Every node	Runs and manages Pods on its node	Node-level code execution
kube-proxy	Every node	Programs service networking (iptables/IPVS)	Network manipulation
Container runtime	Every node	Pulls images and runs containers	Container breakout to host

The guiding principle the exam rewards: every component should authenticate, authorize, and encrypt — and nothing should trust the network by default.

Securing the kube-apiserver

The API server is the only component that talks to etcd and the only front door into the cluster. Every kubectl command, every controller, every kubelet heartbeat passes through it. Compromise it and you own the cluster. The KCSA expects you to know its three-stage request pipeline:

Authentication — who are you? (client certificates, bearer tokens, OIDC, service account tokens)
Authorization — are you allowed? (RBAC, Node, Webhook, ABAC)
Admission control — should this specific request be allowed and possibly mutated? (admission controllers like PodSecurity, NodeRestriction)

A request must pass all three. The most common hardening flags:

# kube-apiserver static pod manifest (excerpt)
spec:
  containers:
  - command:
    - kube-apiserver
    - --anonymous-auth=false               # reject unauthenticated requests
    - --authorization-mode=Node,RBAC       # never AlwaysAllow
    - --enable-admission-plugins=NodeRestriction,PodSecurity
    - --audit-log-path=/var/log/kubernetes/audit.log
    - --tls-cert-file=/etc/kubernetes/pki/apiserver.crt
    - --tls-private-key-file=/etc/kubernetes/pki/apiserver.key
    - --client-ca-file=/etc/kubernetes/pki/ca.crt

Things the exam loves to test:

--anonymous-auth=false — when anonymous auth is on, unauthenticated requests are mapped to the user system:anonymous. If RBAC then grants that user anything, you have a hole.
--authorization-mode must never be AlwaysAllow. The combination Node,RBAC is the production standard. Node authorizes kubelets; RBAC authorizes everyone else.
The legacy insecure port is gone. Older Kubernetes exposed an unauthenticated --insecure-port 8080. It has been removed in modern versions — but the exam may still describe it as a classic misconfiguration.
Audit logging (--audit-log-path + an audit policy) is how you reconstruct what happened after an incident.

Securing etcd

If the API server is the front door, etcd is the vault. It stores the entire desired and observed state of the cluster — including every Secret object. The single most important KCSA fact about etcd:

By default, Secrets are stored in etcd only base64-encoded, not encrypted. Anyone who can read etcd can read every Secret in plaintext.

Three controls protect etcd:

1. Encryption at rest. Configure the API server with an EncryptionConfiguration so Secrets are encrypted before they’re written to etcd:

apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
  - resources:
      - secrets
    providers:
      - aescbc:
          keys:
            - name: key1
              secret: <base64-encoded-32-byte-key>
      - identity: {}   # fallback for reads of unencrypted data

The API server is started with --encryption-provider-config pointing at this file. In production, the secret is typically backed by a KMS provider rather than a local key.

2. Transport security (mTLS). etcd should require TLS for both client-to-server (port 2379) and peer-to-peer (port 2380) traffic. Only the API server should hold a valid client certificate.

3. Network isolation. etcd should never be reachable from the pod network or the internet. Firewall rules should limit 2379/2380 to control-plane nodes only. A common attack path the exam describes: an attacker reaches an unauthenticated etcd endpoint and dumps every Secret.

Securing the kubelet

The kubelet is the agent on every node that actually starts containers, mounts volumes, and reports status. It exposes an API on port 10250. If that API is unauthenticated, anyone who can reach the node can run commands inside your Pods (kubelet ... /exec) — effectively node-level code execution.

# kubelet config (KubeletConfiguration) hardening
apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
authentication:
  anonymous:
    enabled: false          # no anonymous kubelet API access
  webhook:
    enabled: true           # delegate authn to the API server
authorization:
  mode: Webhook             # delegate authz to the API server (never AlwaysAllow)
readOnlyPort: 0             # disable the unauthenticated read-only port 10255
rotateCertificates: true    # auto-rotate the kubelet's client cert

Key exam points:

anonymous.enabled: false and authorization.mode: Webhook together ensure the kubelet asks the API server “is this caller allowed?” for every request.
readOnlyPort: 0 disables port 10255, a legacy unauthenticated endpoint that leaks pod and node metadata.
NodeRestriction admission plugin limits what a kubelet can modify to only its own node and the pods bound to it — so a single compromised node can’t rewrite the whole cluster.
The kubelet authenticates to the API server using a node certificate; certificate rotation keeps that credential short-lived.

Securing the Controller Manager and Scheduler

These two control-plane components have a smaller attack surface than the API server, but the KCSA still expects you to know their specific risks.

kube-controller-manager runs dozens of control loops and — critically — signs service account tokens using the cluster’s private key (--service-account-private-key-file). Whoever can read that key can mint tokens for any service account. Hardening:

--use-service-account-credentials=true   # each controller uses its own SA, least privilege
--bind-address=127.0.0.1                  # serving endpoint not exposed on the network
--root-ca-file=/etc/kubernetes/pki/ca.crt

kube-scheduler decides which node a Pod runs on. Its risk is smaller, but binding its serving endpoint to localhost and disabling profiling endpoints reduces exposure:

--bind-address=127.0.0.1
--profiling=false

Both components should authenticate to the API server with their own least-privileged identities, and their kubeconfig files (which contain credentials) must be protected with strict file permissions on the control-plane node.

kube-proxy and the Container Runtime

kube-proxy programs the node’s iptables or IPVS rules to implement Service networking. It runs with elevated privileges and reads a kubeconfig; protect that kubeconfig and keep kube-proxy’s RBAC permissions minimal. Many managed and modern clusters now replace kube-proxy with an eBPF dataplane (such as Cilium), which the exam may reference as an alternative.

The container runtime (containerd or CRI-O via the CRI interface) is where container isolation actually happens. The KCSA connects runtime security to several Pod-level controls:

seccomp profiles restrict which syscalls a container can make (RuntimeDefault is the baseline recommendation).
AppArmor / SELinux add mandatory access control on the host.
Sandboxed runtimes (gVisor, Kata Containers) provide stronger isolation for untrusted workloads by adding a layer between the container and the host kernel.

A container breakout — escaping to the host — is the runtime’s worst-case failure, and most breakouts start with a container that was allowed to run as root or with extra Linux capabilities.

Pod-Level Security: Where Components Meet Workloads

Cluster components enforce security, but the workloads themselves must be configured to be secure. The securityContext is your primary tool, and it shows up constantly on the KCSA:

apiVersion: v1
kind: Pod
metadata:
  name: hardened-app
spec:
  securityContext:
    runAsNonRoot: true
    seccompProfile:
      type: RuntimeDefault
  containers:
    - name: app
      image: myorg/app:1.0
      securityContext:
        allowPrivilegeEscalation: false
        readOnlyRootFilesystem: true
        capabilities:
          drop: ["ALL"]

What each line buys you:

Setting	Protection
`runAsNonRoot: true`	Container can’t run as UID 0; blocks a whole class of breakouts
`allowPrivilegeEscalation: false`	Process can’t gain more privileges than its parent (no setuid escalation)
`readOnlyRootFilesystem: true`	Attacker can’t write tools or persistence to the container filesystem
`capabilities.drop: ["ALL"]`	Removes Linux capabilities; add back only what’s strictly needed
`seccompProfile: RuntimeDefault`	Blocks dangerous syscalls at the kernel boundary

These map directly to the Pod Security Standards (Privileged, Baseline, Restricted) enforced by the built-in Pod Security Admission controller — a topic that bridges this domain and Kubernetes Security Fundamentals.

Verifying It All: The CIS Benchmark and kube-bench

You don’t have to remember every flag from memory in real life — the CIS Kubernetes Benchmark codifies these recommendations, and the open-source tool kube-bench checks a running cluster against it:

# Run the CIS Kubernetes Benchmark checks against the current node
kube-bench run --targets master,node

# Example finding it flags:
# [FAIL] 1.2.1 Ensure that the --anonymous-auth argument is set to false

The KCSA expects you to recognize the concept — that there’s a published benchmark and tooling to audit against it — more than the exact check numbers. For the hands-on, CKS-level version of this same auditing work, see Kubernetes security best practices and the CKS cluster setup and hardening guide. If you’re deciding which security cert to pursue, KCSA vs. CKS breaks down the difference.

Common Mistakes on This Domain

Mistake	Reality
Assuming Secrets are encrypted in etcd	They’re only base64-encoded unless you enable encryption at rest
Thinking `--authorization-mode=AlwaysAllow` is ever acceptable	It disables authorization entirely; use `Node,RBAC`
Forgetting the kubelet has its own API	Port 10250 needs authn/authz; 10255 should be disabled
Treating the scheduler/controller-manager as harmless	The controller manager signs SA tokens; protect its key
Confusing authentication with authorization	Authn = who you are; authz = what you can do; both run before admission
Ignoring the container runtime	Most breakouts begin with a root container and excess capabilities

Conclusion

The Cluster Component Security domain rewards a clear mental model over memorization. If you can sketch the components, name what each one trusts, and recall the one or two flags that harden each — --anonymous-auth=false on the API server and kubelet, encryption at rest and mTLS for etcd, Node,RBAC authorization, a locked-down securityContext on every Pod — you’ll handle most questions in this 22% slice with confidence.

The fastest way to lock that model in is repetition under exam conditions: see a misconfiguration, identify the component, name the fix. That’s exactly what realistic practice questions train.

Practice Until Every Component Is Second Nature

Reading about the API server, etcd, and the kubelet builds understanding; answering timed, scenario-based questions builds exam readiness. The two reinforce each other — concepts give you the “why,” and practice questions surface the gaps you didn’t know you had.

Sailor.sh’s KCSA mock exam bundle is built around the real exam’s domain weights, so the Cluster Component Security questions get the emphasis they deserve — each with an explanation of why an answer is right, not just which option to pick. Use the free KCSA practice questions to benchmark where you stand, then close the gaps with full mock exams and the KCSA study plan. If you’re still weighing the cert, is KCSA worth it? lays out the career case.

Frequently Asked Questions

Why is Cluster Component Security worth 22% of the KCSA?

It’s tied for the largest domain because nearly every cluster compromise traces back to a component misconfiguration — an exposed kubelet, an unencrypted etcd, or an over-permissive API server. Understanding these components is foundational to everything else in cloud native security.

Are Kubernetes Secrets encrypted by default?

No. By default, Secret objects are only base64-encoded in etcd, which is trivially reversible. You must configure encryption at rest with an EncryptionConfiguration (ideally backed by a KMS provider) to encrypt them. This is one of the most frequently tested facts on the exam.

What’s the difference between the API server’s authentication and authorization?

Authentication answers “who are you?” using client certificates, tokens, or OIDC. Authorization answers “are you allowed to do this?” using RBAC, the Node authorizer, or webhooks. A request must pass authentication first, then authorization, then admission control — all three before it takes effect.

Why does the kubelet need its own authentication?

The kubelet exposes an API (port 10250) that can execute commands inside Pods and read their logs. If that API allows anonymous access, anyone who can reach the node gains code execution inside your workloads. Setting anonymous.enabled: false and authorization.mode: Webhook forces every request to be authenticated and authorized by the API server.

Do I need to memorize every kube-apiserver flag for the KCSA?

No. The KCSA is a multiple-choice, knowledge-level exam — it tests whether you understand the purpose of controls like disabling anonymous auth, using Node,RBAC authorization, and enabling audit logging. You should recognize the key flags and what they protect, but you won’t be asked to write a full manifest from scratch.

What is kube-bench and why does it matter?

kube-bench is an open-source tool that checks a running cluster against the CIS Kubernetes Benchmark — a published set of security configuration recommendations. It automates the audit of exactly the controls covered in this domain, which is why the exam references the CIS Benchmark as the authoritative hardening standard.

Ready to make Cluster Component Security a strength? Drill realistic, explained questions with the Sailor.sh KCSA mock exams, then map your full prep with the KCSA exam guide for 2026.