Secrets management

Secrets are sensitive values such as API keys, database passwords, and encryption keys. Managing them securely is critical: leaked secrets can lead to data breaches, unauthorized access, or complete compromise of systems.

Local Development

In local development, secrets need to be accessible for developers while still kept out of source control.

Laravel / Docker – use a .env file for local settings. A .env.example file should be committed to Git to document required keys, but each developer maintains their own .env file outside version control.
.NET projects – secrets are typically provided via environment variables or local configuration files that are ignored by Git.
Docker Compose – environment variables may be defined in a .env file or injected at runtime, but must never be hardcoded directly into docker-compose.yml or baked into images.

When onboarding, developers should receive instructions on which secrets are needed and how to obtain them securely (for example via a password manager or by requesting them from the project lead).

Production

In production, secrets must be handled with the highest level of security. Unlike local development, where flexibility is key, production systems face real risks from attackers, misconfiguration, and accidental leaks.

Centralized Secret Stores

Secrets should be stored in a managed service rather than scattered across servers.

Azure Key Vault is the preferred option for Azure-hosted projects. Secrets are stored centrally, versioned, and access can be controlled per-application or per-role.
If another cloud provider is used (AWS, Google Cloud), their secret management services (AWS Secrets Manager, GCP Secret Manager) can fulfill the same role.

Application Integration

Applications should fetch secrets at runtime or receive them through environment variables injected by the platform. This ensures that secrets are never baked into code or configuration files inside source control. Examples:

An Azure App Service can inject secrets directly from Key Vault into environment variables.
A Docker container in production should read secrets from the orchestrator (Portainer, Kubernetes, etc.), not from an .env file copied during build.

Access Control

Principle of least privilege – only the application and a minimal set of administrators should have access to production secrets.
Audit trails – secret stores like Azure Key Vault provide logs of who accessed what, which is essential for compliance and incident response.
No shared credentials – each system or integration should have its own key or token. Avoid one password for everything.

Rotation and Renewal

Secrets should be rotated proactively, not only after an incident. Many providers support automatic rotation.
Certificates (TLS/SSL) must be renewed before expiration, automating this (Let’s Encrypt or Key Vault integration) prevents outages.
When rotating, coordinate between environments to avoid downtime (e.g. deploy new secret before invalidating the old one).