- 公開日
- 最終更新日
【AWS CLI】認証でハマったこと
この記事を共有する
目次
はじめに
こんにちは。サービスGの佐藤です。
今回は、AWS CLI実行時に認証にまつわる内容を共有したいと思います。
実際、AWS CLI実行時に使用する認証の方法にはいくつか存在します。
同時設定されている場合の優先度も決められており、そこを理解していないと予期せぬトラブルとなるうるかなと思います。
今回、自分自身その優先度を認知してなかったばかりにすこしハマってしまいました。
それぞれの詳細は以下記事にわかりやすくまとめられておりますのでそちらご参照ください！
実施してたこと
今回EC2上よりAWS CLIを実行し、別AWSアカウント内のリソースAPIへ接続を行っておりました。
その際、認証の方法としては以下のようなことを実施しておりました。
- ①EC2にIAMインスタンスプロファイル情報として必要なIAMロールを設定
- ②そのロールを使用し、スイッチロールで別アカウントのリソース情報取得(aws sts assume-role)
- ③②実行後、AWS_ACCESS_KEY_ID 、AWS_SECRET_ACCESS_KEY、AWS_SESSION_TOKEN環境変数へ設定
今回、一時的な検証ということもあり多少面倒でしたが、③の方法を都度手動で実施していました。
以下、簡易図です。
ハマったこと
基本上記のとおりで実施していたのですが、
一回なぜかaws configureを実行し③で設定していた値をこちらのコマンドより設定し、~/.aws/配下に保存してしまいました。
補足：aws configureを実行することで.aws フォルダ配下にcredentials と config ファイルが作成されます。
最初はよかったのですが期限が切れるともちろんその認証情報は使用できません。
新たな認証情報を得よう(aws sts assume-role)としても、期限が切れた認証情報を使い取得しようとするので、
結果何もできない状態になってしまいました。
credentialsの削除
保存した認証情報を消せばよいのかなとなんとなく考え、credentialsファイルの中身を削除しました。
ですが、同様なエラーが出力されました。
実施すべきだったこと
認証の優先度の関係でまず、credentialsファイル、Configファイルの設定が優先されます。
その次にIAMインスタンスプロファイル情報が参照される形となります。
優先順は以下のようになります。※①から優先度高
①コマンドラインオプション
②環境変数
③ロールの継承
④ウェブ ID によるロールの継承
⑤AWS IAM Identity Center (SSO)
⑥認証情報ファイル
⑦カスタムプロセス
⑧設定ファイル
⑨コンテナ認証情報
⑩EC2 インスタンスプロファイル認証情報
参照：Configuring settings for the AWS CLI
今回、中身は消したものの、credentialsファイル(config)自体は残っており、 結果そちら設定を優先されてしまったようです。
そのため今回は必要ないので.awsごと削除しました。 削除したことによりIAMインスタンスプロファイル情報を使い、STSを取得できました。
まとめ
いかがだったでしょうか。 今回の失敗を機に認証についての優先度を認識することができました。 手を動かすことで再認識できることがあると改めて思い知りました…
この記事は私が書きました
佐藤 祐弥
記事一覧日々の業務上での学びをコツコツアウトプットできればなと思います。
