Private corporate batches, live online cohorts and 1-on-1 mentoring in content trust for container images — TUF roles, key lifecycle, signing in CI and verification at the gate — 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 Notary around the trust hierarchy rather than around the commands: which role holds which key, why the root key stays offline, what the timestamp role actually protects against, and how delegations let teams sign within a bounded scope. Sessions cover Docker Content Trust and the notation-based second generation side by side, then the operational half most material skips — signing from CI without leaking keys, verification at the registry and at Kubernetes admission, staged rollout of enforcement, and the recovery procedure for a compromised signing key.
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 Notary that means a trainer who has run it in production — content trust for container images — TUF roles, key lifecycle, signing in CI and verification at the gate — 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 Notary batchNotary is the CNCF project that provides content trust for container images and other artefacts — a way to prove that the thing you are about to run was published by who you think, and has not been altered since. It is an implementation of The Update Framework, a specification designed around a hard assumption: that a registry or distribution server will eventually be compromised, and that trust must survive that event rather than depend on the server behaving honestly.
Two generations are in use. Notary v1 pairs a Notary server with a signer service and is the machinery behind Docker Content Trust, where setting DOCKER_CONTENT_TRUST=1 causes pushes to be signed and pulls to be verified. The Notary Project's second generation replaces that architecture with the notation CLI and a set of specifications: signatures are stored in the registry as OCI artefacts linked to the image through the referrers API, signing uses standard certificate-based identities, and verification is driven by a trust policy that names trust stores, identities and a verification level.
What both generations share is the model that makes signing meaningful. Separate roles hold separate keys — a root key that anchors trust and is kept offline, targets keys that sign the actual artefacts, delegation roles so individual teams can sign within their own scope, and snapshot and timestamp roles that provide freshness so an attacker cannot serve an old, still-validly-signed image forever. Getting that hierarchy, its key storage and its rotation procedure right is the entire discipline; a signature verified against a key nobody controls proves nothing at all.
The build pipeline became the attack surface. Several high-profile compromises worked by tampering with artefacts after they were built and before they were deployed, which is precisely the gap that a vulnerability scanner cannot see — the scanned image and the deployed image were simply not the same object. Signing and verification are the only controls that close it.
That has moved from good practice to requirement. Software supply chain guidance, SLSA levels, and an increasing number of customer and public-sector procurement requirements now ask for signed artefacts, verifiable provenance and an SBOM attached to the release. Registries and orchestrators followed: Harbor can require signed images before allowing a pull, and Kubernetes admission can reject an image whose signature does not verify against a trust policy.
The difficulty is operational, not conceptual. Everyone agrees images should be signed. Deciding who holds the root key and where it physically lives, how a build system signs without holding a key it could leak, how delegation is scoped per team, what happens the day a signing key is compromised, and how verification is enforced without stopping every deployment during rollout are the questions that determine whether a signing programme is real or ceremonial.
What signing is for. The specific attacks a signature stops — tampered artefacts, malicious mirrors, rollback to a known-vulnerable version, a compromised registry — and the ones it does not. Then The Update Framework's threat model, which assumes the distribution server is hostile.
Topics: Where artefacts are tampered with between build and deploy · What a signature proves, and the questions it leaves open · The Update Framework threat model and compromise resilience · Freshness, rollback and replay attacks · Signing versus scanning versus provenance versus SBOM · Notary v1 and the Notary Project second generation compared · Where cosign and Sigstore fit in the same problem space · Registry, orchestrator and pipeline as verification points
The model both generations are built on. Root, targets, snapshot and timestamp roles, what each signs and why they are separated, delegation roles that scope signing authority to a team or a path, threshold signatures, and metadata expiry as an active security control.
Topics: Root, targets, snapshot and timestamp roles and their responsibilities · Why role separation limits the damage from any single key compromise · Delegation roles and scoping signing authority · Threshold signing and requiring multiple signatures · Metadata expiry, timestamping and freshness guarantees · Trust bootstrapping and pinning the root of trust · Reading and interpreting TUF metadata directly · Designing a hierarchy for a multi-team organisation
The first-generation implementation still deployed widely. Standing up a Notary server and signer, initialising trust for a repository, signing on push and verifying on pull, managing delegation roles for teams, and the client-side key material that lives on a developer's machine.
Topics: Notary server and signer architecture · Initialising trust for a repository and generating the root key · DOCKER_CONTENT_TRUST and the push and pull workflow · Local trust directory, key storage and passphrases · Adding and removing delegation roles for teams · Signing from a machine that is not a developer laptop · Diagnosing verification failures · Operational limits of the v1 architecture
The part that decides whether any of this is real. Generating keys properly, keeping the root key offline, hardware-backed storage, backup and custody, planned rotation, and the emergency procedure for the day a signing key is believed to be compromised.
Topics: Key generation, algorithms and strength choices · Offline root keys: storage, custody and access procedure · Hardware-backed and HSM-backed signing keys · Backup, escrow and split custody · Planned rotation of targets and delegation keys · Emergency rotation and root key compromise recovery · Revocation and what clients must do to honour it · Documenting the procedure so it works under pressure
The current direction of the Notary Project. The notation CLI, signatures stored as OCI artefacts and discovered through the referrers API, certificate-based signing identities, and the trust policy file that determines which identities are accepted for which artefacts and at what verification level.
Topics: The notation CLI: sign, verify, list and inspect · Signatures as OCI artefacts and the referrers API · Signature formats and envelope choices · Certificate-based identities and certificate chains · Trust stores: certificate authority and signing authority types · Trust policy: scopes, trusted identities and verification levels · Plugins and integration with external key management · Interoperating and migrating from Docker Content Trust
Making it automatic. Signing from a pipeline without handing a build a key it could leak, then enforcing verification where it counts — at the registry, at Kubernetes admission, and in the deployment pipeline — with a rollout that does not stop delivery on day one.
Topics: Signing from CI with short-lived credentials or a remote signing service · Keeping signing keys out of build logs, caches and images · Registry-side enforcement, including Harbor content trust policy · Verification at Kubernetes admission and policy controller options · Verifying in the deployment pipeline before rollout · Staged enforcement: audit, warn and reject · Handling third-party and base images that are not signed · Air-gapped and disconnected verification
Beyond 'who signed it' to 'how was it built'. Attaching provenance and SBOM attestations to an artefact, verifying them alongside the signature, placing the result against SLSA expectations, and the governance that keeps a signing programme working after the project that introduced it ends.
Topics: Provenance attestations and in-toto statements · Attaching and verifying SBOM attestations · SLSA levels and what each actually requires of a build system · Verifying provenance as part of an admission decision · Coexisting with cosign and Sigstore-based signing · Ownership: who runs the trust hierarchy day to day · Auditing signing activity and detecting unexpected signatures · Metrics, expiry monitoring and keeping trust metadata fresh
We rebuild the agenda around the tools you actually run.
Request a custom agendaBuild a role and delegation hierarchy for three teams sharing a registry, then inspect the resulting metadata and explain what each signature asserts.
Stand up a Notary server, sign a repository, add per-team delegation roles, and prove a delegated key cannot sign outside its scope.
Rotate a targets key on a live repository with no consumer failures, then rehearse a root key compromise and execute the full recovery procedure.
Sign with notation, inspect the signature through the referrers API, and write a trust policy that accepts only your identity at a stated verification level.
Sign from CI without long-lived key material, then enforce verification at the registry and at Kubernetes admission, moving from audit to reject cleanly.
Attach provenance and SBOM attestations to a release, verify them alongside the signature at admission, and assess the pipeline against a SLSA level.
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.
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.
The Rundeck developer session was excellent and highly engaging. I appreciated how well the session was structured, with the theoretical concepts explained clearly and in simple terms. What stood out most to me was the demo — it was both informative and enjoyable. I especially liked how Rajesh walked us through not only the happy path but also the sad path, showcasing common issues and sharing practical troubleshooting tips.
Rajesh's experience and knowledge are exceptional and we learnt invaluable practical knowledge which we can apply in our production environment. Incredibly friendly and gave us a fantastic insight both in-depth and at a high level of the Rundeck product.
Great learning experience from a very knowledgeable instructor with well-prepared course notes. The lab exercises on AWS instance work well to learn the hands-on side of the course.
The trainer (Rajesh) provided very good sessions on SRE profession. Not only hands-on learning on the tools but also SRE mindset.
| 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.