Memory hook: The API admits; controllers reconcile; the scheduler places; etcd remembers.
Must remember
The API server is the normal entry point for cluster management. Protect its reachable endpoints, validate TLS certificates and configure authentication, authorization and admission. A typical write request establishes identity, checks permission and passes applicable admission/validation before persistence. API audit logs provide evidence of requests. Direct access to etcd or node endpoints can bypass some API protections, so protect those separately.
The controller manager runs reconciliation loops that move observed state toward desired state. A controller may create Pods or update other resources with its own credentials. Scope those credentials to its responsibility and protect its configuration, credentials and serving endpoints. Installing an operator also installs a controller with whatever permissions its manifests grant; review them.
The scheduler selects a node for an unscheduled Pod according to constraints and available resources. It does not run containers itself. Protect scheduler configuration, plugins, credentials and access to its endpoints. A malicious scheduler or privileged configuration change can place workloads on unsuitable nodes or disrupt availability. Scheduling isolation depends on who can set node labels, taints and workload placement constraints.
Etcd stores Kubernetes API data, including sensitive objects. Restrict client and peer network access, authenticate and encrypt connections, protect files and snapshots, and configure API storage encryption where needed. API encryption at rest and transport TLS solve different problems. A copied etcd snapshot can expose information; secure and test backups rather than placing them in a broadly readable bucket. Encryption also requires protection and recoverability of the associated keys.
The user-facing client is part of the trust boundary. A kubeconfig can contain tokens, private-key references, server addresses and executable credential plugins. Treat an untrusted kubeconfig as potentially dangerous; inspect its source and configuration before using it. Protect local credential files and avoid insecure-skip-tls-verify, which weakens server identity validation.
Check context and namespace before inspecting or changing a cluster. Use separate least-privilege identities for users and automation, short-lived credentials where supported, and a controlled identity-provider login process. Never distribute the cluster-admin kubeconfig as a convenience.
Read-only recognition drill: kubectl config current-context identifies the selected cluster/user context; kubectl get --raw=/version reports API version if permitted. A successful API request establishes neither that all component endpoints are secure nor that the caller should have administrator access.
Choose under exam pressure
| Requirement | Choice and reason |
|---|---|
| Credentials accepted, but the requested action is forbidden | Investigate authorization/RBAC; authentication already established an identity. |
| Protect a stolen etcd backup | Use protected encrypted backups and protect the keys; API endpoint TLS does not encrypt an exported file. |
| Workload scheduled onto an inappropriate node | Inspect scheduler inputs, placement configuration and who can change them. |
| Receive kubeconfig from an unknown source | Inspect and establish trust before use; executable credential plugins may run locally. |
Traps
- Exposing only an authenticated API does not make an independently exposed etcd endpoint safe.
- Controller permissions can be much broader than an ordinary application service account.
- TLS server validation must remain enabled; encryption to an impersonator is not sufficient.
Active recall
1. Which component chooses a node, and which later starts containers there?
The scheduler chooses a node; its kubelet manages execution through the container runtime.
2. Why are etcd snapshots sensitive even when no application volume data is included?
They can contain cluster API objects, configuration and Secrets. They need access controls, encryption and controlled recovery.
3. What can make a kubeconfig more dangerous than a list of server addresses?
It can include credentials or an exec credential plugin that runs a local command.
4. Does the controller manager store authoritative cluster state itself?
No. Controllers act through the API; etcd persists API state.
5. What does skipping TLS certificate validation sacrifice?
Confidence that the client is communicating with the intended server, enabling impersonation despite encrypted transport.