Articles

Secrets Management: Stop Leaking API Keys

March 15, 2026 7 min read

Secrets management is the practice of securely storing and accessing sensitive information like API keys, passwords, and certificates, preventing developers from accidentally exposing them in code or configuration files.

Imagine you’re building a web application that needs to interact with a third-party service, like a payment gateway or a social media API. To do this, you’ll need an API key. This key is essentially a password for your application to prove its identity to the service. If this key falls into the wrong hands, an attacker could impersonate your application, potentially making fraudulent transactions or accessing user data.

Here’s a simplified, but functional, example of how a web server might use a secret to authenticate with an external API. This Python Flask snippet demonstrates the problem before we get to the solution:

from flask import Flask, request
import requests
import os

app = Flask(__name__)

# THIS IS THE BAD WAY: Hardcoded secret
# NEVER do this in production!
API_KEY = "sk_test_very_secret_key_12345"
EXTERNAL_SERVICE_URL = "https://api.example.com/v1/charge"

@app.route('/charge', methods=['POST'])
def charge_customer():
    data = request.get_json()
    customer_id = data.get('customer_id')
    amount = data.get('amount')

    if not customer_id or not amount:
        return {"error": "Missing customer_id or amount"}, 400

    headers = {
        "Authorization": f"Bearer {API_KEY}",
        "Content-Type": "application/json"
    }

    payload = {
        "customer": customer_id,
        "value": amount
    }

    try:
        response = requests.post(EXTERNAL_SERVICE_URL, headers=headers, json=payload)
        response.raise_for_status() # Raise an exception for bad status codes
        return response.json(), 200
    except requests.exceptions.RequestException as e:
        return {"error": f"Failed to process charge: {e}"}, 500

if __name__ == '__main__':
    app.run(debug=True)

In this code, API_KEY = "sk_test_very_secret_key_12345" is directly embedded. If this code is accidentally pushed to a public GitHub repository, anyone can see and use your API key. This is a developer’s nightmare.

The core problem secrets management solves is the separation of sensitive credentials from application code and configuration. Instead of embedding secrets, applications should retrieve them from a secure, centralized location at runtime.

The mental model for secrets management is like a digital safe. Your application needs to access the contents of the safe (the secrets) to do its job. It doesn’t own the contents; it just needs to read them when necessary. The safe itself is protected by robust access controls, ensuring only authorized entities (your application instances) can open it.

There are several common approaches and tools for managing secrets:

  1. Environment Variables: The simplest method. Secrets are injected into the application’s environment.

    • How it works: The operating system or container orchestration platform provides environment variables to the running process. The application reads these variables.
    • Example (Python):
      import os
api_key = os.environ.get("EXTERNAL_API_KEY")
    • Fixing the previous example:
      # ... (imports and app setup)
API_KEY = os.environ.get("EXTERNAL_API_KEY") # Read from environment
if not API_KEY:
    raise ValueError("EXTERNAL_API_KEY environment variable not set")
# ... (rest of the charge_customer function)
    • Deployment: When deploying your application (e.g., on Kubernetes, AWS ECS, or even a simple server), you’d configure the EXTERNAL_API_KEY environment variable with the actual secret value. For instance, on Linux: export EXTERNAL_API_KEY="sk_test_very_secret_key_12345".

  2. Configuration Files (Encrypted): Storing secrets in a separate file, often encrypted, that the application can decrypt.

    • How it works: A tool encrypts the secret file. The application, or a service it interacts with, has the decryption key to read the contents.
    • Example Tool (SOPS): sops (Secrets Operations) by Mozilla is a popular tool. You can encrypt a JSON or YAML file containing secrets.
      # Encrypt a file named secrets.yaml
sops --encrypt --in-place secrets.yaml
      The secrets.yaml might look like:
      external_api_key: "sk_test_very_secret_key_12345"
    • Application Access: The application would need sops installed and the decryption key (often managed via cloud KMS or GPG) to read the file at runtime.
      import subprocess
import json

def get_secret_from_sops(key_name):
    try:
        # Assumes sops is in PATH and decryption key is available
        result = subprocess.run(
            ['sops', '--decrypt', 'secrets.yaml'],
            capture_output=True,
            text=True,
            check=True
        )
        secrets_data = json.loads(result.stdout)
        return secrets_data.get(key_name)
    except (subprocess.CalledProcessError, json.JSONDecodeError) as e:
        print(f"Error decrypting secrets: {e}")
        return None

API_KEY = get_secret_from_sops("external_api_key")
if not API_KEY:
    raise ValueError("Could not retrieve external_api_key from secrets.yaml")

  3. Dedicated Secrets Management Systems: Services specifically built for managing secrets, offering features like rotation, auditing, and fine-grained access control.

    • Examples: HashiCorp Vault, AWS Secrets Manager, Google Cloud Secret Manager, Azure Key Vault.
    • How it works: Applications authenticate with the secrets manager (often using service accounts or IAM roles) and request secrets by name. The secrets manager returns the secret value.
    • Example (HashiCorp Vault CLI):
      # Assuming vault CLI is configured and authenticated
vault kv get -field=api_key secret/data/myapp/external_api
    • Application Integration: Most secrets managers provide SDKs for various languages.
      # Example using a hypothetical Vault Python client
from hvac import Client

client = Client(url='https://your-vault-address.com')
# Assuming client is authenticated (e.g., via environment variables or token)
response = client.secrets.kv.v2.read_secret_version(
    path='secret/data/myapp/external_api'
)
API_KEY = response['data']['data']['api_key']

  4. Kubernetes Secrets: For applications running on Kubernetes, this is the native way.

    • How it works: Secrets are stored as Kubernetes Secret objects, which are base64 encoded. They can be mounted as volumes or injected as environment variables into pods.
    • Example (secret.yaml):
      apiVersion: v1
kind: Secret
metadata:
  name: my-api-secrets
type: Opaque
data:
  EXTERNAL_API_KEY: c2tf... # base64 encoded value of "sk_test_very_secret_key_12345"
    • Deployment:
      kubectl apply -f secret.yaml
    • Application Access (as environment variable):
      apiVersion: v1
kind: Pod
metadata:
  name: my-app-pod
spec:
  containers:
  - name: my-app-container
    image: my-app-image
    env:
    - name: EXTERNAL_API_KEY
      valueFrom:
        secretKeyRef:
          name: my-api-secrets
          key: EXTERNAL_API_KEY
    • Application Code: The Python code would be the same as the environment variable example: API_KEY = os.environ.get("EXTERNAL_API_KEY"). Kubernetes handles injecting it.

  5. Cloud Provider IAM Roles/Service Accounts: Many cloud providers allow you to grant permissions directly to compute instances or containers to access secrets stored in services like AWS Secrets Manager or GCP Secret Manager, without needing explicit credentials for the secrets store itself.

    • How it works: Your application runs with an identity (e.g., an EC2 instance profile or Kubernetes service account) that has been granted secretsmanager:GetSecretValue permissions. The SDK then uses this identity to fetch the secret.
    • Example (AWS SDK for Python - Boto3):
      import boto3
import json

secrets_client = boto3.client('secretsmanager')

def get_secret_from_aws(secret_name):
    try:
        get_secret_value_response = secrets_client.get_secret_value(
            SecretId=secret_name
        )
        if 'SecretString' in get_secret_value_response:
            secret = get_secret_value_response['SecretString']
            return json.loads(secret) # Assuming secret is JSON
        else:
            # Handle binary secrets if necessary
            pass
    except Exception as e:
        print(f"Error retrieving secret {secret_name}: {e}")
        return None

secret_data = get_secret_from_aws("my/app/secrets")
if secret_data:
    API_KEY = secret_data.get("EXTERNAL_API_KEY")
else:
    API_KEY = None

if not API_KEY:
    raise ValueError("Could not retrieve EXTERNAL_API_KEY from AWS Secrets Manager")

The most surprising thing about secrets management is that it’s not just about hiding secrets, but about controlling access to them. A secret can be stored in plain text, but if only your application has the permission to read it, it’s effectively managed. Conversely, a secret encrypted with a key that’s also checked into your Git repository is still a massive leak.

The core lever you control with secrets management is the identity your application uses to authenticate with the secrets store. Whether it’s a Kubernetes service account, an AWS IAM role, a Vault token, or an API key for a secrets manager itself, this identity is what grants access. The principle of least privilege is paramount: the identity should only have permission to fetch the specific secrets it needs, and nothing more.

Once you have a robust secrets management system in place, the next challenge you’ll often face is managing the lifecycle of those secrets, particularly secret rotation.

Want structured learning?

Take the full Cryptography course →