Secrets Management: Vault, AWS Secrets, GitHub Secrets – Operational Guide • Meteora Web Agency

If your database password is in a .env file on the server, it's not a matter of if it will be exposed, but when. We see it every day in projects that come to us for review: hardcoded API keys, plain-text tokens in repos, production credentials scattered across dozens of places. It doesn't take a sophisticated hacker – a misconfigured CI build or a public repository can trigger data leaks costing millions.

We, at Meteora Web, have been working with servers and DevSecOps pipelines for years. We've seen the chaos that comes with no secrets management strategy. And we've built solutions using HashiCorp Vault, AWS Secrets Manager, and GitHub Secrets that actually work. This guide is a deep dive into secrets management: tools, commands, real-world examples. If you need the fundamentals of cloud security, start with our Pillar Guide on Cloud Security and DevSecOps.

Why Secrets Are the Achilles' Heel of Cloud Security

A secret is anything that should not be public: database passwords, OAuth tokens, SSH keys, certificates, API keys. The problem is that in modern cloud environments secrets multiply: microservices, containers, CI/CD, serverless. Managing them manually is a nightmare.

Common mistakes we've encountered dozens of times:

.env files in repositories (even private ones – one distracted collaborator is enough)
Passwords hardcoded in environment variables inside Dockerfiles
Service tokens shared via chat or email
No automatic rotation
Database backups with credentials in plain text

The cost? Not only financial: the time for an incident response multiplies tenfold when you don't know where secrets are. And customer trust vanishes in an instant.

The solution is a centralized secrets management system: a single control panel with tracked access, automatic expiration, and rotation. Three leading tools today are HashiCorp Vault, AWS Secrets Manager, and GitHub Secrets. Each has its place. Let's dive in.

HashiCorp Vault: The Central Control Point

Vault is much more than a password drawer. It's a system that can generate secrets on the fly (dynamic secrets), create them with expiration, revoke them, and encrypt data in transit via the Transit Engine. We use it on multi-cloud and Kubernetes projects.

Quick Dev Setup

# Download and start Vault in development mode (NEVER in production without TLS and HA)
vault server -dev

The server returns a Root Token and Unseal Key.

Writing and Reading a Secret

export VAULT_ADDR='http://127.0.0.1:8200'
export VAULT_TOKEN='your-token'

# Write a secret at path /secret/production/db
vault kv put secret/production/db username=dbuser password=S3cur3P@ss

# Read the secret
vault kv get secret/production/db

Dynamic Database Secrets (PostgreSQL)

Vault can create temporary database credentials valid only for the needed time. Example with PostgreSQL:

# Enable the database secrets engine
vault secrets enable database

# Configure PostgreSQL connection
vault write database/config/postgresql-db \
    plugin_name=postgresql-database-plugin \
    allowed_roles="*" \
    connection_url="postgresql://{{username}}:{{password}}@host:5432/db" \
    username="vault_admin" \
    password="admin_password"

# Create a role that generates credentials valid for 1 hour
vault write database/roles/dynamic-reader \
    db_name=postgresql-db \
    creation_statements="CREATE USER \"{{name}}\" WITH PASSWORD '{{password}}' VALID UNTIL '{{expiration}}'; GRANT SELECT ON ALL TABLES IN SCHEMA public TO \"{{name}}\";" \
    default_ttl="1h" \
    max_ttl="24h"

# Request credentials (your CI/CD can do this)
vault read database/creds/dynamic-reader

Result: disposable passwords, automatic revocation at expiry. No more static credentials in config files.

Transit Engine for Data Encryption

Vault can serve as a centralized encryption service. Your code sends data to encrypt/decrypt without ever seeing the keys.

vault secrets enable transit
vault write -f transit/keys/my-key

# Encrypt
vault write transit/encrypt/my-key plaintext=$(base64 <<< "sensitive data")
# Decrypt
vault write transit/decrypt/my-key ciphertext="vault:v1:..."

Why it pays off? A single point for key rotation without updating every application.

User link: Official HashiCorp Vault Documentation

AWS Secrets Manager: The Native AWS Manager

If you live inside AWS, Secrets Manager is the most integrated choice. It handles automatic rotation for RDS, Redshift, DocumentDB, and can be called via SDK without managing a Vault cluster.

Creating a Secret from CLI

aws secretsmanager create-secret \
    --name prod/db \
    --secret-string '{"username":"dbuser","password":"S3cur3P@ss"}'

Retrieving a Secret in Lambda (Python)

import boto3
import json
from botocore.exceptions import ClientError

def get_secret():
    secret_name = "prod/db"
    region_name = "eu-west-1"
    session = boto3.session.Session()
    client = session.client(
        service_name='secretsmanager',
        region_name=region_name
    )
    try:
        response = client.get_secret_value(SecretId=secret_name)
        secret = json.loads(response['SecretString'])
        return secret
    except ClientError as e:
        raise e

Automatic Rotation

Secrets Manager can invoke a Lambda function to rotate the password every X days. AWS provides ready-made templates for RDS. We recommend enabling rotation immediately after creating the secret.

aws secretsmanager rotate-secret \
    --secret-id prod/db \
    --rotation-lambda-arn arn:aws:lambda:... \
    --rotation-rules AutomaticallyAfterDays=30

When to use it? For workloads entirely on AWS, needing native integration and without the complexity of Vault.

User link: AWS Secrets Manager User Guide

GitHub Secrets: Safeguarding CI/CD Pipeline Secrets

The #1 enemy of CI/CD pipelines is hardcoded secrets in YAML files. GitHub Secrets (and encrypted environment variables) let you inject credentials into workflows without ever exposing them in code.

Management Levels

Repository secrets: visible to all workflows in the repo.
Environment secrets: bound to a specific environment (prod/staging) – extra protection with required reviewers.
Organization secrets: shared across multiple repos, accessible only to authorized teams.

Example GitHub Actions Workflow

name: Deploy to production
on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    environment: production
    steps:
      - uses: actions/checkout@v4
      - name: Deploy
        run: |
          echo "Connecting to server..."
          ssh user@${{ secrets.DEPLOY_HOST }} << 'EOF'
            docker pull myapp:latest
            docker compose up -d
          EOF
        env:
          DB_PASSWORD: ${{ secrets.DB_PASSWORD }}

Important: secrets are masked in logs, but avoid intentionally printing them. Always use secrets.KEY, never plain strings.

Best Practices

Organize secrets by environment (dev, staging, prod) with separate permissions.
Never reuse the same secret across multiple environments.
For more complex pipelines, integrate with Vault (e.g., vault-action) for dynamic secrets.

User link: GitHub Docs – Using secrets in GitHub Actions

Hybrid Strategy: When to Use What?

In practice, no single tool suffices alone. Here's our mental model:

Scenario	Recommended Tool
Multi-cloud / on-premise + cloud	Centralized Vault
All-in on AWS	AWS Secrets Manager + Vault for advanced dynamic secrets
CI/CD on GitHub	GitHub Secrets + Vault for temporary operations
Microservices on Kubernetes	Vault + CSI driver for automatic injection

Golden rule: never hardcode, never share, never skip rotation. Every secret should have an expiration.

In Summary – What to Do Now

Full audit: search all repositories, servers, and backups for plaintext secrets. Tools like truffleHog or git-secrets help.
Choose your manager: for new projects, start with Vault if multi-cloud or need dynamic secrets; otherwise AWS SM.
Enable rotation: don't postpone. Set automatic rotation every 30 or 90 days.
Integrate with CI/CD: move all pipeline secrets into GitHub Secrets (or equivalent for GitLab, Bitbucket).
Train the team: a single member committing a token costs more than half a day of remediation.

Secrets are the blood of your infrastructure. Treat them as such. And if you need help setting up the right system, moving from chaos to a managed environment – we at Meteora Web do it every day. Start with the Pillar Guide on Cloud Security and DevSecOps and, if you like, reach out to us.