Private corporate batches, live online cohorts and 1-on-1 mentoring in cryptographic workload identity without secret zero — SPIFFE IDs, SVIDs, attestation and SPIRE — 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 SPIFFE through the attestation chain rather than the marketing of zero trust — node attestation against real platform evidence, workload attestation from kernel-observable selectors, and the Workload API handshake that delivers an SVID with no bootstrap secret anywhere in the path. Sessions cover the design work that determines whether a deployment lasts: trust domain and naming scheme choices, registration entries and selector precision, SVID lifetimes and rotation, and CA and key management including upstream authorities. Application-side integration is written and run in the lab — mutual TLS authorised by SPIFFE ID, JWT-SVID validation, Envoy SDS and spiffe-helper for workloads that cannot be changed — alongside federation across trust domains and exchanging SVIDs for cloud and Vault credentials to retire long-lived keys.
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 SPIFFE that means a trainer who has run it in production — cryptographic workload identity without secret zero — SPIFFE IDs, SVIDs, attestation and SPIRE — 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 SPIFFE batchSPIFFE — the Secure Production Identity Framework For Everyone — is a CNCF-graduated set of standards for giving software workloads a cryptographic identity that is issued automatically, rotates on its own, and works the same way across clouds, clusters and on-premise machines. A workload is named by a SPIFFE ID, a URI of the form spiffe://trust-domain/path, and proves that name with an SVID: either an X.509 certificate carrying the SPIFFE ID in its URI SAN, or a signed JWT. SPIRE is the reference implementation, and in practice SPIFFE and SPIRE are learned together.
The problem SPIFFE solves is secret zero. Conventional systems authenticate a workload with a credential — an API key, a certificate, a database password — that has to be delivered to the workload somehow, which requires another credential to authorise the delivery. SPIFFE cuts that regress by attesting instead of authenticating. A SPIRE agent proves what node it runs on using platform evidence such as an AWS instance identity document, a Kubernetes projected service account token or a TPM attestation. It then attests individual workloads by inspecting kernel-level facts about the calling process — its UID, its container, its Kubernetes pod — and hands identity documents over a Unix domain socket. Nothing is stored on disk, nothing is copied into an environment variable, and every SVID has a short lifetime and is rotated automatically before it expires.
What that identity unlocks is the practical payoff. Two services can establish mutual TLS and authorise each other by SPIFFE ID rather than by IP address or shared secret. Trust domains can federate, so workloads in different clusters or different organisations validate each other through published trust bundles. And through an OIDC discovery endpoint, a JWT-SVID can be exchanged for AWS, GCP or Azure credentials, or for a HashiCorp Vault token — which is how teams remove long-lived cloud access keys from applications entirely.
Static credentials remain the most common root cause in breach reports: a leaked API key in a repository, an access key that outlived the person who created it, a certificate that nobody rotated. At the same time the perimeter that used to make network location a proxy for trust has dissolved into multiple clouds, multiple clusters and third-party services. Zero-trust architecture is the stated direction for most security programmes, and workload identity is the part of it that actually has to be engineered rather than declared.
SPIFFE is the vendor-neutral standard for that layer, and it is already embedded in tools teams run. Istio issues SPIFFE-format identities natively, Envoy consumes SVIDs over SDS, Linkerd follows the same model, and Vault, cert-manager and the major clouds all have integration paths. That means the concepts transfer even for teams who never deploy SPIRE directly.
The skill is scarce in a specific way. Plenty of engineers can describe mutual TLS; far fewer can design a trust domain and naming scheme that survives a reorganisation, write registration entries and selectors that attest workloads correctly, federate two clusters, or plan an incremental migration from shared secrets to attested identity without a flag day. That design and migration work is where this training concentrates.
Why the credentials most systems use do not work any more. Secret zero and the bootstrap regress, network location as a failed proxy for identity, what breaks when workloads span clouds and clusters, and where SPIFFE sits against cloud IAM, service meshes, Vault and a private PKI.
Topics: Secret zero and the credential bootstrap problem · Static credentials: leakage, rotation debt and blast radius · Why IP address and network location are not identity · Zero trust, stated as an engineering requirement rather than a slogan · SPIFFE the specification versus SPIRE the implementation · SPIFFE compared with cloud IAM, mesh identity, Vault and internal PKI · Where SPIFFE already exists in tools you run
The data model, in detail. The SPIFFE ID URI and what belongs in its path, X.509-SVIDs with the identity in the URI SAN, JWT-SVIDs and their audience semantics, trust bundles and how a workload decides whom to believe — plus naming schemes that do not have to be rewritten after a reorganisation.
Topics: SPIFFE ID format: trust domain and path · X.509-SVID structure, URI SAN and validation rules · JWT-SVID structure, audience, subject and expiry · Choosing between X.509 and JWT SVIDs · Trust domains: one, several, or one per environment · Trust bundles and bundle distribution · Naming schemes: by service, by team, by environment · SVID lifetimes and why they are short · Common naming mistakes and their long-term cost
The mechanism that makes the whole thing work without a secret. Node attestation using platform evidence, workload attestation from kernel-observable properties of the calling process, selectors, and the Unix domain socket handshake through which an SVID is delivered and rotated.
Topics: Node attestation: join token, AWS IID, GCP IIT, Azure MSI, k8s PSAT, TPM, x509pop, sshpop · Node resolvers and node selectors · Workload attestation: unix, docker, kubernetes and systemd plugins · Selectors, selector precision and over-broad entries · The Workload API over a Unix domain socket · Why the socket path is not a secret · SVID delivery, caching and automatic rotation · The trust bundle stream and rotation of the CA · Failure modes: attestation denied, no matching entry, socket unavailable
Deploying and operating the implementation. Server and agent configuration, datastore choices, the CA options that matter for a security review, high availability and nested topologies, registration entry management, and the Kubernetes-native path with a controller and CRDs.
Topics: SPIRE server configuration and plugin model · Datastore options: SQLite, PostgreSQL, MySQL · CA choices: self-signed, disk-based upstream, AWS Private CA, Vault, cert-manager · Key manager plugins and hardware-backed keys · High availability and nested SPIRE topologies · SPIRE agent deployment on VMs and as a DaemonSet · Registration entries: parent ID, SPIFFE ID, selectors, TTL, federation · spire-controller-manager and ClusterSPIFFEID on Kubernetes · Entry lifecycle and automation from CI · Backup, disaster recovery and CA rotation
Turning an SVID into enforced authorisation. Fetching identity with the go-spiffe library, mutual TLS where the peer is authorised by SPIFFE ID rather than hostname, validating JWT-SVIDs, and giving identity to workloads that cannot be modified through spiffe-helper and Envoy SDS.
Topics: go-spiffe: X509Source, JWTSource and lifecycle · Mutual TLS with SPIFFE ID authorisers · Authorisation policy: exact ID, prefix, member-of-trust-domain · Validating JWT-SVIDs and audience checks · Libraries and Workload API support in other languages · spiffe-helper: writing rotating certificates to disk for legacy applications · Envoy SDS consuming SVIDs · Service mesh integration: Istio and Linkerd identity · Databases, message brokers and third-party components · Testing identity-based authorisation
Extending identity past one trust domain. Federation between clusters and between organisations through bundle endpoints, then the OIDC discovery provider that lets a JWT-SVID be exchanged for AWS, GCP or Azure credentials and Vault tokens — the fastest route to removing long-lived access keys.
Topics: Why more than one trust domain exists · Federation relationships and bundle endpoints · Bundle endpoint profiles: https_web and https_spiffe · Federating across clusters, clouds and organisations · The SPIRE OIDC discovery provider · Exchanging a JWT-SVID for AWS role credentials · GCP and Azure workload identity federation · Vault authentication with JWT and certificate methods · Removing static cloud access keys from applications · Auditing which identity was used for what
What it takes to run this as production security infrastructure. TTL and rotation policy, CA and key rotation, the revocation posture that short lifetimes imply, monitoring and alerting, threat modelling the attestation path, and a staged migration off shared secrets that never requires a flag day.
Topics: TTL policy and the trade-off between rotation load and exposure · CA rotation and trust bundle propagation · Revocation: why short SVID lifetimes replace CRLs, and the residual risk · Monitoring SPIRE: entry counts, attestation failures, rotation lag · Alerting on the failure modes that matter · Threat modelling: compromised node, compromised agent, over-broad selector · Hardening: agent socket permissions, admin API access, audit logging · Capacity and performance at large entry counts · Incremental migration: dual credentials, enforcement stages, cutover · Proving the design in a security or compliance review
We rebuild the agenda around the tools you actually run.
Request a custom agendaAttest a node with platform-native evidence, attest a workload by kernel-observable selectors, and obtain a rotating SVID over the Workload API with nothing stored on disk.
Deploy SPIRE across a Kubernetes cluster and virtual machines with a PostgreSQL datastore and an upstream CA, then automate registration entries with the Kubernetes controller.
Build two services that establish mutual TLS with go-spiffe, authorise each other by SPIFFE ID, and reject a peer that holds a valid certificate but the wrong identity.
Use spiffe-helper and Envoy SDS to give rotating credentials to an unmodifiable workload, and confirm rotation happens with no restart and no downtime.
Federate two SPIRE deployments through bundle endpoints and have a workload in one trust domain authenticate to a service in the other over mutual TLS.
Stand up the OIDC discovery provider, exchange a JWT-SVID for temporary AWS credentials and a Vault token, then delete the static access key and prove the service still works.
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.