Kubernetes (K8s) has rapidly become the de facto platform for container orchestration, enabling microservices, scalability, resilience and portability. From a security testing (penetration testing) point of view, it introduces a new attack surface: clusters, nodes, pods, containers, APIs, role-based access, etc.

Why test Kubernetes?

Kubernetes shifts much of the application infrastructure into a highly dynamic environment: ephemeral containers, pods that scale up/down, complex networking, inter-pod communication, control‐plane APIs, etc. If misconfigured or poorly secured, an attacker can discover cluster metadata, expose etcd (the cluster’s key‐value store), exploit open APIs, or elevate privileges via mis-set role-based access control (RBAC).

Key Kubernetes Concepts for Pentesters

Before diving into tests, it helps to get familiar with the basic terminology

• Pod: The smallest deployable object in K8s, a group of one or more containers that share storage/network.
• Node: A machine (virtual or physical) on which pods run; contains kubelet, kube-proxy, etc.
• Kubelet: Agent running on each node; connects to API server to ensure pods are running.
• Kube-proxy: Proxy service on each node handling network communication for pods/services.
• Cluster: Set of nodes (typically including a control‐plane (master) node and worker nodes) running the orchestrated workloads.
• Container: Standard unit of software that packages an application and its dependencies; in K8s they are often microservices.
• etcd: Distributed key-value store used by Kubernetes for configuration, state and metadata.
• kubectl: CLI tool for interacting with the Kubernetes API server.
• Kubernetes API Server: The front-end of the control plane; other components (e.g., kube-scheduler, kubelet) talk to it.
• Namespace: A virtual cluster inside a K8s cluster; namespaces help to partition resources and scope names.

Getting these terms solid helps you follow the later attack surfaces.

Reconnaissance & Information Gathering

Passive discovery

Start with externally available information; this phase avoids touching the target network:

Public scans & search engines: use Shodan/Censys and CT logs to find domains, hostnames and certificates that indicate Kubernetes components

Below is a list of keywords to search with these tools:

• kubernetes dashboard
• kubernetes
• k8s
• kubernetes master or kubernetes control plane
• openshift
• swarm
• product:etcd
• k8s.io
• apiserver
• k8s_node/k8s-cluster-etcd/kubeadm-master/kubemaster-etcd
• services.kubernetes.kubernetes_dashboard_found

Searching in Censys

Cluster management can be performed using tools like the Kubernetes dashboard, Weave Scope, and Lens. These applications add capabilities and offer graphical interfaces for the Kubernetes environment. Search engines like Shodan and Censys are useful for discovering improperly secured dashboards. Authentication is typically needed for these dashboard interfaces.

Here is an example to search in CT logs like crt.sh

Search in CT Logs using crt.sh

Public repos & config leaks: search GitHub/GitLab for yaml/yml manifests, Helm charts, or CI/CD configs containing cluster endpoints, tokens, or credentials.

Searching in GitHub for leaks

What you’ll likely find: Secrets and leaked credentials, and publicly visible config files.

Active discovery

If passive discovery yields IPs/domains, move to live probes:

Here are the common exposed ports for Kubernetes clusters:

• Port enumeration: check for common K8s components and their ports: API server (commonly 6443 or 443), etcd (2379/2380), kubelet ports (10250 secured, 10255 often read-only), dashboard ports, and any plugin UIs.
• HTTP probing of endpoints: query https://<host>:<port>/api/v1, https://<host>:<port>/healthz, or /swaggerapi to see if the API responds and whether authentication is enforced.
• Kubelet probes: many clusters historically exposed the kubelet read-only port (10255). Querying http://<ip>:10255/pods may list running pods and helpful metadata.
• etcd checks: test whether etcd is reachable externally (e.g., port 2379). If reachable and unauthenticated, etcd may reveal secrets and certificates.

Practical example (conceptual, follow legal rules before running any command):

• curl -k https://<api-server>:6443/api/v1 Does it return anything without auth?
• curl http://<node-ip>:10255/pods Does the read-only kubelet port list pods?
• etcdctl --endpoints=http://<etcd-host>:2379 get "" --prefix --keys-only Does it return keys?

Attack Surface Checklist

Below is a prioritized checklist with what to test, the risk each item represents, and common indicators of compromise or misconfiguration.

1. Kubernetes API Server

What to test

• Is the API server reachable externally? (ports 6443, 443)
• Does it allow anonymous or unauthenticated reads?
• Are sensitive endpoints (/api/v1/secrets, /apis/rbac.authorization.k8s.io/) accessible?

Why it matters

The API server is the cluster’s control plane unauthenticated access can allow reading resource definitions, secrets, or even creating resources.

Indicators

• curl https://<api>:6443/api/v1 returns JSON without auth.
• Swagger or discovery endpoints accessible.

Remediation pointers

• Restrict API server access by network controls and require strong auth (client certs/OIDC). Disable anonymous auth.

2. etcd

What to test

• Is etcd open/accessible on 2379/2380 from outside?
• Can you read keys without TLS/auth?

Why it matters

etcd stores cluster state and often secrets. Unprotected etcd = full cluster compromise.

Indicators

• Plain HTTP(S) or gRPC access to etcd endpoints. Tools or etcdctl return keys or values.

Remediation

• Require TLS and client certs for etcd, firewall off etcd ports to control plane only.

3. Kubelet endpoints

What to test

• Is kubelet read-only port (10255) exposed?
• Is the kubelet secured (10250 with TLS) and does it require auth?

Why?

Read-only kubelet can leak pod metadata, file locations, container images. If write operations or CVEs exist, kubelet could be abused to execute or escalate.

Indicators

• Access to /pods, /containers, or file reading endpoints via kubelet.

Remediation

• Block kubelet ports at perimeter, require TLS and authentication for kubelet API.

(Both sources discuss kubelet as a valuable reconnaissance target.)

4. Dashboard & Add-ons (cAdvisor, metrics UIs)

What to test

• Are dashboards or metrics UIs exposed publicly?
• Do they require auth and are they running with privileged permissions?

Why?

Dashboards often run with elevated permissions and can be used to view secrets or create workloads.

Indicators

• HTTP endpoints for kubernetes-dashboard, cAdvisor, or network plugin UIs reachable.

Remediation

• Restrict dashboards to internal networks, use RBAC, and avoid running as cluster-admin.

5. RBAC / Service Account Misconfigurations (internal escalation)

What to test

• Are service accounts given overly broad permissions?
• Can a pod access the API using a mounted service account token to escalate?

Why?

Service accounts often act as the identity of a pod. Overprivileged tokens are an easy path from pod to cluster admin.

Indicators

• Mounted tokens in pods, automountServiceAccountToken: true where not needed, broad ClusterRoleBindings.

Remediation

• Apply least privilege, minimize token auto-mounting, audit RBAC bindings.

6. Secrets and Configuration Leakage

What to test

• Are secrets stored in plain text in configs or public repos?
• Are secrets accessible through misconfigured API endpoints or etcd?

Why?

Secrets in repo or etcd lead to credential theft and lateral movement.

Indicators

• Base64 encoded tokens in YAMLs found in public repos; /api/v1/secrets listing.

Remediation

• Use secret managers, encrypt etcd at rest, and audit public repos for config leakage.

Attack scenarios and escalation chains

Below are typical chains a pentester should attempt to demonstrate impact (based on the methodologies in the two resources).

Scenario A External API server + anonymous read

1. Discover https://api.example.com:6443 responding to unauthenticated queries.
2. Enumerate namespaces and secrets.
3. Read a secret containing credentials for external services (DB, cloud provider).
4. Use credentials to access other infrastructure or exfiltrate data.

Impact: full cluster visibility and external resource compromise.

Scenario B Exposed etcd

1. Find etcd reachable at http://master.example.com:2379.
2. Extract keys (including kube-system secret blobs, TLS certs).
3. Reconstruct credentials to impersonate the cluster or decrypt data.

Impact: cluster takeover via direct control-plane data compromise.

Scenario C Kubelet information leakage → pivot

1. Kubelet read-only port lists all pods and container images.
2. Find a pod running with a mounted service account token and permissive RBAC.
3. Retrieve token and use it against API server to escalate privileges.

Impact: lateral movement within cluster and possible cluster admin compromise.

Hands-on examples & commands

Below are conceptual examples of the kinds of commands shown or suggested in the referenced guides only run them against systems you are authorized to test.

• Probe API discovery:
  • curl -k https://<api-server>:6443/api/v1 check for unauthenticated JSON.
• Kubelet read-only probe:
  • curl http://<node-ip>:10255/pods list pods (if exposed).
• etcd check (conceptual):
  • etcdctl --endpoints=http://<etcd-ip>:2379 get / --prefix --keys-only see keys if unauthenticated.
• Check healthz:
  • curl -k https://<api-server>:6443/healthz API health and possible leak of version info.
• Repo/config search:
  • Search public GitHub for kubernetes, kubeconfig, apiVersion, imagePullSecrets to find accidental leaks.

Interpreting findings

When you find a positive result on a check, assess:

• Confidentiality impact Did you obtain secrets or credentials? Are secrets in etcd?
• Integrity/Control impact Can you create/update resources via API? Can you create pods to run arbitrary images?
• Availability impact Could you delete resources, or destabilize the control plane?

A small leak (e.g., read-only kubelet) may be low immediate severity but often enables lateral steps that escalate impact.

Remediation checklist

Following the two resources, apply these prioritized hardening steps:

1. Lock down API server
   • Restrict access via firewall/network ACLs.
   • Require authentication (TLS client certs or OIDC) and disable anonymous access.
2. Secure etcd
   • Require TLS for client/server communication.
   • Restrict network access to control plane only; enable access control.
3. Harden kubelet
   • Disable read-only endpoints publicly; require auth for kubelet API.
   • Block 10255/10250 on external interfaces.
4. Limit dashboard & add-on exposure
   • Don’t expose admin dashboards to the internet; bind them to localhost or use bastion/proxy.
   • Run dashboard with the least privilege necessary.
5. RBAC & tokens
   • Audit RBAC ClusterRoleBindings; remove overly broad bindings.
   • Disable automounting of service account tokens where not needed.
   • Rotate service account tokens and secrets regularly.
6. Secrets management
   • Don’t store secrets in plaintext in repo or in etcd without encryption at rest.
   • Use a secrets manager and ensure etcd encryption.
7. Logging & monitoring
   • Log API access and watch for anomalous calls (e.g., unexpected list/delete operations).
   • Scan for exposed endpoints (regular Shodan/Censys checks) and alert on new public endpoints.

Reporting how to present findings to stakeholders

When you deliver a pentest report, include:

• Executive summary: High-level impact (e.g., “unauthenticated API access revealed secrets in etcd high severity”).
• Technical findings: Evidence (curl output snippets, endpoints discovered), reproduction steps, and risk mapping.
• Exploit chains: Show the sequence from initial discovery to full impact (if you reached that stage).
• Remediation steps: Prioritized, practical fixes (apply the remediation checklist above).
• Recommendations for continuous validation: periodic scanning for exposed endpoints, repository scans for leaked config, RBAC reviews.

Limitations & safe testing notes

• Always have explicit, documented authorization before testing.
• Many of the commands above can be destructive if misused prefer read-only checks until you have permission for intrusive testing.
• Kubernetes is evolving this guide is restricted to the attack surfaces and tests covered by the two referenced articles and may not include more recent features or CVEs beyond those posts.

Appendix: Practical checklist

Use this checklist during a test. Mark results and follow with evidence.

1. Passive discovery: public cert logs, Shodan/Censys, GitHub searches.
2. API server reachable? /<api>/api/v1 responds without auth?
3. etcd reachable (2379/2380) and returns keys?
4. Kubelet read-only (10255) lists pods?
5. Dashboard or metrics UI publicly reachable?
6. Any secrets found in public repos?
7. Service accounts with broad RBAC bindings?
8. Can a mounted token be used to access API?

Common Tools you will need

• Passive recon/internet discovery: Shodan, Censys, cert-transparency search (crt.sh), GitHub search, gitleaks (repo secrets).
• Network & HTTP scanning: nmap, masscan, curl, httpie, jq.
• K8s surface discovery / automated pentest: kube-hunter.
• Configuration / CIS benchmark checks: kube-bench.
• Manifest / IaC / policy scanners: Kubescape, kubesec, kubeaudit.
• Image & vulnerability scanning: Trivy (and Clair, Grype, etc.).
• Low-level K8s interaction / exploitation helpers: kubectl, etcdctl, kubectl-debug / kubectl-cp, simple curl against kubelet/API, custom scripts.
• Runtime / behavioral / EDR: Falco, runtime monitoring (for defenders / post-compromise detection).

Frequently Asked Questions FAQ —

• What is the first thing I should check when testing a Kubernetes cluster?
  Start with discovery: can you reach the API server, kubelet, or etcd from outside? Run non-intrusive probes like curl -k https://<api>:6443/api/v1 and curl http://<node-ip>:10255/pods. If any respond without authentication, treat that as high priority to investigate and isolate

• .How do I safely test for exposed etcd without breaking anything?
  Prefer read-only checks and avoid destructive commands. Try a simple connectivity test to the etcd port (2379/2380). Use etcdctl with read-only flags if authorized. If you find unauthenticated access, capture minimal metadata and report it immediately. Never write to etcd unless you have explicit permission.

• How can a read-only kubelet leak be used in an attack chain?
  A read-only kubelet can reveal running pods, container images, and file paths. That info helps identify pods with mounted service account tokens or sensitive images, which can then be targeted for token extraction or vulnerability exploitation. Fix by blocking 10255 and enforcing kubelet auth on 10250.

• What signs indicate RBAC or service account misconfiguration?
  Indicators include broad ClusterRoleBindings, automountServiceAccountToken: true on many pods, and service accounts with cluster-admin privileges. Test by checking in-pod token mounts and attempting only read operations against the API with those tokens to confirm scope. Recommend least privilege and token minimization.

• If I find secrets in git or manifests, what is the responsible disclosure path?
  Document exact locations, types of secrets, and minimal reproduction steps. Avoid exfiltrating secrets. Contact the owner via secure channel, include evidence and remediation steps (rotate secrets, enable secret management, encrypt etcd). If public provider hosts the leak, follow their disclosure policy for takedown.

• Which tools should I run for a fast, focused K8s assessment?
  For reconnaissance and checks use kubectl (when you have creds), curl for endpoints, nmap for ports. For automated posture checks use kube-hunter and kube-bench. For manifest and IaC scanning use Trivy, Kubescape, or kubesec. Use each tool in read-only mode unless you have permission for intrusive tests.

• How do I prioritize findings for stakeholders who are not technical?
  Map each finding to business impact: Confidentiality (data or credential leak), Integrity (ability to create/modify workloads), Availability (delete or disrupt resources). Label severity (High, Medium, Low) and give concise remediation: network restriction, enable auth, RBAC changes, rotate secrets, enable etcd encryption. Provide an executive summary with risk and required actions in plain language.