Quick Recap: API keys, database passwords, encryption keys—these credentials are scattered across your systems. Developers hardcode them. Credentials rotate manually (or never). Someone leaves company, credentials stay active. Vault centralizes credential management. One source of truth. Automatic rotation. Role-based access. Audit trails of who accessed what.
Opening Hook
Your ML pipeline needs a database password.
A developer hardcodes it: DB_PASSWORD="super_secret_123" in the code.
Code gets committed to Git. Password is now in version control history forever.
Someone clones the repo. Password is visible. Contractor leaves the company. Still has the password in their local clone.
Password needs to change. Do you search every script? Every config file? Every developer's laptop? Nobody knows where all copies are.
Two years later, that "super_secret_123" is still being used somewhere. You never knew it existed.
This is what happens without secrets management.
Vault changes it: Single source of truth. Automatic rotation. Access control. Audit logs.
Password changes once in Vault. All systems automatically use new password. Old password stops working.
Why This Pattern Matters
Credentials are everywhere:
API keys for external services
Database passwords
Encryption keys
SSH keys
OAuth tokens
Each needs:
Storage (secure, not in code)
Access control (who can see it)
Rotation (change regularly)
Audit trail (who accessed it)
Most teams do none of this. Credentials hardcoded. Shared via Slack. Stored in spreadsheets. Rotated manually (or never).
Why this matters in BFSI: Hardcoded credentials in production code = regulatory violation. Credential breach = audit finding. Unrotated credentials = maximum exposure window.
Vault handles all of it. Centralizes secrets. Controls access. Rotates automatically. Logs everything.
How Vault Works
Three Core Concepts:
1. Secret Storage
Vault is encrypted database for secrets
Stores: passwords, API keys, tokens, encryption keys
Everything encrypted at rest
Only accessible through Vault API
2. Access Control (RBAC)
Define roles: Developer, DevOps, ML Engineer
Assign permissions to roles: Which secrets can they access?
Users get roles, not direct secret access
Audit log tracks every access
3. Secret Rotation
Vault generates new secret
Updates system using it
Invalidates old secret
Automatic on schedule (every 30 days, 90 days, etc)
Building Secrets Management with Vault
Step 1: Initialize Vault and Create Secrets
Store credentials in Vault.
python
import hvac
# Connect to Vault
client = hvac.Client(url='http://vault.example.com:8200')
# Authenticate (in production: use proper auth method)
client.auth.userpass.login(username='admin', password='vault_pass')
# Store database password
secret_data = {
'username': 'db_user',
'password': 'super_secret_db_password_123'
}
# Write to Vault
client.secrets.kv.v2.create_or_update_secret_version(
path='database/prod',
secret_data=secret_data
)
print("Database secret stored in Vault")Step 2: Define Roles and Permissions
Control who can access what.
python
# Create a role for ML engineers
role_policy = """
path "database/*" {
capabilities = ["read", "list"]
}
path "api/fraud-detection/*" {
capabilities = ["read"]
}
path "auth/token/renew-self" {
capabilities = ["update"]
}
"""
# Write policy to Vault
client.sys.create_or_update_policy(
name='ml-engineer',
policy=role_policy
)
print("ML Engineer role created")
print("Permissions: Read database secrets, read fraud-detection API secrets")Step 3: Authenticate and Retrieve Secrets
Applications authenticate to Vault. Get secrets. Use them.
python
def get_database_password():
"""
Retrieve database password from Vault.
Never hardcode credentials.
"""
# Authenticate (using service identity, not hardcoded password)
client = hvac.Client(url='http://vault.example.com:8200')
# Use JWT/OIDC/AppRole in production
# NOT username/password
client.auth.jwt.jwt_login(
role='ml-app',
jwt='jwt_token_from_k8s'
)
# Retrieve secret
secret = client.secrets.kv.v2.read_secret_version(
path='database/prod'
)
username = secret['data']['data']['username']
password = secret['data']['data']['password']
return username, password
# Use it
db_user, db_pass = get_database_password()
# Connect to databaseStep 4: Automatic Secret Rotation
Vault rotates secrets on schedule.
python
# Enable database secret engine
client.sys.enable_secrets_engine(
backend_type='database',
path='database'
)
# Configure database connection
db_config = {
'plugin_name': 'postgresql-database-plugin',
'allowed_roles': 'readonly,readwrite',
'connection_url': 'postgresql://{{username}}:{{password}}@db.example.com:5432/mydb',
'username': 'vault_admin',
'password': 'vault_admin_password'
}
client.secrets.database.configure(
name='postgresql',
plugin_name='postgresql-database-plugin',
allowed_roles='readonly,readwrite',
connection_url='postgresql://{{username}}:{{password}}@db.example.com:5432/mydb',
username='vault_admin',
password='vault_admin_password'
)
# Create role with automatic password rotation
client.secrets.database.create_role(
name='readonly',
db_name='postgresql',
creation_statements='CREATE ROLE "{{name}}" WITH LOGIN PASSWORD \'{{password}}\' VALID UNTIL \'{{expiration}}\';',
default_ttl='1h',
max_ttl='24h'
)
print("Database passwords rotate every 1 hour automatically")Step 5: Audit Logging
Track every access to secrets.
python
# Enable audit logging
client.sys.enable_audit_backend(
backend_type='file',
path='file',
options={
'file_path': '/var/log/vault-audit.log'
}
)
# Query audit logs
audit_logs = client.sys.read_audit_backend_config(
path='file'
)
print("Audit logging enabled")
print("All secret access logged with timestamp, user, path, action")BFSI-Specific Patterns
Pattern 1: Database Password Rotation
Production database password changes every 30 days. Vault handles it.
python
# Configure for 30-day rotation
rotation_config = {
'ttl': '720h', # 30 days
'max_ttl': '720h'
}
# New password generated automatically every 30 days
# Old password invalidated
# All applications using it updated in real-timeWhy this matters: If password leaked, attacker can only use it for 30 days max. Standard practice in financial services.
Pattern 2: Separation of Secrets by Environment
Development, staging, production have different secrets. Same code, different credentials.
python
# Code reads from Vault path, not hardcoded environment
secret_path = os.getenv('VAULT_PATH') # Set by deployment
# Could be: database/dev, database/staging, database/prod
client.secrets.kv.v2.read_secret_version(path=secret_path)Why this matters: Same app code. Different secrets based on where it's deployed. No environment-specific hardcoding.
Pattern 3: Revoke Access When People Leave
Employee leaves company. One API call revokes all their access.
python
# When employee departs
employee_id = 'john.doe'
# Revoke all tokens issued to this user
client.auth.token.revoke_self_issued(
accessor=employee_id
)
# Delete their Vault role
client.sys.delete_policy(name=employee_id)
print(f"All access revoked for {employee_id}")Why this matters: Former employees can't access production. Immediate, no manual password changes needed.
Common Mistakes
Mistake 1: Hardcoding "Secret" Passwords
❌ DB_PASSWORD="super_secret_123" in code ✅ DB_PASSWORD = vault.get_secret("database/prod")
Hardcoded = permanent breach if code leaks.
Mistake 2: Sharing Secrets via Chat/Email
❌ "Here's the prod password: xyz123" in Slack ✅ Grant them Vault access role instead
Shared secrets are untrackable. Rotation impossible.
Mistake 3: Manual Rotation
❌ Update password in script, notify teams, hope they update ✅ Configure Vault to rotate automatically every 30 days
Manual = some systems miss update. Old password stays active somewhere.
Mistake 4: No Audit Logs
❌ "Who accessed the API key?" Can't answer. ✅ Vault logs every access with timestamp, user, action
Audit logs are required for regulatory compliance.
Mistake 5: Same Secret Across Environments
❌ Production and development use same database password ✅ Different secrets for dev/staging/prod
Production breach shouldn't affect development.
Looking Ahead: 2026-2030
2026: Vault becomes standard infrastructure
Most institutions deploy secrets management
Hardcoded credentials become audit finding
Automatic rotation expected
2027-2028: Zero-standing-secrets emerges
Credentials valid for minutes, not days
Request access, get temporary credential, credential expires
Reduces window of exposure dramatically
2028-2029: Hardware security modules (HSM)
Master keys stored in hardware, not software
Cryptographic operations happen in HSM
Highest security tier
2030: Credential-less architecture
Applications prove identity without secrets
Cryptographic signatures replace passwords
Humans never touch credentials
HIVE Summary
Key takeaways:
Vault centralizes secrets. One source of truth. No hardcoding. No sharing via chat.
RBAC controls access. ML Engineer role gets only ML secrets. Database admin role gets only database secrets. Audit logs track every access.
Automatic rotation. Password changes every 30 days without human intervention. Old password immediately invalid.
Separation of concerns. Development, staging, production have different secrets. Same code. Different credentials.
Revoke immediately. Employee leaves. One API call revokes all their access. No manual password changes needed.
Start here:
If hardcoding secrets now: Deploy Vault this month. Move first secret to Vault. Test it. Then migrate others.
If sharing via chat: Stop. Create Vault roles. Grant access roles instead of sharing secrets.
If rotating manually: Configure automatic rotation. Every 30-90 days. Set and forget.
Looking ahead (2026-2030):
Vault becomes regulatory requirement (not optional)
Zero-standing-secrets architecture (credentials valid minutes, not days)
Hardware security modules (HSM) for highest security
Credential-less architecture (cryptographic identity)
Open questions:
How often should secrets rotate? 30 days? 7 days? Real-time?
What if application can't restart immediately after secret rotation?
How to handle certificate rotation at scale?
Jargon Buster
Secret: Any credential that grants access (password, API key, encryption key, token). Why it matters in BFSI: Must be protected, rotated, audited.
RBAC (Role-Based Access Control): Users get roles. Roles get permissions. Different roles access different secrets. Why it matters in BFSI: Fine-grained access control. Developer doesn't see production database password.
Secret Rotation: Changing secrets on schedule (every 30 days, 90 days, etc). Old secret invalidated. Why it matters in BFSI: Limits exposure window. If password leaked, attacker can only use it until next rotation.
Audit Trail: Log of every access to secrets. Who accessed what, when. Why it matters in BFSI: Regulatory requirement. Proves who accessed credentials.
TTL (Time To Live): How long a credential is valid before expiring. Why it matters in BFSI: Secret valid 24 hours. After 24 hours, must request new one.
Service Identity: Application proves identity without passwords (JWT, AppRole, mTLS). Why it matters in BFSI: Applications don't need hardcoded credentials to authenticate.
HSM (Hardware Security Module): Physical device storing encryption keys. Why it matters in BFSI: Highest security tier. Master keys never leave hardware. Cryptographic operations happen in HSM.
Zero-Trust: Assume nothing is trusted. Verify everything. Every access requires authentication. Why it matters in BFSI: Secrets never hardcoded. Always requested and validated.
Fun Facts
On Credential Sprawl: A major bank audited their systems and found 47 different database passwords in use across production. Some 3+ years old. When they tried to retire one password, systems crashed (forgotten dependency). When they activated Vault and configured automatic rotation, they discovered the sprawl was actually 12 unique passwords (others were copies). Cost of mess: 2 months of migration work. Lesson: Centralize early.
On Rotation Benefits: A fintech experienced an API key compromise. Before Vault: searched logs for 2 weeks trying to understand scope of exposure. After Vault: rotation happened automatically 6 hours later (next scheduled rotation). Exposed window: 6 hours instead of 2 weeks. Lesson: automatic rotation limits damage window dramatically.
For Further Reading
HashiCorp Vault Documentation (HashiCorp, 2025) - https://www.vaultproject.io/docs - Official guide for setup, RBAC, and secret rotation.
Secrets Management Best Practices (NIST SP 800-56C, 2024) - https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56C.pdf - Federal guidance on credential lifecycle management.
Zero-Trust Security Architecture (NIST SP 800-207, 2024) - https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-207.pdf - Modern security framework requiring secrets management.
Financial Services Credential Management (Federal Reserve, 2024) - https://www.federalreserve.gov/supervisionreg/srletters/sr2410.pdf - Regulatory expectations for managing API keys and passwords.
Vault Enterprise for Financial Services (HashiCorp, 2025) - https://www.hashicorp.com/resources/vault-enterprise-financial-services - Enterprise deployments in regulated environments.
Infographic Prompts
[See separate document: Infographic Prompts - Week 8 Wednesday]
Next up: Week 9 Sunday explores why model lifecycle differs from software lifecycle. Models degrade even when code stays frozen. Understanding this changes how you manage production AI.
This is part of our ongoing work understanding AI deployment in financial systems. If you've migrated from hardcoded credentials to Vault and automated rotation, share your migration timeline and lessons learned.
— Sanjeev @ AITechHive.com