Private corporate batches, live online cohorts and 1-on-1 mentoring in authorised discovery of exposed Kubernetes attack surface, and closing it — taught by a practitioner who runs it in production.
20 years across DevOps, SRE and Security · 10,000+ engineers trained · Trained teams at JPMorgan Chase, Verizon, Nokia and the World Bank
Principal DevOps Engineer & Architect
Rajesh teaches kube-hunter defensively and in order: scope and written authorisation first, then the threat model, then scanning your own cluster from each vantage point that matters — outside, inside the pod network, and from a compromised workload. Every finding class in the syllabus is followed straight away by the remediation and the re-verification, from kubelet authentication and API server anonymous access through service account token hygiene and metadata endpoint blocking. Sessions run only against clusters the attendees own, and pair kube-hunter with kube-bench so exposure and configuration are covered together.
Twenty years across DevOps, SRE and Security, in principal and architect roles at PayPay, SoftwareAG, ServiceNow, JDA Software, Intuit, Adobe and others. He has trained engineers at JPMorgan Chase, Verizon, Nokia, the World Bank, VMware, Oracle, Mercedes-Benz and Airbus — more than 10,000 people personally. He teaches what he runs, not what he reads.
You are booked with a named engineer, and that is who turns up. Marketplaces and larger providers rotate whoever is free, so the person who sold you the agenda is rarely the person teaching it.
The same trainer is available for the next engagement, which matters when a team builds on what it learned last time.
Your batch is assigned a named trainer before it starts, and that is who teaches it. See the full faculty.
Engagements are matched on the tool, not the calendar. For kube-hunter that means a trainer who has run it in production — authorised discovery of exposed Kubernetes attack surface, and closing it — rather than whoever is free that week. You are told who is teaching before you commit, and that person is on the discovery call that shapes the agenda.
Where a batch is large enough to need a second trainer, the pairing is declared up front. The lead trainer stays accountable for the syllabus and the assessment either way.
Principal DevOps Engineer & Architect
Twenty years across DevOps, SRE and Security in principal and architect roles at PayPay, SoftwareAG, ServiceNow, JDA Software, Intuit, Adobe, IBM/Emptoris, Ness, MindTree and Accenture. He has trained more than 10,000 engineers personally, at organisations including JPMorgan Chase, Verizon, Nokia, the World Bank, VMware, Oracle, Mercedes-Benz and Airbus. He teaches what he runs, not what he reads.
Teams of 8–30
Custom agenda, your timezone, onsite or online, NDA-friendly.
Request a quoteIndividual engineers
A private instructor and a curriculum built around your goal.
₹99,999Individuals who want peers
Scheduled batch, max 8 to 10 hours of live instruction.
₹34,999A private batch starts with a discovery call. We look at the stack you actually run — the CI system, the cloud, the constraints — and map the agenda onto it, so examples use your topology rather than a generic one.
Delivery is onsite at your premises, live online, or hybrid, scheduled around your release calendar rather than ours. Batches run 8 to 30 engineers.
Every attendee leaves with recordings, slides, lab repositories and a completion certificate. You receive an attendance and assessment report. Invoicing supports PO and GST.
Talk to us about a private kube-hunter batchkube-hunter is an open-source tool that looks at a Kubernetes cluster the way an unauthenticated attacker would, and reports what it can reach. Where kube-bench inspects configuration from inside a node, kube-hunter probes from a network position and asks a different question: given this vantage point, what is exposed? It is a self-assessment tool for clusters you own and are authorised to test.
It runs in several modes, and the mode is the point. Remote mode scans a named host. Interface mode scans everything reachable from the machine's network interfaces. CIDR mode sweeps a range. Pod mode runs kube-hunter as a pod inside the cluster, which answers the most useful question of all — what does an attacker who has compromised one workload get to see? Findings are grouped into discovery results, which describe what services are reachable, and vulnerability results, which carry an identifier, a category mapped to MITRE ATT&CK for Containers, and remediation guidance.
The class of findings it surfaces is consistent and depressingly common: an API server answering anonymous requests, a kubelet with its read-only port on 10255 open or its authenticated port on 10250 accepting unauthenticated /run and /exec calls, etcd listening without client certificate authentication, an exposed dashboard, cloud instance metadata reachable from inside a pod, and over-privileged service account tokens mounted by default. Every one of those is fixable, and closing them is the actual subject of this training.
Cluster compromise rarely begins with a kernel exploit. It begins with something being reachable that should not have been — a management port bound to all interfaces, a dashboard exposed through an ingress, a node's kubelet answering questions from the pod network, or a service account token that lets one compromised container list secrets across the cluster.
Those exposures are invisible to the tools most teams already run. Image scanners look at packages. Configuration auditors read flags on the node they run on. Neither of them tells you what is actually reachable from the pod network, from another namespace, or from the office VPN — and that reachability is what determines blast radius.
Authorised self-assessment closes that gap, and it is increasingly expected. Security reviews, customer questionnaires and internal red-team programmes all ask whether the cluster's exposed surface has been tested from an attacker's vantage point rather than assumed from the manifest. The skill worth training is not running a scanner; it is scoping the exercise properly, triaging findings honestly, understanding why each exposure matters, and remediating and re-verifying so the finding stays closed.
Before any tool runs. Written authorisation and why it is non-negotiable even on your own infrastructure, defining scope and blast radius, notifying the right people, and then a structured view of the Kubernetes attack surface using MITRE ATT&CK for Containers so findings have somewhere to sit.
Topics: Written authorisation, scope definition and rules of engagement · Blast radius, change windows and stakeholder notification · MITRE ATT&CK for Containers as a mapping frame · Attack surface: control plane, node, pod network, supply chain, cloud identity · Threat actor positions: internet, corporate network, pod, compromised node · Where self-assessment fits alongside auditing and runtime detection · Handling and storing findings responsibly
The mechanics, and the reasoning behind each mode. Installing and running kube-hunter, remote versus interface versus CIDR versus pod mode, passive discovery against active hunting and why active mode belongs only in a controlled window, and getting output into a form you can work with.
Topics: Installation: pip, container image and the in-cluster Job manifest · --remote, --interface and --cidr scanning modes · --pod mode: the compromised-workload vantage point · Passive hunting vs --active, and the risk of active checks · Output formats: plain, YAML, JSON and report handling · Logging, verbosity and reproducing a run · Choosing the vantage point that matches your threat model
The step that separates a useful report from noise. How hunters are organised, what discovery findings mean versus vulnerability findings, the identifier and category scheme, and a triage process that separates genuine exposure from expected behaviour and from false positives.
Topics: Hunter taxonomy: discovery hunters vs vulnerability hunters · Finding identifiers, categories and severity · Discovery results as a reachability map, not a vulnerability list · Triage: exploitable, exposed-but-controlled, expected, false positive · Corroborating a finding manually with curl and kubectl · Prioritising by reachability and blast radius rather than raw severity · Writing a finding up so an engineer can act on it
The highest-value findings and how to close them. Anonymous access to the API server, the insecure and read-only ports, etcd reachable without client certificate authentication, an exposed dashboard, and the kubelet's authenticated and read-only ports — each explained, then remediated, then re-tested.
Topics: API server anonymous authentication and unauthenticated endpoints · Authorisation mode and what anonymous callers can still enumerate · etcd exposure and client certificate authentication · Kubelet port 10250: authentication, authorisation webhook, /run and /exec · Kubelet read-only port 10255 and metrics exposure · Dashboard exposure and safe access patterns · Network placement: binding, firewalls and management network separation · Re-verifying each fix from the original vantage point
What an attacker gets after compromising one workload, which is the realistic starting point for most incidents. Service account tokens, cloud instance metadata endpoints, reachable internal services, Linux capabilities and privileged containers, and the paths from a container to the node.
Topics: Default service account token automounting and what a token can do · RBAC reachable from a compromised pod, and enumerating it · Cloud instance metadata endpoints and credential theft from pods · Lateral movement across namespaces without network policy · Capabilities, privileged containers, hostPID, hostNetwork and hostPath · Container-to-node escape paths and what blocks them · Kubelet and API server access from within the pod network
Turning findings into durable controls rather than one-off fixes. Least-privilege RBAC and service account hygiene, default-deny network policies, Pod Security Standards, admission control, secrets handling, and a verification loop that proves each control still holds after the next deployment.
Topics: Least-privilege RBAC and eliminating wildcard roles · Disabling automountServiceAccountToken and using bound tokens · Default-deny NetworkPolicies and namespace isolation · Pod Security Standards: baseline and restricted enforcement · Admission control with OPA Gatekeeper or Kyverno for durable guardrails · Secrets: encryption at rest, external stores, avoiding environment variables · Re-verification: scripted re-scans and regression evidence · Recording accepted risks with justification and review dates
Self-assessment as a repeating control instead of a project. Scheduling scans, combining kube-hunter with kube-bench and image scanning so exposure, configuration and content are all covered, reporting to security and engineering audiences, and handling the reality that any single tool has a lifecycle.
Topics: Scheduled self-assessment cadence and change-triggered scans · Combining kube-hunter with kube-bench, Trivy and runtime detection · Coverage gaps no scanner closes, and manual review · Reporting to engineering vs reporting to security leadership · Tracking exposure trend rather than snapshot counts · Tool lifecycle: kube-hunter is archived upstream — assessing successors · Migrating checks to actively maintained tooling without losing coverage · Incident readiness: what these findings tell you during a live incident
We rebuild the agenda around the tools you actually run.
Request a custom agendaWrite the scope, authorisation and rules-of-engagement document for your own cluster, including blast radius and the notification list, before any scan runs.
Scan the same cluster remotely, from the pod network and from inside a pod, then reconcile why the finding sets differ.
Take a raw report and manually corroborate each finding with curl and kubectl, classifying every one as exploitable, controlled, expected or false positive.
Remediate anonymous API access, kubelet 10250 and 10255, and etcd exposure, re-scanning after each change to prove the finding is gone.
From pod mode, enumerate the service account's reach and the metadata endpoint, then cut both with RBAC, network policy and token settings.
Run a full authorised assessment, remediate the backlog, add admission guardrails that stop regression, and produce the report and cadence plan.
Billed yearly at ₹9,996
Max 8 to 10 hours of live instruction
Full program, private instructor
8–30 engineers · custom agenda · onsite or online · PO and GST invoicing
Refunds. If we cancel or postpone a cohort, you get a full refund within 15 days. There is no money-back guarantee otherwise.
Terms. Course material remains licensed to the attendee. Read the terms.
Your data. We don't share it with third parties. Privacy policy.
Certificate of completion
Rajesh is a very good trainer I have experienced in DevSecOps training. The number of contents in different topics he has posted on the DevOpsSchool public website are amazing and user friendly for beginners and experienced professionals.
Very good training session. Well explained from the basics to the complex concepts. Also tried to cover practicals and demos within the 3 hour sessions. The learning content and videos are of a great deal of help.
Basics explanation was exemplary from Rajesh where he dealt with complicated topics to be simple. Great learning stuff personally for me.
Very detailed explanation and has lots of patience in attending the questionnaire. Thanks again for your wonderful sessions.
Good discussion, helped us to understand different tools in SRE.
Got good lab sessions which kept the new DevOps tool learnings to the point and it helped a lot in my career.
| What matters | YouTube + blogs | Generic online course | Freelance marketplace | DevOpsSchool |
|---|---|---|---|---|
| Named practitioner | No | Rarely | Varies per booking | Yes — same trainer each time |
| Production experience | Unknown | Unknown | Unverified | 20 years, named employers |
| Custom agenda | No | No | Sometimes | Built from your stack |
| Onsite delivery | No | No | Sometimes | Yes |
| Lab environment | None | Sandbox that expires | Varies | Your own cloud — skill goes with you |
| Assessment | None | Quiz | Rarely | Assignments + capstone per module |
| Per-attendee certificates | No | Sometimes | Rarely | Yes |
| Corporate invoicing | No | Limited | Varies | PO and GST |
| Post-training support | None | Forum, time-limited | None | Lifetime forum access |
Tell us the team, the stack and the timeline. You'll get a straight answer, not a sales sequence.
Talk to an advisorPrefer to call or email?
More ways to reach us on the contact page.