Private corporate batches, live online cohorts and 1-on-1 mentoring in Layer 7 container firewalling and behavioural protection — discover, monitor, protect, with scanning and compliance — 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 NeuVector around the Discover, Monitor and Protect progression rather than around the console: what a representative discovery period looks like, how to review and edit a learned rule set before promoting a group, and how to reach Protect mode without blocking legitimate traffic. Sessions run against live clusters and cover the Layer 7 inspection model in depth — protocol identification, network rules by application, threat and DLP sensors, packet capture for investigation — alongside registry and pipeline scanning, admission control, CIS compliance and multi-cluster federation.
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 NeuVector that means a trainer who has run it in production — Layer 7 container firewalling and behavioural protection — discover, monitor, protect, with scanning and compliance — 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 NeuVector batchNeuVector is an open-source Kubernetes security platform, released under Apache 2.0 by SUSE and shipped commercially as SUSE Security. It covers vulnerability scanning, compliance benchmarking, admission control and runtime protection, but the capability that sets it apart from the rest of the category is network inspection: an Enforcer pod on every node performs deep packet inspection on container traffic, identifies the application protocol in use, and can allow, alert on or block a connection based on Layer 7 behaviour rather than only on IP address and port.
The deployment is a small set of components. Controllers hold policy and cluster state and expose the API. Enforcers run as a DaemonSet, see the traffic and the process activity on their node, and carry out enforcement locally. The Manager provides the console, the Scanner performs vulnerability analysis for registries, pipelines and running workloads, and the Updater refreshes vulnerability data on a schedule. In a multi-cluster estate a federation layer lets one primary cluster distribute policy to many managed clusters.
Operationally NeuVector is organised around groups and three policy modes. Workloads are automatically grouped by service, and each group moves through Discover, where NeuVector learns the network connections, processes and file access that are normal; Monitor, where deviations are alerted but allowed; and Protect, where they are blocked. That progression is the core skill in using the product — the learned baseline is only as good as the traffic observed while learning, so knowing what to run during discovery, how to review a learned rule set before promoting it, and how to handle workloads that legitimately change behaviour is what determines whether Protect mode is safe to switch on.
Kubernetes network policy stops at Layer 3 and 4. It can express that one namespace may reach another on port 8080, and nothing more — not which API is being called, not whether the traffic is really HTTP, not whether a connection that has always carried database queries has started carrying something else. As lateral movement became the phase of an attack that defenders most want to interrupt, that ceiling started to matter.
At the same time the buying pattern changed. Container security was dominated by commercial suites with per-node pricing that scales badly; NeuVector being open-sourced put a full platform — scanning, compliance, admission control, runtime and network enforcement — within reach of teams that could not justify a licence, and made it a common choice inside Rancher-based and multi-cluster estates.
What teams struggle with is the learning model rather than the installation. A Helm chart brings the platform up quickly and Discover mode starts producing rules immediately, but a baseline learned during a quiet weekend will block half of Monday's traffic. Deciding what constitutes a representative discovery period, reviewing and editing learned rules rather than accepting them, choosing group criteria that survive redeployment, and staging the move to Protect per group instead of per cluster are the skills that make the difference between real enforcement and a platform permanently parked in Monitor.
What each component does and what that means when it runs on every node. Controllers, Enforcers, Manager, Scanner and Updater; Helm-based deployment; high availability for the control components; and the resource footprint of packet inspection on a busy node.
Topics: Controller, Enforcer, Manager, Scanner and Updater responsibilities · Deploying with Helm and the values that actually matter · Controller high availability and cluster state · Enforcer as a DaemonSet: privileges, placement and node coverage · Resource footprint of deep packet inspection · Behaviour when a Controller or Enforcer is unavailable · Air-gapped installation and offline vulnerability updates · Upgrade paths and version skew between components
The concept everything else hangs on. How workloads are grouped automatically by service, how to define custom groups with criteria that survive redeployment, and what actually happens during Discover mode — plus the network activity map that makes a real architecture visible for the first time.
Topics: Automatic service groups and their naming · Custom groups and criteria that survive redeploy and rescale · Discover mode and what is learned: connections, processes, file access · Designing a representative discovery period · The network activity map and reading real traffic · Reviewing and editing learned rules before promoting · Nodes, host groups and platform groups · Group inheritance and policy precedence
The capability that distinguishes the platform. Deep packet inspection identifying the protocol on a connection, network rules expressed by application rather than by port, egress and external destination control, threat signatures for known attack traffic, and packet capture when an alert needs to be understood.
Topics: Deep packet inspection and protocol identification · Network rules between groups, by application and by port · Allow, alert and deny actions and their ordering · Egress control and external or FQDN-based destinations · Comparison with Kubernetes NetworkPolicy and with a service mesh · Threat detection signatures and what they catch · Packet capture and investigating a specific connection · Encrypted traffic and the limits of inspection
Constraining what a container can do, not just what it can reach. Learned process profiles, file access rules, and zero-drift protection that prevents execution of any binary not present in the original image — with the tuning needed for workloads that legitimately spawn helper processes.
Topics: Process profile rules and how they are learned · Zero-drift protection and what it prevents · File access rules and monitored paths · Host and node-level protection · Handling workloads that legitimately execute new binaries · Privileged containers and what protection remains possible · Alerting versus blocking per rule dimension · Investigating a process violation to a decision
Stopping bad images before they run and finding them after they do. Registry scanning, scanning inside a CI pipeline, continuous scanning of running containers, nodes and the platform itself, and admission control rules that reject a deployment on vulnerability, configuration or compliance criteria.
Topics: Registry scanning: scope, scheduling and credentials · Scanning in CI and failing a build on policy · Continuous scanning of running containers, nodes and the platform · Vulnerability database updates, including air-gapped · Base image and layer attribution of findings · Admission control rules and enforcement modes · Blocking on vulnerability, image source, configuration and compliance criteria · Exceptions, allowlists and their expiry
The evidence and content-inspection layer. CIS benchmark checks for Docker, Kubernetes and hosts, compliance profiles mapped to regulated control sets, data loss prevention sensors that match patterns inside traffic payloads, and web application sensors for common injection attacks.
Topics: CIS benchmark checks for Docker, Kubernetes and hosts · Compliance profiles and mapping to regulated control sets · Scheduling, scoping and exempting compliance checks · DLP sensors: pattern design and where they apply · Web application firewall sensors and their false positive profile · Reporting compliance and violation state over time · Exporting evidence for an audit · Tuning content inspection without disabling it
Running it for an organisation. Federation from a primary cluster to managed clusters, RBAC and single sign-on, response rules that act automatically when a violation fires, integration with SIEM and ticketing, and the operational routine of upgrades, backup and policy as code.
Topics: Federation: primary and managed clusters, and what is distributed · Policy consistency and drift across clusters · RBAC roles, namespace scoping and SSO integration · Response rules: quarantine, suppress and webhook actions · Notification and SIEM integration, and syslog output · Backing up and restoring configuration · Policy as code through the REST API and version control · Upgrade planning and rollback across a fleet
We rebuild the agenda around the tools you actually run.
Request a custom agendaDeploy Controllers, Enforcers, Manager and Scanner to a cluster, verify node coverage, then measure inspection overhead under load and set real resource limits.
Design and run a representative discovery period for a live application, then review, prune and justify every learned rule before promoting the group.
Write Layer 7 network rules permitting only the protocols a service genuinely uses, control egress destinations, and capture packets to explain a blocked connection.
Move a workload to Protect for network, process and file dimensions with zero-drift enabled, and confirm nothing legitimate is blocked before and after a redeploy.
Gate a CI pipeline on scan results and write admission rules that reject insecure workload patterns, then prove both paths cannot be bypassed.
Federate a primary and a managed cluster, distribute a single policy set, wire automated response rules, and prove the clusters cannot drift apart.
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.
Got good lab sessions which kept the new DevOps tool learnings to the point and it helped a lot in my career.
I took Terraform training with the tutor named Mithilesh. I requested to tailor the course curriculum for my needs. He did an excellent job of showing me how to write the Terraform script per the instructions provided.
My experience with the AIOps training was positive. The course covered important topics in a structured way, and Rajesh Kumar explained the concepts patiently. I found the practical aspects particularly helpful because they made the technical content easier to understand.
I was looking to improve my understanding of AIOps, and this training helped me achieve that goal. Rajesh Kumar explained the subject in a structured and practical manner. The sessions on different AIOps concepts were informative.
I recently did a SRE Session with Rajesh Kumar from DevOps School and the session was great. Right from 1st day till day 15, we had a very interactive session. Rajesh clarified our doubts and the tool demos were excellent without any hiccups. He simplified the concepts while sticking to the content with a fine balance between theory and practice. Am convinced he is one of the best trainers for SRE & DevOps concepts.
| 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.