A password committed "temporarily" to Git, found three months later by an attacker: the commit had been deleted, but the history keeps everything. This course teaches you to avoid that scenario and all its cousins. It has you inventory the secrets of a system, store them in a vault, issue them with a bounded lifetime, remove the shared secret in favour of a machine identity, then detect a leak and respond to it. It is aimed at people who run or develop a system and already know how to use a Linux terminal; the module on leaks also asks you to read a Git history and build a container image. HashiCorp Vault serves as the implementation, and the notions hold with any vault.
Who is the secrets management course for?
Secrets management is not only a security matter: it concerns everyone who handles code, infrastructure or data. The course is at intermediate level and every role finds its share, from the developer to the CISO.
| Profile | Responsibility | Where the course helps |
|---|---|---|
| Developer | Never commit a secret, use injection at startup | Inventory, leak surfaces |
| Ops / SRE | Configure vaults, automate rotation and revocation | Vault, dynamic secrets |
| DevSecOps | Detect exposed secrets, integrate scans into CI/CD | Leak detection and response |
| CISO | Management policy, compliance audit | Anchoring on the SOCLE requirements |
| Tech Lead | Code review, team culture, tool choices | Choosing static, dynamic or identity |
What do you need before you start?
The declared prerequisite of the course is the Linux training: everyday use of the terminal is enough for every module but one. The module "Detect a leak, and respond to it" works on a real repository and on real images, and therefore assumes two more skills: reading the Git history and building then running a container image.
- Git: knowing how Git records a project and reading its history to find what changed. The Git training (in French) teaches it, in particular the lesson Browsing the history (in French).
- Container images: writing a Dockerfile, building an image, then running a container. The Docker training (in French) teaches it, with the guide Dockerfile (in French).
The quizzes of the leak module assess these two skills. If one is missing, follow the matching training first: the first five modules can be read without them, and so can the seventh, which is optional.
In what order do the ideas build on one another?
The course follows a simple idea: you only protect what you know about, you only issue with a bounded lifetime what you know how to store, and you only detect a leak if you know what to look for. The modules are therefore read in this order, each one resting on the previous one.
The first module sets the vocabulary and the register. You learn to recognise a secret, to measure the cost of a secret that lives for months, then to keep the inventory that serves as the basis for everything else. The second module walks through the lifecycle of a secret, from its generation to its destruction, and compares three models: the static secret, the dynamic secret and the federated identity. It also introduces envelope encryption, which protects the vault itself.
The third module puts a secret in a vault and opens it only to whoever needs it: storage, authentication, then access policies. The fourth draws the consequence: a secret issued on demand, valid for a few minutes, is revoked in one go. The fifth tackles the last secret that remains to be distributed, the one that lets you authenticate to the vault, and replaces it with a verifiable machine identity. The sixth closes the loop: where does a secret get out (the Git history first, then logs and images), how do you spot it, and what do you do once it is out. It is the only module to require Git and container images.
A seventh module, optional, is for whoever runs the vault rather than whoever consumes secrets: installation, sealing, backup, monitoring, and choosing the edition according to its licence. The course outline in the left-hand column, and the progress tracking on the My course page, give the detail lesson by lesson.
What the course does not cover
A course about application-level practice has a clear boundary. It does not deal with human secrets: a password manager such as Bitwarden (in French) or Passbolt (in French) answers a different need, with mandatory MFA (multi-factor authentication) and controlled, audited sharing. Nor does it detail how a secret is consumed on a given platform: Kubernetes secrets (in French) and CI/CD pipeline secrets have their own guides, because those contexts have their own constraints.
One point deserves to be made upfront: Kubernetes Secrets are a distribution mechanism, not a protection one. Their security depends on etcd encryption (often disabled), on RBAC and on the security of the cluster. Putting them at the centre of a strategy gives a false sense of security.
Which principles guide the whole course?
Whatever the tool, sound management rests on six principles that every lesson takes up at its own level.
- Separate code and secrets: the source code never contains a secret; it is injected at startup from a safe source.
- Encrypt, centralise, trace: secrets live in an encrypted vault, at a single point, with every access audited (who, when).
- Least privilege: each secret grants the strict minimum, never an admin access "for convenience". This principle has its own concept page.
- Rotation and revocation: a secret must be changeable and invalidatable quickly; if it is painful to renew, it will not be renewed.
- Automate: humans are the weak link, so you automate generation, distribution and rotation.
- Reduce persistent secrets: favour dynamic secrets (generated on demand, short-lived) and workload identity (proving who you are rather than holding a durable secret).
Which pitfalls does the course teach you to avoid?
These mistakes recur even in organisations that already use a vault. The table links each one to its consequence and to the remedy the course teaches.
| Pitfall | Consequence | Remedy |
|---|---|---|
| Static secret shared between services | Impossible to attribute an incident | One identity or secret per workload |
| Rare manual rotation | Secret valid for too long | Dynamic secrets or automated rotation |
| Kubernetes Secrets as the only vault | False sense of security | etcd encryption + RBAC + External Secrets |
| Long-lived cloud token in CI/CD | Lasting compromise | OIDC, temporary access, workload identity |
| Secrets in environment variables only | Exposure in logs and dumps | Controlled injection, minimal lifetime |
| Same secret in dev, preprod and prod | A leak in dev compromises prod | Separate secrets per environment |
| Committing "temporarily" | The Git history keeps everything | Pre-commit hook with secret detection |
How is the course validated?
Each lesson carries a Key points section that fixes the essentials, followed by a quiz when the lesson has one. The proof the course aims for is not a score: it is the ability to produce, for a given system, what the site's reference framework requires. The SOCLE threat model for secrets (in French) lists the attack vectors (plaintext secret, stolen token, misconfigured OIDC) and the SOCLE reference framework for the secrets domain (in French) links them to verifiable requirements: inventory, encrypted vault, scoped and traced access, rotation, ephemeral identities, leak detection.
Within the course, the quizzes do the assessing: they measure how well you understood each lesson. A passed quiz shows that you understood, not that you can produce an inventory or a rotation: those requirements of the reference framework are demonstrated on your own system.
To place the course, two external references frame the subject: the OWASP Secrets Management Cheat Sheet for good practices, and the publication NIST SP 800-57 for cryptographic key management. On the tooling side, the Vault documentation and the SPIFFE / SPIRE project serve as the reference for dynamic secrets and workload identities.
Key points
-
Source code must never contain secrets: this is the basic rule.
-
A static secret must be the exception, not the norm: aim for dynamic secrets and workload identity.
-
A dynamic secret beats a long-lived secret: it shrinks the window of exploitation and revokes itself.
-
For machine-to-machine, think identity before password: SPIFFE, workload identity, OIDC.
-
Reduce persistent secrets progressively, not all at once: start with the most durable, shared and critical ones.
-
You only protect what you know about: the inventory comes before the vault, rotation and detection.