1. The Problem
A developer accidentally committed Azure Storage Account access keys into a public Git repository, exposing cloud data lake containers to unauthorized access.
2. What I Initially Thought
3. What I Learned
Zero Trust Security requires storing credentials in hardware-backed Key Vaults and authenticating services using passwordless Managed Identities (MSI).
4. What I Built
Azure Key Vault integration module for Airflow (`Airflow KeyVault Secret Backend`) and Azure Managed Identity authentication for ADLS Gen2 access.
from azure.identity import DefaultAzureCredential
from azure.keyvault.secrets import SecretClient
# Passwordless Managed Identity Authentication!
credential = DefaultAzureCredential()
secret_client = SecretClient(vault_url="https://kv-datapulse.vault.azure.net/", credential=credential)
db_password = secret_client.get_secret("prod-db-password").value5. The Experiment
Hardcoded connection strings and storage keys in configuration files and environment scripts.
Migrated all secret resolution to Azure Key Vault via Managed Identity authentication.
Zero plain-text secrets exist in codebase or Git history; secret access audited automatically via Azure Key Vault logs.
6. What Went Wrong
Managed Identity permissions were initially granted `Owner` role on Key Vault. Applied Least Privilege policy to restrict role to `Key Vault Secrets User`.
7. Engineering Decision & Trade-offs
Configured Airflow Key Vault Secrets Backend so Airflow connections resolve dynamically from Key Vault at runtime.
8. What I Would Do Differently in Production
Implement automated git pre-commit hooks (e.g. `gitleaks` or `trufflehog`) to block commits containing API keys or private certificates.
Questions I Can Now Answer Confidently in an Interview:
- Why are passwordless Managed Identities preferable to storage account access keys in Azure?
- How do Airflow Secret Backends dynamically resolve connection secrets at runtime?
- What steps should you take immediately if a production database key is committed to Git?