Secrets management: scanning, rotation and leak response
You keep passwords, keys and tokens out of code, catch leaks with gitleaks, store them in Vault and revoke and replace a leaked key.
Level 201 · 20 lessons · 18 practice labs
Lessons
Foundations
- What a secret is: passwords, keys, tokens, certificates: You will recognise the kinds of secrets applications use and understand what each one would unlock if it were exposed.
- Where leaks come from: code, logs, images, screenshots: You learn, through realistic workplace examples, the most common ways secrets get out.
- Building an inventory of your organisation’s secrets: You will prepare an inventory showing where each key is used, who owns it and when it was last changed.
- Short task: list every secret of a sample project with its owner and lifetime
Detection
- Scanning repository history with gitleaks: You will scan the whole history of a Git repository with gitleaks, find forgotten keys and weed out false alarms.
- Checking whether a found key is still valid with trufflehog: You will use trufflehog to tell which found keys still work and set your response priority accordingly.
- Blocking secrets from entering the repository with a pre-commit hook: You will use a hook on the developer’s machine so changes containing keys are stopped before they are committed.
- Searching container images and logs for secrets: You will find passwords and tokens left in image layers and application logs and close off where they came from.
- Short task: scan three repositories and one image and separate the live keys
Safe storage
- Environment variable or file: ways to hand secrets to an app: You will compare the pros and risks of passing a secret as an environment variable, a protected file or a secrets service.
- Encrypted configuration files with sops: You will encrypt secret values in a configuration file with sops, keep it safely in the repository and let only authorised people open it.
- A central secrets store with HashiCorp Vault: You will write and read secrets in Vault and define policies that give each application access only to its own path.
- Short-lived and dynamic credentials: You learn how credentials that expire on their own, instead of fixed passwords, shrink the impact of a leak.
- Scoped keys: only the access each job needs: You will create separate keys for each service and job that allow only the actions needed, ending shared key use.
- Short task: move an app’s database password into Vault
Responding to a leak
- The first hour after a leak: scope and impact: You will quickly work out what the leaked key reaches, how long it has been exposed and who must be told.
- Revoking and rotating a key and updating dependent services: You will replace a leaked key with a new one without downtime, revoke the old one and confirm every service still works.
- Cleaning history with git filter-repo and why that alone is not enough: You will remove a key from repository history with git filter-repo and understand why revoking it is the real fix, because copies remain.
- Reviewing usage logs of a leaked key: You will review the requests made while the key was exposed and determine whether there was any unauthorised use.
- Capstone: end-to-end response to a key pushed to a public repository: You find a key pushed to a public repository, revoke and rotate it, review its use and set up controls that stop it happening again.
Practice labs
- Tell apart the kinds of secret in a sample project: Classify ten given values as password, API key, token, private key or certificate.
- Build the project’s secret inventory with owner and lifetime: List every secret in code, pipeline and server configuration with where it lives, its owner and rotation period.
- Search four leak channels and complete the inventory: Find exposed secrets in code, logs, images and documentation screenshots and add the two missing from the inventory.
- Scan repository history with gitleaks: Scan the full history and list the rule name, file and commit of each finding.
- Search a container image and logs for secrets: Scan the image layers and application logs and state which layer and log line contain the token found.
- Scan three repositories and one image and separate the live keys: Deduplicate the findings, weed out false alarms and list keys still valid by verifying them only against the lab service.
- Install a pre-commit hook and block a leak: Add the gitleaks hook to the repository and show a commit containing a key is rejected.
- Write an allowlist for a pattern that raises false alarms: Exempt fake keys in test data by path and pattern in the gitleaks configuration and confirm a real key is still caught.
- Write a custom rule for the organisation’s key format and enforce it server-side: Write a rule that catches Yakamoz Telekom’s internal token format and show a push that skips the local hook is stopped by the server-side check.
- Have the app read a secret from a file instead of an environment variable: Make the app read the password from a permission-restricted file and show it is absent from the process environment.
- Encrypt a configuration file with sops: Encrypt only the secret fields of a file with an age key, commit it and show it is decrypted and used at deploy time.
- Rotate the sops key and remove an old recipient: Remove a leaver’s key from the recipients, re-encrypt the files with a new key and prove the old key can no longer decrypt.
- Write a secret to Vault and read it back: Write the database password to the KV engine, read it from the command line and note the version number.
- Move an app’s database password into Vault: Remove the password from the config file, make the app read it from Vault at start-up and write a narrowly scoped policy.
- Replace a static password with short-lived dynamic credentials: Set up the database engine, give the app a one-hour user and show access ends when the lease expires.
- Establish the scope and impact of a leaked key: Work out from the inventory and history what the key accesses, how long it has been exposed and who could see it.
- Revoke and rotate a key and update dependent services: Generate a new key, distribute it to the three services using it, revoke the old one and confirm no service broke.
- Respond end to end to a key pushed to a public repository: Revoke the key, search the usage logs for foreign access, clean history with git filter-repo and explain in the report why that alone is not enough.
About this course
You keep passwords, keys and tokens out of code, catch leaks with gitleaks, store them in Vault and revoke and replace a leaked key.
What you will learn
- Foundations
- Detection
- Safe storage
- Responding to a leak
Prerequisites
Finishing the level 101 courses of the same path, or knowing those topics, is enough.
Lab environment
Lessons run in your own Kali Linux terminal in the browser, connected to a private lab network. Nothing to install.
Frequently asked questions
- Is this course right for my level?
- The course is at level 201; it assumes you know the topics of the lower-level courses.
- Is there anything to install?
- No. Every lesson runs in your own lab environment that opens in the browser.
- How do lessons work?
- Each lesson has 8 to 10 steps and a short quiz. Early steps show the command to type, later steps give less help; if two attempts fail, the solution opens.
- Can I try it for free?
- Yes. The first three lessons of every course are free.