Invos

06_secrets_management

3 min read

Secrets Management Policy

This document defines the company-wide policy for managing secrets. Proper secrets management is a cornerstone of our security posture. This policy applies to all employees and contractors.

The technical, platform-specific implementation for Cloudflare is detailed in 04_infrastructure_devops/04_managing_cloudflare_secrets.md.

What is a Secret?

A secret is any piece of information that grants access to a system or to sensitive data. This includes, but is not limited to:

  • Passwords and passphrases
  • API keys and tokens
  • Private encryption keys (e.g., TLS, JWT signing keys)
  • Database connection strings
  • Environment variables containing sensitive information

If you have to ask if it’s a secret, treat it as a secret.

Core Policies

1. Never Hardcode Secrets in Git

  • Under no circumstances should a secret ever be committed to a Git repository, even if the repository is private.
  • History can be rewritten, but it is difficult and prone to error. Assume that anything committed to Git is potentially exposed.

2. Never Share Secrets in Plain Text

  • Do not share secrets via insecure channels like Slack, email, or other messaging platforms.
  • These platforms often store messages indefinitely and are not designed for secure secret sharing.

3. Use Approved Secrets Management Tools

  • Company Password Manager: All employees must use the company-approved password manager (e.g., 1Password, Bitwarden) for storing and sharing secrets like service account credentials.
  • Platform-specific Secret Stores: For application and infrastructure secrets, we use the secret management solution provided by our platform. For our stack, this is Cloudflare’s Wrangler secrets and the secrets management UI in the dashboard.
  • Local Development: For local development, secrets are stored in .env files, which are explicitly excluded from Git via the .gitignore file.

4. Principle of Least Privilege

  • Secrets should only be accessible to the people and systems that absolutely require them to function.
  • We use Role-Based Access Control (RBAC) in our platforms (GitHub, Cloudflare) to limit who has access to production secrets.

5. Secret Rotation

  • Secrets should be rotated regularly to reduce the risk of a compromised secret going undetected.
  • Rotation Schedule:
    • Critical secrets (e.g., database root credentials, signing keys): Rotate every 90 days.
    • High-sensitivity secrets (e.g., third-party API keys): Rotate every 180 days.
    • Other secrets: Rotate at least annually.
  • On Employee Offboarding: All secrets that an offboarding employee had access to must be rotated immediately as part of the offboarding process.
  • After a Security Incident: If a secret is known or suspected to be compromised, it must be rotated immediately.

Responsibilities

  • All Employees: Are responsible for safeguarding any secrets they have access to and adhering to this policy.
  • DevOps/Technical Leads: Are responsible for implementing and managing the technical secret management solutions and for leading the secret rotation process.

Violation of this policy is a serious security risk and will be treated as such.

Graph View

Backlinks