Lesson 03 — Kubernetes Control Plane Components

Learning Objectives

By the end of this lesson, you will be able to:

Understand the purpose of the Kubernetes Control Plane
Identify each Control Plane component
Explain how the components work together
Understand the flow of requests inside the Control Plane
Recognise common security risks affecting the Control Plane
Apply security best practices to protect critical Kubernetes infrastructure

Why This Matters

The Control Plane is the brain of Kubernetes.

Every action performed in Kubernetes—including creating Pods, deploying applications, managing Secrets, configuring RBAC, and scaling workloads—passes through the Control Plane.

If an attacker compromises the Control Plane, they can effectively gain control over the entire Kubernetes cluster.

For this reason, securing the Control Plane is one of the highest priorities for a Kubernetes Security Engineer.

What is the Kubernetes Control Plane?

The Control Plane is a collection of services responsible for managing the entire Kubernetes cluster.

It continuously monitors the environment and ensures that the actual state of the cluster matches the desired state defined by administrators.

It is responsible for:

Managing cluster configuration
Scheduling workloads
Maintaining desired state
Authentication
Authorization
Cluster health monitoring
Communication between cluster components

Kubernetes Control Plane Overview

                kubectl
                    │
                    ▼
          Kubernetes API Server
                    │
      ┌─────────────┼─────────────┐
      │             │             │
      ▼             ▼             ▼
 Scheduler   Controller Manager   etcd
                    │
                    ▼
          Worker Nodes

Every request enters through the API Server before being processed by the other Control Plane services.

Components of the Control Plane

Component	Responsibility
API Server	Entry point for all Kubernetes requests
Scheduler	Assigns Pods to Worker Nodes
Controller Manager	Maintains desired cluster state
etcd	Stores cluster configuration and state
Cloud Controller Manager	Integrates Kubernetes with cloud services

Each component performs a specific role while working together to keep the cluster operational.

Kubernetes API Server

The API Server is the central management interface for Kubernetes.

It exposes the Kubernetes REST API and processes requests from:

kubectl
Kubernetes Dashboard
CI/CD pipelines
Automation tools
Controllers
Operators
External integrations

Examples of API requests include:

Creating Pods
Updating Deployments
Viewing logs
Managing Secrets
Creating Namespaces
Configuring RBAC

Without the API Server, Kubernetes cannot be managed.

Request Flow

Administrator

↓

kubectl

↓

API Server

↓

Authentication

↓

Authorization

↓

Admission Controllers

↓

etcd / Scheduler / Controllers

Every request follows this sequence before being executed.

Authentication

Before accepting a request, the API Server verifies the identity of the requester.

Common authentication methods include:

Client certificates
IAM integration
Service Accounts
OpenID Connect (OIDC)
Authentication tokens

Authentication answers the question:

Who are you?

Authorization

Once authenticated, Kubernetes checks whether the requester has permission to perform the requested action.

Authorization is commonly implemented using:

RBAC
ABAC (legacy)
Webhook authorization

Authorization answers:

What are you allowed to do?

Admission Controllers

Admission Controllers evaluate requests before they are stored in etcd.

They can:

Reject insecure deployments
Enforce security policies
Require labels
Block privileged containers
Validate configurations

Think of Admission Controllers as security checkpoints.

Kubernetes Scheduler

The Scheduler determines where new Pods should run.

It evaluates available Worker Nodes based on:

CPU availability
Memory availability
Resource requests
Affinity and anti-affinity rules
Taints and tolerations
Node selectors
Scheduling constraints

Once a suitable node is identified, the Scheduler assigns the Pod to that node.

Example

Deployment Created

↓

API Server

↓

Scheduler

↓

Best Worker Node Selected

↓

Pod Starts

The Scheduler does not run containers; it simply decides where they should run.

Controller Manager

The Controller Manager ensures that the cluster continuously matches its desired state.

For example:

Desired State:

5 Web Pods

Current State:

4 Running

The Controller Manager immediately creates a replacement Pod.

This process enables Kubernetes’ self-healing capability.

Major Controllers

Examples include:

Deployment Controller
ReplicaSet Controller
Node Controller
Namespace Controller
Service Account Controller
Endpoint Controller
Job Controller

Each controller manages a specific aspect of the cluster.

etcd

etcd is Kubernetes’ distributed key-value database.

It stores nearly all cluster information, including:

Deployments
Pods
Services
Namespaces
Secrets
ConfigMaps
RBAC configuration
Service Accounts
Network Policies
Cluster settings

It is the single source of truth for the Kubernetes cluster.

Why etcd is Critical

Every time Kubernetes starts, it reads cluster information from etcd.

If etcd becomes unavailable:

Cluster management stops
New workloads cannot be scheduled
Configuration changes fail
Cluster recovery becomes difficult

Protecting etcd is therefore essential.

Security Risks to etcd

Attackers targeting etcd may attempt to obtain:

Kubernetes Secrets
API tokens
Service Account credentials
Certificates
Cluster configuration
Administrative permissions

An exposed or unencrypted etcd database can lead to complete cluster compromise.

Cloud Controller Manager

When Kubernetes runs in cloud environments, the Cloud Controller Manager communicates with cloud provider APIs.

Examples include:

AWS

Elastic Load Balancer
EC2 Instances
EBS Volumes
Security Groups
Auto Scaling

Azure

Virtual Machines
Azure Load Balancer
Managed Disks

Google Cloud

Compute Engine
Persistent Disks
Cloud Load Balancers

Managed services such as Amazon EKS handle many of these integrations automatically.

How Components Work Together

Consider a developer deploying a new application.

kubectl apply deployment.yaml

↓

API Server

↓

Authentication

↓

Authorization

↓

Admission Controllers

↓

etcd stores deployment

↓

Scheduler selects Worker Node

↓

kubelet starts Pod

↓

Controller Manager monitors health

↓

Application Running

Every Control Plane component contributes to this workflow.

Enterprise Example

A financial organisation deploys a new payment service.

The deployment process involves:

Developer submits deployment
API Server validates the request
RBAC verifies permissions
Admission Controllers ensure compliance
Scheduler selects a secure Worker Node
Controller Manager maintains availability
etcd stores configuration
Monitoring tools begin collecting telemetry

This entire process occurs within seconds.

Common Security Risks

Cloud Security Engineers frequently identify the following Control Plane issues:

Publicly exposed API Server
Weak authentication
Excessive RBAC permissions
Unencrypted etcd
Disabled audit logging
Anonymous API access
Missing Admission Controllers
Outdated Kubernetes versions
Insecure certificates
Poor Secrets management

These weaknesses can allow attackers to gain administrative control over the cluster.

Control Plane Hardening Best Practices

Always:

Restrict API Server access
Enable RBAC
Enforce least privilege
Encrypt etcd
Rotate certificates regularly
Enable audit logging
Disable anonymous authentication
Protect Secrets
Keep Kubernetes up to date
Enable multi-factor authentication where applicable
Monitor API activity continuously

A hardened Control Plane significantly reduces the attack surface.

Enterprise Security Monitoring

Security teams should monitor:

Failed authentication attempts
RBAC changes
Secret access
Cluster-admin assignments
API Server errors
Unusual API activity
Node registration events
Admission Controller failures
Scheduler anomalies
etcd access

Continuous monitoring helps detect attacks early.

Key Takeaways

After completing this lesson, you should understand:

The purpose of the Kubernetes Control Plane
The role of the API Server
How the Scheduler assigns workloads
How the Controller Manager maintains cluster health
Why etcd is the most sensitive component
How cloud providers integrate with Kubernetes
Best practices for securing the Control Plane

A strong understanding of the Control Plane is essential before learning about Worker Nodes, Pods, networking, and workload security.

Knowledge Check

Question 1

Which Control Plane component is the primary entry point for all Kubernetes requests?

A. Scheduler
B. kubelet
C. API Server
D. Deployment

Answer: C

Question 2

Which component stores the Kubernetes cluster configuration?

A. kube-proxy
B. etcd
C. ReplicaSet
D. Namespace

Answer: B

Question 3

Which Control Plane component decides where a Pod should run?

A. Controller Manager
B. Scheduler
C. kubelet
D. API Server

Answer: B

Question 4

What is the primary responsibility of the Controller Manager?

A. Running containers
B. Managing network traffic
C. Maintaining the desired state of the cluster
D. Storing container images

Answer: C

Question 5

Which Control Plane component is considered the “single source of truth” for Kubernetes?

A. Scheduler
B. kube-proxy
C. etcd
D. kubelet

Answer: C

What’s Next?

In the next lesson, you will move from the Control Plane to the worker infrastructure and learn how Worker Nodes execute workloads, how kubelet, containerd, and kube-proxy operate, and what security controls are required to protect Kubernetes compute resources.

➡️ Next Lesson: Lesson 04 — Kubernetes Worker Nodes