AWS CLIプロファイルで、ローカル操作の行き先を固定する
CLIは便利な反面、どの認証情報で実行したかを見失うと危険になる。プロファイル・リージョン・caller identityをセットで扱う。
TL;DR
- Terraform等の自動化用権限は、人のコンソールログイン用とは用途を分けて考える。
- 名前付きprofileでアカウントとリージョンの組合せを明示し、defaultに頼らない。
- 実行前後にsts get-caller-identityを使うと、認証先の取り違えを早く発見できる。
01人の操作と自動化の主体を分ける
コンソール利用者とローカルからAPIを呼ぶ認証を混同しない
この章ではTerraformやAWS CLIがAWS APIを呼ぶための認証を整える。人がコンソールへ入るためのSSOと、ローカル自動化の認証は用途・監査・権限設計が異なる。
自動化に必要な権限は広くなりやすい。用途と利用場所を固定して扱う。
- 人のコンソール操作はSSO中心
- CLIはAWS APIを呼ぶ認証主体
- 認証情報をソースコードに置かない
02名前付きprofileで実行先を明示する
コマンドの前に環境名を置くことで、暗黙のdefaultを避ける
AWS CLIの名前付きprofileに認証情報とリージョンを置き、実行時にprofileを指定する。環境名を目に見える形で含めることで、別アカウントへの誤実行を減らせる。
profileを切り替えたつもり、という記憶ではなく、コマンドと設定で行き先を表現する。
- profile名に環境を含める
- リージョンも設定値として固定する
- Terraform providerでも同じprofileを参照する
03caller identityを操作前の検査にする
権限エラーより先に、実行先が正しいかを確かめる
設定を書いたら、まずsts get-caller-identityを実行してアカウントIDとARNを確認する。リソースが見つからない、権限がない、と調べる前に認証先の取り違えを除外できる。
AWS CLIを使う日の最初の確認は、読み取り専用のcaller identityにする。
- profileを明示して実行する
- accountとARNを期待値と照合する
- regionも対象サービスのリージョンと合わせる
結論
- CLI認証は人のSSOと用途を分ける。
- 名前付きprofileでアカウントとリージョンを明示する。
- 最初にcaller identityを確認してからTerraformやAWS操作を始める。