Skip to main content
Style:
Size:

Chapter 7: Secrets Management (Killing the Hardcoded Password)

In the last chapter, we established that your network is likely swarming with Non-Human Identities (NHIs) like automated scripts, APIs, and background services. We also established that they are incredibly dangerous because they rely on static passwords.

The most common, catastrophic mistake developers make is hardcoding secrets.

A developer writes a script that needs to pull data from a server. To make the script work, they type Password = "SuperSecret123!" directly into the code. Then, they upload that code to a repository (like GitHub). Suddenly, anyone who can read the code now holds the keys to your internal network.

We cannot solve this by asking developers to "be more careful." We have to solve it architecturally. We do this using a Secrets Manager.

What is a Secrets Manager?​

Think of a Secrets Manager (like HashiCorp Vault, AWS Secrets Manager, or CyberArk) as a heavily fortified, digital safety deposit box.

Instead of a script having the database password hardcoded inside its own files, the script only has a single, tightly controlled "Vault Token."

  1. The Request: The script wakes up and needs to access the database.
  2. The Knock: The script knocks on the door of the Secrets Manager and presents its Vault Token.
  3. The Verification (Context): The Secrets Manager acts as the bouncer. It checks the token, but it also checks the network context. "Is this script knocking from the correct IP address? Is it the correct time of day?"
  4. The Hand-off: If everything checks out, the Secrets Manager reaches into its digital vault, retrieves the database password, hands it to the script, and logs the entire transaction.

The Holy Grail: Dynamic Secrets (Ephemeral Tokens)​

Retrieving a static password from a vault is a massive improvement over hardcoding it. But it still leaves a risk: what if the password is intercepted during the hand-off?

The gold standard for NHI security is Dynamic Secrets (also known as Ephemeral Tokens).

Instead of storing a permanent password inside the vault, the Secrets Manager creates a brand-new, temporary password on the fly. It hands this temporary password to the script. The script logs into the database. Exactly 60 minutes later, the Secrets Manager automatically deletes that password from the database.

  • The Impact: If an attacker intercepts a Dynamic Secret, it doesn't matter. By the time they figure out what system it belongs to and attempt to use it, the password has already self-destructed. The blast radius is reduced to zero.

Visual Logic: Static Passwords vs. Dynamic Secrets​

Network Micro-segmentation as the Ultimate Fail-safe​

Even with a world-class Secrets Manager generating ephemeral tokens, our Zero Trust architecture demands that we never rely on a single control. We must back it up with Network Security.

If a rogue script attempts to use a legitimate token to access a server it shouldn't, the network firewall must block the traffic at the packet level.

  • Identity-Based Firewalls: Modern firewalls no longer just block IP addresses; they communicate directly with your IAM systems. If the firewall sees a connection attempt from a service account that belongs to the HR department, but the destination is the Engineering codebase, the firewall drops the connection—even if the service account has a perfectly valid Dynamic Secret.

Interactive Simulator: Secrets Manager Simulator​

Compare static hardcoded credentials against dynamic, self-destructing ephemeral secrets:

Secrets Manager Simulator

Compare a hardcoded static password against a Dynamic Ephemeral Secrets Vault.

Database Backup Script

The script requests access to authenticate with the primary database.

Click 'Execute Script' to begin the simulation.

Consultant's Corner: Securing the CI/CD Pipeline​

If you are an IAM consultant, your clients will eventually ask you to secure their CI/CD (Continuous Integration / Continuous Deployment) pipelines. This is the automated machinery that developers use to push new software to production.

CI/CD pipelines (like GitHub Actions, Jenkins, or GitLab CI) are essentially massive, highly privileged Non-Human Identities. They have the power to spin up servers, delete databases, and rewrite firewall rules.

The Rule: Never, under any circumstances, allow developers to store long-lived cloud credentials (like an AWS Access Key that lasts for 5 years) directly inside GitHub or Jenkins.

Instead, force the CI/CD pipeline to use OIDC (OpenID Connect) Federation. This allows GitHub Actions to securely request a temporary, short-lived token from your cloud provider (like AWS or Azure) for the exact 3 minutes it takes to deploy the code, and then the token vanishes. It is the purest implementation of the Control and Impact pillars in the modern developer ecosystem.