少しキャッチーなタイトルを考えてみました。
これは、私が実際に業務で体験した話です...👻
一体、何が起きたのか...
AWS上の運用保守用サーバとして、EC2を用意していました。
このサーバにはAWS CLIを導入しており、以下のコマンドでS3にファイルを転送していました。
aws s3 cp hoge-file s3://hoge-bucket
参考：オブジェクトのコピー
が、しかし！
いつの間にか、上記のコマンドでは認証エラーが発生するようになっていました。
一方でsudoコマンドを使った場合は、今まで通りファイル転送できることが分かりました。
# 認証エラーが発生してしまう
aws s3 cp hoge-file s3://hoge-bucket
# 認証エラーは発生せず、ファイル転送に成功する
sudo aws s3 cp hoge-file s3://hoge-bucket
現状の整理
改めて、認証周りの設定を確認しました。
- EC2にはIAMロールが付与され、S3へのファイル転送が許可されている
- S3のバケットポリシーでは、EC2からのアクセスだけが許可されている
- EC2には、
aws configureコマンドで認証情報が設定済み - 設定した認証情報はフェデレーテッドユーザーのものであり、認証情報が一時的なものである（有効期限が切れると使えない）
どうやら作業の過程でaws configureしてしまい、EC2に重複した認証情報が設定されていたようです。
「認証情報の優先度」について
今回の原因は、まさにこのドキュメントに書いてある内容でした。
(以下、AWS CLI の公式ドキュメントを意訳)
認証情報は複数の箇所で設定可能であり、それぞれの設定には優先順位があります。AWS CLI において、認証情報は次の順序で優先されます。
1. コマンドラインオプション
--region、--output、--profile パラメータなど
2. 環境変数
3. Assume role / ウェブIDを利用したAssume role
assume-role等のコマンドで IAM ロールのアクセス許可を継承
4. AWS IAM Identity Center
5. credentials ファイル
aws configureを実行すると設定される
6. カスタムプロセス
外部ソースから認証情報を取得
7. config ファイル
aws configureを実行すると設定される
8. コンテナの認証情報
ECSのタスクロールのこと（のはず...）
9. EC2 インスタンスプロファイルの認証情報
EC2への、IAM ロールの関連付け
つまり私の環境では、コマンドを実行すると次のような処理がされていたのでした。
sudoなしの場合
- 上述の優先度に沿って、CLI が認証情報を確認する
/home/ec2-user/.awsに credentials ファイルが存在する（優先度5に該当）- credentials ファイルに設定されたフェデレーテッドユーザーが認証情報として利用される
- 一時的な認証情報の有効期限が切れており、コマンドに失敗する
sudoあり（Root環境）の場合
- 上述の優先度に沿って、CLI が認証情報を確認する
/root/.awsに credentials ファイルが存在しない- EC2 インスタンスプロファイル（IAMロール）が認証に利用される（優先度9に該当）
- IAMロールはS3へのアクセスを許可しているため、コマンドが成功する
AWS CLI を使いたくなったときは
aws configure で永続的な認証情報を保存する方法は、セキュリティ面で推奨されていません。
一方で、一時的な認証情報を利用する場合では、認証情報を毎回設定し直す必要が生じます。
もし既に EC2 がデプロイ済（予定）ならば、IAMロールを設定したEC2から AWS CLI のコマンドを実行するのが良いかもしれません。