IntegrAuth Academy
Identity, security and practical AI — free, from zero. Byte-sized lessons, real diagrams, hands-on labs, zero fluff. Two programs, each with its own exam and certificate.
English is hard? Your browser can translate this page into Tamil, Telugu, Kannada, Malayalam or Hindi. Tech words stay in English so you learn the real names.
How?
- Chrome on phone: ⋮ menu → Translate
- Chrome on computer: right-click → Translate to …
- Edge: the translate icon in the address bar
Secrets management & rotation
Even with tokens and SVIDs, a few real secrets stay. A database password. A partner's API key. Your goal: know where such a secret should live, and how to make it useless soon after it leaks.
- Never put a secret in source code or a repo.
- Keep it in a vault. The workload fetches it with its own identity.
- A dynamic secret expires in minutes. A static one lasts for months.
- Rotate with an overlap window, never a hard swap.
- Scan for leaks and alert on odd use.
Some secrets stay
Workload identity, from the SPIFFE lesson, handles most machine trust with no shared secret. But some systems still want a fixed credential. A legacy database may know only passwords. A partner API may give you one long key. These are the stragglers.
Bots often find a key pushed to a public repo within minutes, as in the client-credentials lesson.
Where secrets live: a central vault
The home for a straggler secret is a secrets manager, a vault built for this job. It stores secrets encrypted. It controls who can read each one. It writes a log line for every read.
The secret is not baked into the workload. The workload fetches it when it runs. It proves who it is to the vault with its own workload identity, such as an SVID. Nothing is copied into an image, an env file or a wiki page.
the key cabinet in a school office. You sign the register, and the clerk hands you the classroom key. The register says who took it and when. The key goes back in the cabinet after the lesson. Nobody keeps a copy at home.
Zara, the security operator, never emails a password to a new service. The service proves its identity to the vault and fetches a database credential that lasts fifteen minutes. If an attacker takes over the service, the credential dies soon. Every fetch is in the audit trail with the workload's name.
Dynamic beats static
A static secret is set once and reused for months. It stays valid until a person notices a leak and changes it. A dynamic secret is made on demand for one workload. It expires in minutes, so a leak ends almost at once.
Dynamic is better almost every time. The window for misuse is small. Sometimes you are stuck with a static secret. Then the habit that saves you is rotation. Change the secret on a schedule.
Rotation done right: the overlap window
Rotation is a routine you automate, so leaks age out on their own. Use an overlap window:
- Create the new secret next to the old one. Both are accepted.
- Deploy the new secret to every service that uses it.
- Check that nothing still uses the old secret.
- Retire the old secret.
The wrong way is a hard swap. You switch off the old secret and switch on the new one at the same instant. Every service that still holds the old value is refused, and you have an outage. Refresh-token rotation (see the tokens track) uses the same idea.
Catching a leak
Secret scanning in your pipelines catches a key before it is committed. Identity logs go to a SIEM. A credential used from a strange place, at a strange hour, or far too often should raise an alert.
A hard swap can take the app down. Automate rotation and always use an overlap window.
Go deeper: secrets tools (as of October 2026)
Every major cloud has its own secrets manager. There are also tools you can run yourself. HashiCorp Vault has used the Business Source License since version 1.15 (2023), with IBM as the licensor. That license is not open source in the usual sense. OpenBao is a community project hosted by the OpenSSF at the Linux Foundation. It began as a fork of Vault's last open-source release.
The ideas in this lesson work with all of them: runtime fetch, short lives, audit logs and rotation.
Go deeper: getting secrets into Kubernetes
The External Secrets Operator reads secrets from an outside manager and copies them into Kubernetes Secrets. The copy is a normal Secret. So anyone who can read Secrets in that namespace can read it, including through list or watch. Guard it with RBAC (see the Kubernetes lesson). Mounting a secret as a file at run time is usually safer than an environment variable. Environment variables show up in crash reports and child processes.
🧪 Interactive lab — enable JavaScript to play with this one.
Trade a static secret for short-lived, identity-based credentials. Analyze workload identity federation trust with OIDC Federation. Build a private-key client assertion, which needs no shared secret, with Client Assertion Check.