Kubernetes Penetration Testing: Methodology & Guide

Kubernetes (K8s) has rapidly become the de facto platform for container orchestration, enabling microservices, scalability, resilience and portability. From a security testing point of view, it introduces a new attack surface — clusters, nodes, pods, containers, APIs, role-based access — and one that standard cloud penetration testing has to be scoped specifically to cover.

Service meshes add another layer to test; see what a sidecar proxy is.

This guide also covers the software supply chain that feeds the cluster: container image testing (base images, container vulnerability scanning, SBOMs, signing and admission control) and container registry security (access, immutability, pull-through caches and image provenance). A cluster can be well configured and still run a vulnerable or tampered image, so a complete Kubernetes penetration test checks both.

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 /openapi/v2 (or the legacy /swaggerapi on very old clusters) 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.

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.

Container image testing: base images, CVEs, SBOMs and signing

Every pod runs an image, and the image decides much of what an attacker finds after landing in a container: the packages, the user, the shell and any leftover credentials. NIST SP 800-190, the Application Container Security Guide, groups image risks into five categories: image vulnerabilities, image configuration defects, embedded malware, embedded clear text secrets and the use of untrusted images. A Kubernetes penetration test should check each one, and then check whether the cluster can refuse an image that fails.

For runtime hardening against the CIS Docker Benchmark and NIST SP 800-190, see our container security guide.

The checks below are conceptual and read-only unless stated otherwise. Run them only against images, registries and clusters that are in your written scope.

Container image checkpoints from build to run

Base images: what every image inherits

Most application images are a thin layer on top of a base image, so a weak base is copied into every service built from it. Start by listing the images that are actually running, not the ones the team believes are running. With read access, kubectl get pods -A -o jsonpath="{..image}" returns every image reference in the cluster. Compare that list with the approved base images and application images, then review each base for the points below.

• Age and support: is the base image's distribution release still supported, and when was the image last rebuilt? An image built a year ago carries a year of unpatched packages even if its Dockerfile never changed.
• Size and tooling: does the runtime image ship a shell, a package manager, compilers or debugging tools it does not need? Minimal and distroless bases remove much of what an attacker would use after gaining code execution.
• User: does the image run as root by default? Check the User field in the image configuration and the pod's securityContext settings such as runAsNonRoot and runAsUser.
• References: are base images and deployed images referenced by mutable tags such as latest, or by digest? The Kubernetes documentation on images advises against :latest in production and notes that digests are immutable while tags can be moved.
• Leftovers: do image layers contain secrets, .git folders, private keys or build credentials? A file deleted in a later layer still exists in the earlier one, so review the image history and every layer, not only the final filesystem.

Container vulnerability scanning: reading CVE results honestly

Container vulnerability scanning compares the packages inside an image with vulnerability databases and vendor advisories. Scanners read operating system package metadata and language manifests, such as lock files and installed packages for Python, Node.js, Java and Go, and report the CVEs that match each version. Common open-source scanners include Trivy, Grype and Clair. Docker Scout and the scanners built into registries such as Amazon ECR, Azure Container Registry, Google Artifact Registry and Harbor do the same job inside the platform.

For a pentester, the scan report is evidence, not the finding. Scanners can miss software copied into the image without a package manager, statically compiled binaries and anything whose package metadata was removed. They can also over-report: Linux distributions often backport fixes without changing the upstream version number, and many listed CVEs sit in code the application never loads. Prioritize CVEs that are fixable, present in images that are actually running, and reachable from the network or from untrusted input. Exploitation signals such as the CISA Known Exploited Vulnerabilities catalog help rank them, the same way a risk-based vulnerability management program would.

Scanning at a single point in the pipeline is not enough, because new CVEs are published against images that have not changed. Check where scanning happens and what each point can and cannot catch:

A useful and safe check in a Kubernetes pentest is to compare the digests running in the cluster with the digests the scanner has results for. Images that run but were never scanned, or were scanned only under a tag that has since moved, are a frequent gap between the security dashboard and reality.

SBOMs: turn each image into an inventory

A software bill of materials (SBOM) lists the components inside a piece of software. CISA describes an SBOM as a nested inventory of the ingredients that make up software components. For containers, an SBOM is generated per image, usually in the SPDX or CycloneDX format, with tools such as Syft, Trivy or Docker BuildKit's SBOM attestations. The Kubernetes project itself publishes a signed SPDX SBOM for its releases.

The value shows when a new vulnerability is disclosed: teams with SBOMs can search an inventory for the affected component instead of pulling and rescanning every image. In a test, check that an SBOM exists for each deployed digest (not only for the source repository), that it is stored with the image or in a system that can be queried, and that it matches what is in the image. An SBOM generated from source code can miss everything the base image adds. For the wider risk, see our guide to software supply chain attacks.

Image signing and provenance attestations

Signing binds an image digest to an identity, so a cluster can tell an image your pipeline built from one that merely uses the same name. The most common open-source options are Sigstore Cosign, which supports keyless signing with short-lived certificates tied to an OIDC identity, and the Notary Project's Notation. The Kubernetes release process signs its own release artifacts and control plane images with Cosign, and the Kubernetes documentation shows how to verify them.

Provenance goes one step further. A SLSA provenance attestation records the build platform that produced an artifact, the build definition it ran and the dependencies it resolved, so you can confirm that an image came from your CI system and your repository rather than from a developer laptop.

What to test

• Are signatures and attestations verified anywhere, or only produced? A pipeline that signs every image gives no protection at deploy time if the cluster never checks the signature.
• Is verification tied to a specific signer identity and issuer, such as one CI workflow, or does any valid signature pass? Keyless verification that accepts any identity proves only that someone signed the image.
• Who can reach the signing keys or the CI identity that signs? If any pull request can drive the build system that signs, the signature proves little.
• Do signatures and attestations follow the image when it is copied, mirrored or cached into another registry?

Admission control: can the cluster refuse a bad image?

An admission controller intercepts requests to the Kubernetes API server after authentication and authorization, but before the object is stored. That is where image rules are enforced: allowed registries, digest-only references, required signatures or attestations, and scan results. Built-in options include ValidatingAdmissionPolicy, which uses CEL expressions and has been stable since Kubernetes v1.30, the ImagePolicyWebhook plugin and AlwaysPullImages. Signature and attestation checks usually come from policy engines such as Kyverno, OPA Gatekeeper with Ratify, or the Sigstore policy-controller.

AlwaysPullImages deserves a specific check in multi-tenant clusters. It forces every new pod to pull its image, so the registry checks credentials each time. Without it, once an image has been pulled to a node, any pod scheduled there can use that private image by name, without the credentials that pulled it.

You can test admission rules without running anything. A server-side dry run (kubectl apply --dry-run=server -f pod.yaml) sends the request through admission but never stores the object. Only webhooks that declare sideEffects: None or NoneOnDryRun are called for dry-run requests; if another webhook matches, the dry run is rejected, which is itself worth recording. With permission, in an agreed test namespace, submit dry-run pod specs like these and record what is accepted:

Also review the policy configuration itself. A webhook with failurePolicy: Ignore lets requests through when the policy engine is down or times out, and audit or warn modes report violations without blocking them. Both are common where enforcement was rolled out cautiously and never switched on.

Container registry security testing

The registry is the trust anchor for everything the cluster runs. If an attacker can push to it, overwrite a tag or poison a cached upstream image, every node that pulls that image runs their code, and most cluster controls will accept it. NIST SP 800-190 lists three registry risks: insecure connections to registries, stale images in registries, and insufficient authentication and authorization restrictions. A registry review for a modern pipeline adds two more areas: pull-through caches and image provenance.

Access: who can pull, push and delete

Start with how the registry answers an unauthenticated client. The OCI Distribution Specification defines a base endpoint, GET /v2/. A registry that requires authentication normally answers with 401, so a 200 response to an anonymous client on a private registry is worth investigating further, read-only. Then review identities and permissions:

• Anonymous and public access: can repositories be listed or pulled without credentials? Self-hosted registries are sometimes deployed without authentication on an internal network and later become reachable from outside it.
• Push and delete rights: which human users, CI identities and cluster service accounts can push, overwrite or delete images? Push to production repositories should be limited to the build system; developers rarely need it.
• Pull credentials in the cluster: imagePullSecrets are ordinary Kubernetes Secrets. Anyone who can read Secrets in a namespace can read the registry credentials, and those credentials often allow more than pulling. Check their scope, and whether node or workload identities could replace static credentials.
• Transport: are nodes or build agents configured to trust insecure registries over plain HTTP or with TLS verification turned off?
• Logging: are pushes, deletions, tag changes and permission changes logged and reviewed?

Testing push access against production repositories can change what runs in production. If write tests are in scope, use a dedicated test repository named in the rules of engagement, and prove access through permission reviews rather than real pushes wherever possible.

Immutability: tags, digests and stale images

A tag is a pointer that can be moved; a digest is a hash of the image content and cannot be. Most registries, including Amazon ECR, Azure Container Registry, Google Artifact Registry and Harbor, can stop release tags from being overwritten through tag immutability or image locking settings. Check whether that protection is on for release repositories, whether CI identities can overwrite existing tags, and whether deployments reference digests.

Then look at the other end of the life cycle. NIST SP 800-190 flags stale images as a registry risk because old, vulnerable images stay available to deploy. A retention or lifecycle policy, plus regular rescanning of what remains, closes that gap.

Pull-through caches and mirrors

Many teams route public images through a pull-through cache or mirror, for example Amazon ECR pull-through cache rules, Harbor proxy cache projects or Artifact Registry remote repositories. A cache improves availability, avoids upstream rate limits and gives you one place to scan and control third-party images. It also brings its own risks:

• Automatic refresh: caches update tags from upstream. Amazon ECR, for example, checks the upstream registry for a newer version of a cached tag at least once every 24 hours. A compromised or changed upstream tag flows into your cache unless deployments pin digests.
• Who can populate the cache: if anyone who can pull can also trigger caching of any upstream image, the cache becomes a way to bring arbitrary public images inside your trust boundary.
• Name confusion: look for typosquatted or look-alike repository names, and check whether internal image names could also resolve to a public upstream.
• Upstream credentials: caches that authenticate to upstream registries store credentials. Check where they are stored and who can read them.
• Coverage: are cached images scanned and subject to the same admission policy as the images you build?

Image provenance: proving where an image came from

Provenance connects the source repository, the build, the registry and the cluster. Since version 1.1, the OCI Distribution Specification includes a referrers API that lists the artifacts attached to an image digest, such as signatures, SBOMs and attestations. In a review, confirm that the registry supports referrers (or the fallback tag scheme), that attached artifacts survive replication and caching, and that admission policy actually reads them. A provenance chain that breaks at the mirror leaves the cluster nothing to verify.

Use this summary to plan a registry review:

Registry and image findings usually chain with cluster findings: a token read from a pod that can push to the registry is a path to code execution on every node that pulls the image. DeepStrike's cloud penetration testing services include container and Kubernetes security assessment, covering containerized applications, Docker configurations, Kubernetes clusters and service mesh security, along with infrastructure-as-code and CI/CD pipeline testing. To build these checks into delivery, see penetration testing for DevOps; for the cloud configuration around the registry, see our guide to CSPM tools.

Attack scenarios and escalation chains

Below are typical chains a pentester should attempt to demonstrate impact.

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. If you can execute code in that pod (for example through an application vulnerability or an unauthenticated kubelet API on 10250), read the mounted token and test its permissions against the API server to escalate privileges.

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

Scenario D Registry write access → workload compromise

1. A mounted service account token or a leaked CI credential grants push access to the image registry.
2. The registry allows a release tag to be overwritten, and workloads reference that tag rather than a digest.
3. Admission control does not verify signatures, so any node that pulls the tag again, such as a new node or a pod with imagePullPolicy: Always, runs the replaced image.

Impact: code execution in every workload that pulls the image. Demonstrate it through permission reviews and, only if agreed, a harmless marker image in a dedicated test repository. Never replace a production image.

Hands-on examples & commands

Below are conceptual examples of commands for these checks. Run them only 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/version — check whether version information is exposed without authentication.
• 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

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.

Pair these cluster fixes with the container runtime baseline in our container security checklist.

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, and RBAC reviews — most teams run these alongside an annual engagement from one of the specialist cloud pentest providers.

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 evolves quickly. Check findings and defaults against the Kubernetes version and managed-service configuration in scope, and review current CVEs before testing.

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?
9. Running images scanned by digest, free of fixable critical CVEs, and not running as root?
10. SBOM and signature available for each deployed digest?
11. Admission rejects unapproved registries, tag-only references and unsigned images (server-side dry run)?
12. Registry rejects anonymous access, limits push rights and blocks tag overwrites?
13. Pull-through cache restricted, scanned and consumed by digest?

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 (no longer actively developed; Aqua Security recommends Trivy's Kubernetes scanning).
• Configuration / CIS benchmark checks: kube-bench.
• Manifest / IaC / policy scanners: Kubescape, kubesec, kubeaudit.
• Image & vulnerability scanning: Trivy (and Clair, Grype, etc.).
• Image supply chain, SBOM and admission: Syft (SBOM generation), Cosign and Notation (signing and verification), Kyverno, OPA Gatekeeper and the Sigstore policy-controller (admission policy), plus your registry's own scanning and tag immutability settings.
• 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 read-only etcdctl commands such as get --keys-only 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 (kube-hunter is no longer actively developed; Trivy can also scan live clusters). 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.

• What is container vulnerability scanning?
  Container vulnerability scanning checks the packages inside a container image against vulnerability databases and reports known CVEs. Run it in CI, when images are pushed to the registry, on a schedule for stored images, and against what is running in the cluster, then prioritize fixable CVEs in running, reachable images. Open-source scanners such as Trivy, Grype and Clair, and the scanners built into managed registries, all work this way.

• How do you secure a container registry?
  Require authentication for every pull and push, limit push and delete rights to the build system, make release tags immutable and deploy by digest, remove stale images with lifecycle rules, scan stored and cached images, and keep signatures, SBOMs and provenance attached to each image so admission control can verify them. NIST SP 800-190 is a solid baseline for image and registry risks.

• Should a Kubernetes penetration test include container images and the registry?
  Yes, when they are in scope. Cluster hardening does not help if the cluster runs a vulnerable or replaced image. A complete test reviews the running images, the scanning and signing pipeline, admission policy and registry permissions, using read-only checks and server-side dry runs unless intrusive testing has been agreed.