Blog | Why Storing API Secrets in Plain Te...

Understanding the Hidden Threat

Many teams treat a .env or config.yaml file as a convenient place to keep API keys, database passwords, and third‑party tokens. While this approach speeds up local development, it creates a silent attack surface that can be exploited by a single misstep: an accidental commit, a misconfigured CI pipeline, or a compromised developer workstation.

The danger is not just theoretical. Recent supply‑chain analyses show that a single leaked key can enable attackers to:

Harvest user data from SaaS platforms.
Exfiltrate logs and telemetry that reveal internal architecture.
Spawn privileged cloud resources that bypass existing IAM policies.

The lesson is clear: storing secrets in plain text files is a liability, not a convenience.

Why Not Use Plain Text Secrets? – A Technical Breakdown

Below is a concise “why not” checklist that explains the technical shortcomings of plain text secrets:

Version Control Leakage – Git tracks every change. Even after removing a secret, its hash remains in the repository history.
CI/CD Exposure – Build agents often inherit the repository contents verbatim, meaning secrets travel to every build node.
Filesystem Snapshots – Backups, container images, and VM snapshots capture the file system state, persisting secrets beyond their intended lifetime.
Insider Threats – Anyone with read access to the repo can view the secrets without additional scrutiny.
Compliance Violations – Regulations such as GDPR, PCI‑DSS, and HIPAA require encrypted storage of credential material.

The remedy is to move secrets out of the codebase entirely and retrieve them securely at runtime.

Introducing HashiCorp Vault as a Secure Secret Store

Vault provides a centrally managed, audited, and encrypted storage backend. It can dynamically generate short‑lived credentials, rotate them automatically, and enforce fine‑grained ACLs.

# Install Vault (Linux)
curl -fsSL https://apt.releases.hashicorp.com/gpg | sudo apt-key add -
sudo apt-add-repository "deb [arch=amd64] https://apt.releases.hashicorp.com $(lsb_release -cs) main"
sudo apt-get update && sudo apt-get install vault

# Verify installation
vault --version

After installation, start a development server (never use dev mode in production) to experiment:

# Start Vault in dev mode (for local testing)
export VAULT_ADDR='http://127.0.0.1:8200'
vault server -dev -dev-root-token-id="root-token"

With the server running, you can store a secret:

# Write a secret
vault kv put secret/api-key service="payment-gateway" key="sk_live_9x7yZ..."

# Read it back
vault kv get secret/api-key

Integrating Vault with a Python Microservice

The following example demonstrates how a Python Flask app can retrieve an API key at startup without ever touching a static file.

#!/usr/bin/env python3
import os
import hvac
from flask import Flask, jsonify

app = Flask(__name__)

def get_secret():
    client = hvac.Client(url=os.getenv('VAULT_ADDR'), token=os.getenv('VAULT_TOKEN'))
    if not client.is_authenticated():
        raise RuntimeError("Vault authentication failed")
    secret = client.secrets.kv.v2.read_secret_version(path='api-key')
    return secret['data']['data']['key']

API_KEY = get_secret()

@app.route('/status')
def status():
    return jsonify({
        'service': 'payment-gateway',
        'api_key_masked': API_KEY[:4] + '****' + API_KEY[-4:]
    })

if __name__ == '__main__':
    app.run(host='0.0.0.0', port=5000)

Notice the reliance on two environment variables: VAULT_ADDR and VAULT_TOKEN. These variables are injected by the orchestrator (Docker, Kubernetes, etc.) and never written to disk.

Dockerizing the Service with Secure Secret Injection

To keep the container immutable, we pass the Vault token at runtime using Docker’s --env-file flag. The token itself should be stored in a secret manager that the host OS can access securely (e.g., AWS Secrets Manager, GCP Secret Manager, or a local Vault Agent).

# Dockerfile
FROM python:3.11-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install -r requirements.txt
COPY app.py .
EXPOSE 5000
CMD ["python", "app.py"]

# Build the image
docker build -t secure-payment-service .

# Run the container with secrets injected
docker run -d \
  -p 5000:5000 \
  --env VAULT_ADDR=http://host-vault:8200 \
  --env VAULT_TOKEN=$(cat /run/secrets/vault-token) \
  --name payment-service \
  secure-payment-service

The token file /run/secrets/vault-token is supplied by the Docker secret mechanism, which mounts the secret as an in‑memory file, never persisting it to the container’s writable layer.

Automating Secret Rotation with Vault’s Lease System

Instead of a static token, Vault can issue short‑lived dynamic tokens. The following Bash script demonstrates how to renew a token every hour and update the Docker secret without restarting the container.

#!/usr/bin/env bash
VAULT_ADDR="http://127.0.0.1:8200"
ROLE_ID="my-role-id"
SECRET_ID="my-secret-id"

while true; do
  # Request a new token
  NEW_TOKEN=$(curl -s --request POST \
    --data "{\"role_id\":\"$ROLE_ID\",\"secret_id\":\"$SECRET_ID\"}" \
    $VAULT_ADDR/v1/auth/approle/login | jq -r .auth.client_token)

  # Overwrite the Docker secret file (in‑memory)
  echo "$NEW_TOKEN" > /run/secrets/vault-token

  # Wait 55 minutes before next renewal
  sleep 3300
done

Deploy this script as a sidecar container or a systemd service on the host. The main application automatically picks up the refreshed token on the next Vault request.

Security and Best Practices

Never commit any .env, config.yaml, or *.key file to a public or private repository. Enforce a pre‑commit hook that scans for patterns resembling secret material.

# .git/hooks/pre-commit
#!/usr/bin/env bash
if git diff --cached | grep -E 'AKIA|sk_live|password'; then
  echo "Error: Potential secret detected in staged changes."
  exit 1
fi

Enable audit logging in Vault. This provides a tamper‑evident record of every secret read, write, and lease renewal.

# Enable file audit device
vault audit enable file file_path=/var/log/vault_audit.log

Restrict token scopes. Use Vault policies to limit each application to the exact path it needs.

# policies/payment.hcl
path "secret/data/api-key" {
  capabilities = ["read"]
}

Apply the policy when creating the token:

vault token create -policy="payment"

"Treat secrets as code – they deserve the same review, versioning, and audit discipline."

Conclusion

Storing API keys in plain text configuration files may feel expedient, but it introduces a cascade of hidden risks that can compromise an entire organization. By moving secrets into a purpose‑built vault, injecting them at runtime, and automating rotation, you eliminate the most common leakage vectors while gaining auditability and fine‑grained access control.

The transition requires a modest amount of plumbing—installing Vault, updating deployment manifests, and adding a few scripts—but the security payoff is disproportionate. In an era where a single exposed credential can cascade into a full‑scale breach, the cost of “convenient” secret storage is simply too

♥ Enjoyed this article? Use the like banner at the top of the page to let us know — you can like it more than once! Each additional like from the same reader carries a little less weight than the first, so our appreciation scores reflect genuine enthusiasm rather than accidental clicks. Your feedback helps us understand which topics resonate most.

Why Storing API Secrets in Plain Text Config Files Is a Hidden Liability