Satoru314 EC2 Bastion Postgres Setup
次の 2 点を分けて説明する。
- ローカル端末から踏み台経由で private EC2 に入る方法
- private Amazon Linux 上で PostgreSQL を構築する方法
実際のパスワード、秘密鍵、公開 IP、private IP、固有ユーザー名、DB 秘密情報は残さない。必ずプレースホルダに置き換える。
出力方針
まず、ユーザーが欲しいものを次から判定する。
Connection flowServer architecturePostgreSQL setupTroubleshooting from shell logs
特に指定がなければ、次の順で説明する。
- 構成と、なぜ bastion が要るか
- プレースホルダ付きの接続フロー
- 構築またはインストール手順
- 失敗パターンと切り分け
接続フロー
SSH 接続の話をするときは references/ssh-bastion-access.md を読む。
説明の順番はこれを基本にする。
- 秘密鍵はローカル Linux 側に置く。Windows マウント配下を前提にしない。
- 接続前に鍵の権限を絞る。
- agent forwarding が必要なら
ssh-agentを起動する。 - 鍵を
ssh-agentに登録する。 ssh -Aで bastion に入る。- bastion から private IP か private DNS で private host に入る。
説明時は、次の違いをはっきり分ける。
Connection timed outはだいたいネットワーク経路かセキュリティ設定の問題Permission denied (publickey)は到達はしているが認証に失敗している状態
PostgreSQL 構築フロー
PostgreSQL の話をするときは references/private-postgres-setup.md を読む。
説明は最小完結の流れにする。
- パッケージを入れる
- DB クラスタを初期化する
- サービスを起動し自動起動を有効にする
psql内でロールと DB を作る- 必要な private network または security group だけに開ける
- 再起動して確認する
private host がパッケージリポジトリへ直接出られないなら、private host にインターネットがある前提で話さず、bastion 経由の RPM 持ち込み手順を説明する。
構成説明
「こういうサーバーをどう組むか」を説明するときは references/aws-private-server-pattern.md を読む。
特に次を押さえる。
- public bastion、private workload host、必要なら app host
22/tcpと5432/tcpの security group 関係- NAT、VPC endpoint、あるいはパッケージ中継がないと
dnf updateが失敗しやすい理由 - PostgreSQL を基本 private に置き、app network からだけ受ける理由
ログ解釈ルール
ユーザーがログを貼ったら、単なる言い換えではなく 原因 -> 対処 に正規化する。
UNPROTECTED PRIVATE KEY FILE-> 鍵の置き場所か権限を直すCould not open a connection to your authentication agent->ssh-agentを起動してssh-add- 1 段目は通るが 2 段目で
Permission denied (publickey)-> agent forwarding 不足か private host 側の authorized key 不足 dnfmirror timeout -> private subnet から外へ出る経路がないCREATE: command not found-> SQL をpsqlではなく shell に打っているpostgres-#prompt -> SQL 文がまだ閉じていない。;で終えるかCtrl+C
ログをなぞるだけで終わらせず、順番つきの診断に変換する。
セキュリティ原則
説明では常に次を守る。
- 秘密情報はプレースホルダにする
- 秘密鍵は
chmod 600を基本にする pg_hba.confで0.0.0.0/0は原則避けるlisten_addressesは可能なら private 側に寄せる- 長期運用なら NAT Gateway、VPC endpoint、Systems Manager を候補に出す