> ## Content Index
> Fetch the complete content index at: https://stalin-pereira.com/llms.txt
> Use this file to discover other available public pages before exploring further.

# Injecting Secrets at Runtime: Vault vs Environment Variables
- URL: https://stalin-pereira.com/injecting-secrets-at-runtime-vault-vs-environment-variables/
- Published: 2026-01-05T11:24:00.000Z
- Updated: 2026-10-16T19:08:17.000Z
- Description: Proper use of Vault/AWS Secrets vs committing keys to Git
- Author: Stalin Pereira
- Tags: DevOps

**I Found Your House Keys**

They were under the doormat. Along with your bank PIN.

- **The Convenience** — It's easy for your family to get in if the key is always there.
- **The Vulnerability** — It is also easy for literally anyone else to get in.

## The 'Sticky Note' Password

We all know that one person who writes passwords on their monitor.

- **Visible to All** — Cleaners, visitors, and contractors can see it.
- **Hard to Change** — If you change the password, you have to write a new note.

## This is Your App's Security

Hardcoding API keys is the digital equivalent of the sticky note.

- **The Artifact** — Keys committed to Git history stay there forever.
- **The Exposure** — Anyone with read access to the repo owns your infrastructure.

## The Old Way: .env Files

Better than hardcoding, but still a security headache.

- **Sprawl** — Secrets are scattered across developer laptops and CI/CD pipelines.
- **Leakage Risk** — One accidentally public S3 bucket or log file exposes everything.

## The Fix: Runtime Injection

Stop storing secrets. Start fetching them only when needed.

- **The Vault** — A centralized, secure server (like HashiCorp Vault or AWS Secrets Manager).
- **Just-in-Time** — The app asks for the key *only* when it starts up.

## Concept: Identity vs. Secrets

Your application doesn't need a password; it needs an ID.

- **Authentication** — The app proves its identity (e.g., IAM Role, K8s Service Account).
- **Authorization** — The Vault checks: 'Is this app allowed to open the database?'

## Deep Dive: The Data Flow

How the secret moves without touching a hard drive.

- **Step 1: Request** — App boots -> Authenticates with Vault via IAM/Cert.
- **Step 2: Inject** — Vault returns the secret directly into the process memory.
- **Step 3: Disappear** — The secret never touches the disk or the Git repo.

## Advanced: Dynamic Secrets

The ultimate security feature: Keys that self-destruct.

- **On-Demand Creation** — Vault creates a unique DB username/password for that specific request.
- **Automatic Revocation** — The credentials expire automatically after 30 minutes (TTL).

## The 'Secret Zero' Problem

If you need a token to fetch secrets, where do you store the token?

- **The Paradox** — You can't lock the key inside the box it opens.
- **The Solution** — Use Trusted Platforms (AWS IAM, Kubernetes OIDC) to bootstrap trust.

## Architecture: The Sidecar

Don't make developers write security code.

- **Agent Injection** — A sidecar container fetches secrets and writes them to a shared memory volume.
- **Zero Code Change** — The main app just reads a file at `/etc/secrets/db_pass`. It doesn't know Vault exists.

## Why Business Leaders Care

It's not just tech; it's insurance against catastrophe.

- **Audit Trails** — You know exactly who accessed the production database and when.
- **Instant Kill Switch** — Suspect a breach? Revoke all active leases instantly.

## Summary: Sleep Soundly

Move from 'Hoping for the best' to 'Verify everything'.

- **No More Leaks** — No secrets in Git. No secrets in Dockerfiles.
- **Automated Rotation** — Credentials change before hackers can crack them.

---

Are your secrets rotating, or are they stagnant?