Private corporate batches, live online cohorts and 1-on-1 mentoring in CIS Kubernetes Benchmark auditing, remediation and continuous compliance evidence — 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-bench as the auditing half of a Kubernetes hardening programme, not as a scanner to run once. The syllabus works control by control through the CIS benchmark sections — API server, controller manager, scheduler, etcd, kubelet and the policies group — explaining what each flag actually protects against before any remediation is applied, then verifying the fix by re-running the audit. Sessions run against real clusters the attendees own, include the failures that come from remediating carelessly, and cover the managed-cluster case where half the controls are outside your control.
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-bench that means a trainer who has run it in production — CIS Kubernetes Benchmark auditing, remediation and continuous compliance evidence — 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-bench batchkube-bench is an open-source tool that checks whether a Kubernetes cluster is configured according to the CIS Kubernetes Benchmark. It is an auditing tool, not an exploit tool: it inspects process arguments, configuration files and file permissions on the machine it runs on, compares them against the benchmark's controls, and reports each one as PASS, FAIL, WARN or INFO along with the remediation text from the benchmark.
It is written in Go and driven entirely by YAML configuration under cfg/, with one directory per benchmark version. It detects the running Kubernetes version and selects the matching benchmark, or you pin one with --benchmark. Controls are grouped into targets — master, controlplane, etcd, node, policies and managedservices — and you choose which to run with --targets. Because the control-plane checks need to see the host's processes and files, kube-bench is normally run as a Job with hostPID and the relevant host paths mounted, one Job for control-plane nodes and one for workers.
The output is designed to be consumed by machines as well as people. --json and --junit produce structured results for pipelines and dashboards, and there is integration for pushing findings to AWS Security Hub. Custom benchmark files let you add organisation-specific controls or suppress ones that do not apply, which is what turns kube-bench from a one-off scan into a repeatable compliance control with an audit trail.
Kubernetes configuration is where most cluster security is won or lost, and the defaults are not safe. An API server left with anonymous authentication enabled, a kubelet with its read-only port open, etcd without client certificate authentication, or a static pod manifest that is world-writable are all configuration mistakes, not vulnerabilities — no patch fixes them and no scanner that only looks at images will find them.
At the same time, compliance obligations have caught up with container platforms. SOC 2, PCI DSS, ISO 27001 and internal security reviews now ask specifically how the control plane is hardened and how that hardening is evidenced over time. Auditors want a repeatable check with dated output, not an engineer's assurance.
kube-bench sits exactly at that intersection, which is why it appears in so many platform security programmes. The skill it demands is not running the binary — that takes a minute. It is reading the results correctly, understanding what each control actually protects against, knowing which failures are genuine risk and which are artefacts of a managed control plane you do not own, and remediating without breaking the cluster.
The benchmark before the tool. How CIS benchmarks are structured, the difference between scored and not-scored controls and between Level 1 and Level 2 profiles, how benchmark versions map to Kubernetes versions, and where this fits alongside the rest of a cluster security programme.
Topics: How CIS benchmarks are written and versioned · Scored vs not-scored controls, Level 1 vs Level 2 profiles · Benchmark version to Kubernetes version mapping · Configuration hardening vs vulnerability scanning vs runtime detection · What auditors ask for and what constitutes evidence · Scope: what the benchmark deliberately does not cover
Getting accurate results, which is harder than it looks. Installation options, why control-plane checks need host process and filesystem visibility, running as a Job on the right node class, version auto-detection versus pinning, and interpreting each result state honestly.
Topics: Installing kube-bench: binary, container and Job manifests · Why hostPID and host path mounts are needed for control-plane checks · Targeting nodes: master, controlplane, etcd, node, policies · --benchmark and --version, auto-detection and when it is wrong · Reading PASS, FAIL, WARN and INFO correctly · Output formats: text, --json, --junit, --outputfile · Common causes of misleading results
The API server, controller manager and scheduler sections in depth. What each flagged argument actually does, the ones that break clusters when changed carelessly, static pod manifest and file permission controls, and how to apply changes safely on a live control plane.
Topics: API server authentication controls: anonymous auth, token auth, client certificates · Authorisation mode and admission control plugin controls · Audit logging: policy file, log path, retention flags · Encryption at rest and the encryption provider configuration · Controller manager and scheduler controls · Static pod manifest and kubeconfig file ownership and permissions · Applying control-plane changes safely and rolling back
The two areas where a single misconfiguration is worth the whole cluster. etcd client and peer TLS and certificate authentication, then the kubelet: anonymous authentication, the authorisation mode, the read-only port, certificate rotation and the config file controls.
Topics: etcd client and peer TLS, cert-file, key-file and client cert auth · etcd data directory ownership and permissions · Kubelet anonymous auth and the authorisation webhook mode · The read-only port and the metrics exposure question · protect-kernel-defaults, event record limits and streaming timeouts · Kubelet config file vs command-line arguments, and which the benchmark checks · Client and server certificate rotation
The section kube-bench mostly reports as WARN, because it cannot inspect intent. Working through it manually: RBAC and least privilege, service account defaults, Pod Security Standards replacing PodSecurityPolicy, network policy coverage, secrets handling, and image provenance controls.
Topics: RBAC least privilege and cluster-admin usage · Wildcard roles, escalate, bind and impersonate verbs · Service account automounting and default service accounts · Pod Security Standards: privileged, baseline, restricted · Container security context: privileged, hostPID, hostNetwork, capabilities · Default-deny network policies per namespace · Secrets as files vs environment variables, and external secret stores · Image provenance and admission control
Most clusters are EKS, AKS, GKE or a vendor distribution, and half the control-plane controls are then not yours to fix. The managed benchmarks, what the shared responsibility boundary actually means for each control, and how to report honestly on findings you cannot remediate.
Topics: Managed benchmark variants for EKS, GKE, AKS and OpenShift · The managedservices target and what it checks · Shared responsibility: which controls the provider owns · Node-level hardening on managed node groups and node pools · Distribution-specific file paths and why auto-detection fails · Reporting non-applicable controls to an auditor defensibly · Compensating controls where remediation is impossible
Turning a scan into a control. Writing custom benchmark YAML for organisation-specific requirements, handling documented exceptions without silently ignoring them, scheduling scans, gating pipelines on failure counts, and tracking hardening drift over time.
Topics: kube-bench config YAML: audit, tests, test_items, bin_op and compare · Adding organisation-specific controls to a custom benchmark · Exception handling: documenting rather than deleting a control · Scheduled scanning as a CronJob across a fleet · CI gating on JSON or JUnit output and failure thresholds · Feeding results into dashboards and AWS Security Hub · Tracking drift and reporting trend rather than snapshot · Combining kube-bench with image scanning and runtime detection
We rebuild the agenda around the tools you actually run.
Request a custom agendaRun kube-bench across control-plane and worker nodes, reconcile the reports, and classify every finding by severity and ownership before touching anything.
Remediate authentication, authorisation, admission and audit controls on a live control plane, verifying cluster health after each change.
Disable anonymous authentication and the read-only port, switch to webhook authorisation, enable certificate rotation, and prove the change with a re-run.
Take the policies section manually: reduce an over-permissive RBAC model, apply the restricted Pod Security Standard, and add default-deny network policies.
Run the managed benchmark against a cloud cluster and produce a report that separates provider-owned controls from your own with compensating controls documented.
Write custom controls, schedule fleet-wide scanning, gate a pipeline on failure thresholds, and produce dated evidence an auditor would accept.
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.