Introduction to the Kubernetes API

A new engineer runs kubectl get pods and it works. They have no idea what just happened. The request hit an API server, passed through authentication, authorization, and admission control before anything happened. Understanding this flow is the foundation of K8s security.

Every security control in Kubernetes happens at the API. There is no other entry point. kubectl is a thin wrapper around HTTPS calls to the API server; controllers are clients of the same API; kubelets watch the API for what to run. The cluster has no concept of "the API server is offline but everything else works." If the API is down, the cluster is paused.

That centrality is the whole game for security. Every defensive control (authentication, authorization, admission, audit, network policy enforcement at the API) attaches at the API. If you understand the request lifecycle through the API, you understand where every defense lives.

This lesson is the request lifecycle, end to end, the way a senior engineer would describe it on a whiteboard.

Attack path / threat explanation

The threat model in two sentences: anyone who can reach the API server and authenticate as any identity can do anything that identity is authorized to do. The art of K8s security is making "reach the API server" hard, "authenticate" auditable, and "authorized to do" minimal.

A few attack patterns that exploit weak control at this layer:

• Reaching the API at all. Public-internet-exposed API servers are still common (search Shodan for port 6443). An exposed API server with anonymous auth enabled is game over before authentication even matters.
• Compromising any client. kubectl on a developer laptop with cluster-admin context. A CI/CD job with overly broad credentials. A pod with an over-privileged ServiceAccount. Compromising any of these gives the attacker the same access as the legitimate client.
• Bypassing later gates. If authentication succeeds for an attacker (stolen token, compromised credential), the only remaining defenses are authorization and admission. Both are configurable; both can be permissive by default.

Understanding what each gate does and what happens when each is misconfigured is the foundation for the rest of the course.

How it works under the hood

The end-to-end flow when you type kubectl get pods:

A few important properties of this flow:

The three gates are in series. A request that fails authentication never reaches authorization. A request that fails authorization never reaches admission. This means each gate's failure mode matters: an authentication bypass exposes everything; an authorization too-permissive exposes whatever the identity could have done.

The API server is stateless. All state lives in etcd. The API server can be killed and restarted without losing data. You can run multiple API servers behind a load balancer for HA. Watch caches in each instance get rebuilt on startup. This statelessness is what makes the API server scalable and what makes etcd the single highest-value target.

Every kubectl command is one or more API calls. Even kubectl get pods is two: first a discovery call to find the pod resource definition, then the actual list. kubectl apply is more: read the current state, compute the diff, send a patch. You can see the full request stream with kubectl -v=8 or higher.

The mental model that pays off: when you ask "is this secure?" what you are really asking is "what can an attacker who reached this API endpoint do, given each gate's current configuration?" If the answer is "anything" at any gate, that is your attack surface.

Defense architecture

Every defense in Kubernetes attaches to one of the three gates plus the audit/observability layer. A useful summary:

Each subsequent lesson in this module and Module 2 covers one of these in detail. The lesson here is the flow itself: every security configuration you make is configuring one of these gates.

Configuration examples

A starter kubectl debugging command to see the API call flow yourself:

# See the actual HTTP requests kubectl is making
kubectl -v=8 get pods 2>&1 | head -50

# Output includes:
# - GET https://api-server:6443/api?timeout=32s (discovery)
# - GET https://api-server:6443/api/v1/namespaces/default/pods?limit=500 (list)
# - The full request and response headers

For a security-focused inspection, look at the kubectl config to understand who you are authenticating as:

# Current context (which cluster, which user, which namespace)
kubectl config current-context

# All credentials in your kubeconfig
kubectl config view --minify

# Your effective user identity from the API server's perspective
kubectl auth whoami

The kubectl auth whoami output is what the API server believes about your identity. It is the input to every authorization decision; if this is wrong, every later access decision is wrong.

Common misconfigurations

• Anonymous authentication enabled. Many older clusters had this on by default. An attacker who reaches the API server can list any resource that the system:anonymous user or system:unauthenticated group can access, often more than you think.
• kubeconfig with cluster-admin shared via Slack. Once shared, you cannot revoke (the credential is on someone's machine forever). Always use OIDC for human users; never ship long-lived cluster-admin tokens.
• The API server on the public internet. Attackers find these in minutes via Shodan. Use a private endpoint (or VPN/bastion) for any non-toy cluster.
• Permissive authorization in development clusters. "It's only dev" is the path to production credentials being stolen from dev.
• Audit logging not configured. Without audit logs, you cannot investigate a breach after the fact. The default in many distros is no audit; you must opt in.
• Treating kubectl access as the only attack surface. Controllers, operators, kubelets, and external systems all hit the API. Every credential everywhere is part of the attack surface.