Exercise 2: Describing the Bastion-Host Pattern — Possible Solution
====================================================================

1. The production database keeps its bind address set to a private
   network IP only (never 0.0.0.0), and its firewall allowlists only
   the application server(s) and one specific bastion host — never any
   individual developer's laptop or home IP.

2. The bastion host is a single, small, tightly monitored server that
   sits on the same private network as the database and is the ONE
   machine allowed to reach the database's port directly.

3. The developer connects to the bastion host over SSH (the same
   mechanics as the SSH course's remote_lesson_05), and uses SSH LOCAL
   PORT FORWARDING to tunnel a connection through it:

   ssh -L 3306:db-internal-host:3306 user@bastion-host

4. The developer's own database client then connects to
   localhost:3306 on their own machine — that traffic is tunnelled
   through the SSH connection to the bastion host, which forwards it
   on to the real database on the private network.

WHY THIS AVOIDS OPENING THE PORT PUBLICLY: at no point does the
database's own port need to accept connections from the internet, or
even from the developer's laptop's real IP — the database only ever
needs to trust the bastion host, whose IP is fixed and known.
Developers gain access, but only by first authenticating to the
tightly controlled bastion (which can itself be monitored/audited,
per Chapter 7), never by the database exposing itself directly to
wherever a laptop happens to be connecting from.