Moving API Keys Out of Git and Into HashiCorp Vault

Published 19 Oct 2026 10 min read

The first rule of microservice deployment security is simple yet frequently broken: Never store production secrets in plain text inside your code configurations or your Git repository history.

When setting up a backend pipeline, it's common to rely on a local .env file or hardcode configuration targets inside your infrastructure files. However, the moment your architecture uses public components or scales across automated GitOps triggers, plaintext tokens become massive security liabilities. If a developer accidentally pushes an un-ignored environment file to a public repository, corporate API credentials stand compromised instantly.

To fix this, enterprise environments implement a Zero-Trust Runtime Framework. Here is how we separate security states by using a dedicated HashiCorp Vault instance and the External Secrets Operator (ESO).

The Security Handshake Loop

Instead of embedding tokens, we instruct the cluster to automatically pull variables out of a centralized, secure vault at runtime.

┌──────────────────────┐
│ HashiCorp Vault Pod  │ (Secure System of Record)
└──────────┬───────────┘
           │
           │ 1. Synchronizes keys
           ▼
┌──────────────────────┐
│   External Secrets   │
│    Operator (ESO)    │ (In-Cluster Controller)
└──────────┬───────────┘
           │
           │ 2. Generates dynamic K8s Secret
           ▼
┌──────────────────────┐
│  TypeScript App Pod  │ (Binds keys securely to
│ (process.env.OPENAI) │  in-memory buffers)
└──────────────────────┘

🛠️ Step-by-Step Implementation

1. Mapping the Vault Provider Connection (`secret-store.yaml`)

A Kubernetes cluster and a running HashiCorp Vault service have to be in place first. Helm is how Vault is installed onto the cluster.

We create a resource in our infrastructure toolkit telling the cluster how to securely authenticate and reach out to our Vault engine service:

apiVersion: external-secrets.io/v1beta1
kind: SecretStore
metadata:
  name: vault-backend
spec:
  provider:
    vault:
      server: "http://cluster.local"
      path: "secret"
      version: "v2"
      auth:
        tokenSecretRef:
          name: "vault-token"
          key: "token"

2. Declaring the Variable Fetch Matrix (`external-secret.yaml`)

Instead of duplicating configurations, we declare which exact variables to pull out of the secure Vault store path:

apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: ai-service-secure-vault
spec:
  refreshInterval: "10s" # Continually validates token freshness
  secretStoreRef:
    name: vault-backend
    kind: SecretStore
  target:
    name: ai-app-runtime-secrets # The K8s secret generated automatically
    creationPolicy: Owner
  data:
    - secretKey: OPENAI_API_KEY
      remoteRef:
        key: ai-service-credentials
        property: api_key

3. Binding to the Application Container (`deployment.yaml`)

Our core application deployment file contains no sensitive text strings. It links cleanly to the runtime secret generated by the operator:

env:
  - name: OPENAI_API_KEY
    valueFrom:
      secretKeyRef:
        name: ai-app-runtime-secrets
        key: OPENAI_API_KEY

🧠 The Operational Engineering Advantages

Zero Git Footprint: If your repository is leaked or compromised, your production database credentials and LLM tokens are completely safe. The code contains only target mapping markers, not actual credentials.
Instant Environmental Rotations: If you rotate an API key, you alter it directly inside Vault. Within 10 seconds, the External Secrets Operator updates the cluster. A standard rolling restart (kubectl rollout restart) introduces the new keys with zero service downtime.

Conclusion

True configuration isolation requires removing variables completely from version control. By engineering an automated vault bridge, you achieve a clean separation between your system code infrastructure and corporate security matrices.

Francisco Giraldo