Environment Variables and Secrets Management

Why Secrets Must Stay Out of Source Code

Every application eventually needs sensitive values: database passwords, API keys, authentication tokens, and encryption secrets. The most dangerous place to store these values is directly in your source code. When code is committed to a Git repository, every secret embedded in it is recorded permanently in the project history. Even if you delete the file in a later commit, the value remains visible in earlier commits and can be retrieved by anyone with access to the repository.

Real-world data breaches have resulted from developers accidentally pushing credentials to public repositories on platforms such as GitHub. Automated scanning bots continuously search public repositories for patterns that look like API keys and passwords. Within minutes of an accidental push, those credentials can be harvested and misused. This is not a theoretical risk — it is a routine occurrence that costs organizations significant time, money, and reputation.

The core principle is simple: source code is for logic, not for secrets. Secrets belong in the environment, not in the codebase.

What Is an Environment Variable?

An environment variable is a named value stored in the operating system's process environment rather than in a file the application reads directly. Every process running on a system inherits a set of environment variables from its parent. Applications can read these values at runtime without the values ever being written into the source files.

On Linux (relevant to CompTIA Linux+), you set an environment variable in a shell session with:

```bash

export DATABASE_URL="postgres://user:password@host/dbname"

```

You read it in the same session with:

```bash

echo $DATABASE_URL

```

In Python, the `os` module provides access to these values:

```python

import os

db_url = os.environ.get("DATABASE_URL")

```

Because environment variables exist only in the running process, they are never written into your `.py` files and never committed to Git.

The .env File for Development

Typing `export` commands every time you open a terminal is impractical during development. A `.env` file (short for "environment") solves this by storing key-value pairs in a plain text file that lives on your local machine only. The format is straightforward:

```

DATABASE_URL=postgres://user:password@host/dbname

SECRET_KEY=a-long-random-string

DEBUG=True

```

The critical rule: the .env file must never be committed to version control. You enforce this by adding `.env` to your project's `.gitignore` file. Once listed there, Git will not track it, and it will not appear in `git status` output or in any commit.

The `python-dotenv` package reads a `.env` file and loads the values into the process environment automatically when your application starts. Install it with:

```bash

pip install python-dotenv

```

In a Flask application, you load the variables near the top of your entry point:

```python

from dotenv import load_dotenv

import os

load_dotenv() # reads .env and populates os.environ

app = Flask(__name__)

app.config["SECRET_KEY"] = os.environ.get("SECRET_KEY")

```

This pattern keeps all sensitive values off the file system that Git watches.

Production: Process-Level Environment Variables

A `.env` file is a development convenience. In production, you should not copy a `.env` file to your server. Instead, set environment variables directly in the server's process environment or through your cloud platform's configuration interface.

Cloud platforms such as Heroku, Render, Railway, and AWS Elastic Beanstalk all provide a dashboard or command-line interface where you enter environment variables that are injected into your application's process at startup. Your code reads them the same way — through `os.environ.get()` — so no code changes are needed between development and production.

On a Linux server managed directly, you can set variables in the service unit file (systemd) or in a restricted configuration file that is not part of the repository. Only system administrators with appropriate access should be able to read these values.

Secrets Manager Services

For enterprise and production environments, dedicated secrets manager services provide an extra layer of control. Examples include AWS Secrets Manager, HashiCorp Vault, and Azure Key Vault. These services store secrets encrypted, audit every access, support automatic rotation of credentials, and allow fine-grained permissions. Applications retrieve secrets by calling an API rather than reading a file. This approach is beyond what a `.env` file offers and is the standard for professional production deployments.

Remediating an Accidental Leak

If a secret is accidentally committed to Git history, removing it from the latest file is not enough — the history must be rewritten. Remediation steps include:

1. Immediately revoke and rotate the exposed credential at the source (the database, the API provider, etc.). Assume it is already compromised.

2. Use tools such as `git filter-repo` or BFG Repo-Cleaner to remove the secret from history.

3. Force-push the cleaned history to the remote repository.

4. Notify any collaborators who have clones of the repository so they re-clone from the cleaned version.

Step one — rotating the credential — is the most important. Cleaning the history prevents future exposure but does not undo past exposure.

Safety Reminder

In web and software development, "safety" includes data security. Mishandling credentials can expose users' personal data, violate privacy regulations, and result in legal liability for your employer. Treat secrets with the same discipline that tradespeople apply to lockout/tagout procedures: a missed step causes harm that is difficult or impossible to reverse.