liveBook · Manning

Kubectl

As explained in Cyber Threat Hunting

kubectl is the Kubernetes command-line tool for communicating with and managing Kubernetes clusters through the Kubernetes API.

kubectl is the Kubernetes command-line tool for communicating with a cluster control plane through the Kubernetes API. Authorized administrators use it remotely to inspect and manage Kubernetes objects; its requests also leave useful API audit evidence. section 5.1.2 section 5.1.3

Use kubectl to establish a cluster baseline during an investigation:

  • Identify the control-plane endpoint with `kubectl cluster-info`. section 5.1.2
  • List nodes with wide output to record their internal and external IP addresses. section 5.1.2
  • List namespace-scoped services to identify exposed applications, load balancers, and ports. section 5.1.2
  • List pods across namespaces to find recently created, failed, or evicted workloads. section 5.1.3

Treat the kubectl user agent in Kubernetes API server events as investigation context, not proof of benign activity. A recorded `kubectl get pods` call identifies the caller IP, authenticated principal, authorization decision, requested resource, and client version. Comparing those fields with known administrator, node, cluster-management, and cloud-provider addresses helps isolate unexpected API access. section 5.1.3 section 5.1.2

Investigating kubectl inside a container

A default service account produced allowed `get`, `pods.list`, and `services.list` calls, plus forbidden namespace-creation attempts, all carrying a `kubectl/v1.23.4` user agent. Check its effective permissions with `kubectl auth can-i --list --as=system:serviceaccount:chapter5:default -n chapter5`; then inspect suspect containers for a kubectl binary. A Falco alert tied a container-side `kubectl create deployment` command to an unexpected connection to the API server. section 5.1.3 section 5.1.3 section 5.1.3

Listing 5.15 Searching for containers with the kubectl client
kubectl exec -it $pod-name$ -n chapter5 \
  -- find / -name "kubectl" -ls                            #1
 
1049445 45500 -rwxr-xr-x   1 root     root
  46592000 Mar  5 08:41 /tmp/kubectl                       #2

Inspecting a container filesystem for kubectl can corroborate API audit findings and runtime alerts. section 5.1.3

How Cyber Threat Hunting covers it

How deep it goes
Demonstrates operational inspection, permission checks, container searches, and audit-log investigation rather than kubectl installation or command syntax comprehensively.
Examples
Uses cluster-info, node and service listings, service-account permission checks, container binary searches, and a malicious deployment command.
What it assumes
Assumes familiarity with Kubernetes clusters, pods, namespaces, and API access while illustrating practical kubectl investigation commands.
What you can do after
Diagnose/debug with it by baselining cluster resources, checking service-account permissions, and correlating kubectl activity with API and runtime alerts.
How it connects
Connects Kubernetes API, audit logs, namespaces, service accounts, RBAC, DaemonSets, Falco, and Kubernetes services.

Also explained in

Compare how 11 books explain kubectl →

Related concepts

This explainer was generated by Manning's knowledge graph from the text of Cyber Threat Hunting. The section links point to the parts of the book it draws on.