ローカル環境のターミナルからAWSの各種サービスを操作するために欠かせないAWS CLIですが、これまでの認証プロセスには、セキュリティと利便性のトレードオフがつきまとっていました。ローカル環境で一時的にAWSリソースにアクセスする際の認証設定は、地味ながらも手間がかかる作業の一つでした。

本記事では、この課題を解決するAWS CLIにログインするための新機能であるaws login コマンドについて、そのメリット、使い方、そして注意点について解説します。

これまでの認証方法

ローカル環境でAWS CLIを利用するための主な認証方法は以下の通りでした。

1.アクセスキー（IAMユーザーの長期認証情報）による接続
概要: IAMユーザーを作成し、発行されるアクセスキーIDとシークレットアクセスキーを ~/.aws/credentials ファイルなどに直接設定する方法です。

課題: この認証情報は永続的であり、一度流出すると他の人に使われてしまう危険性があります。セキュリティの観点から、AWSのベストプラクティスでは長期的なアクセスキーの利用は非推奨とされています。

2.一時的な認証情報（STS）による接続
概要: IAMロールを引き受ける（sts:AssumeRole）ことで発行されるセッショントークンを含む一時的なアクセスキーを利用する方法です。

課題: セキュリティは高いものの、一時アクセスキーの発行プロセスや環境変数への設定、そして有効期限が切れるたびに手動で更新する手間が発生し、利便性が損なわれがちでした。

aws loginのメリット

  • キーレス認証: ローカルファイルに永続的なシークレットアクセスキーを保存する必要がなくなります。セキュリティリスクを低減できます。
  • シンプルな操作性: コマンド一つでブラウザ認証に誘導され、認証情報が自動的にターミナルに引き継がれます。

aws loginを用いた認証ステップ

aws loginを使うと、以下のようなステップになります。

1,ブラウザでAWS環境にログイン:事前にブラウザ（AWSコンソール）で、aws login を使用したいAWS環境にログインしておきます。
2,ターミナルでコマンドを実行
aws login
3,ブラウザでのユーザー選択: コマンド実行後、デフォルトのブラウザが自動で開きます。開いたページで、ターミナルに認証を適用したいログイン済みユーザー（セッション）を選択します。
4,ターミナルに認証が通る：ブラウザでの承認が完了すると、自動的にターミナルに戻り、セッションに対する一時的な認証情報が設定されます。これで、AWS CLIの各種コマンドが実行可能になります。

https://aws.amazon.com/jp/blogs/security/simplified-developer-access-to-aws-with-aws-login/
ログイン方法の詳細はドキュメントに譲ることとしますが、私が試した時はうまくいかなかったのでそれについて記録しておきます。

aws login を利用するための前提条件と落とし穴

前提条件
1,aws cliのバージョン
aws login 機能は、AWS CLI バージョン 2.32.0 以降でサポートされています。
利用する前にバージョンを確認しましょう。
aws --version
2,IAMユーザーへの必要な権限付与
この認証を通すには、ログインしたいIAMユーザーに、OAuth2の認証プロセスに必要な特定の権限を付与する必要があります。
具体的には、以下の2つのアクションが必要となります。
signin:AuthorizeOAuth2Access
signin:CreateOAuth2Token
これらを許可するカスタムポリシーを作成する方法もありますが、
AWSが提供するマネージドポリシーのSignInLocalDevelopmentAccessの権限を付与するのが簡単です。

「400エラー」の落とし穴

最初に試行した際、「CLIのバージョンアップ（前提条件1）のみ対応していれば大丈夫だろう」と早とちりしてしまい、認証プロセスでデフォルトブラウザが開いた後、ユーザーを選択すると「400エラー」が発生して認証途中で止まってしまうという事態になりました。これはまさにSignInLocalDevelopmentAccess(前提条件2)が欠けていたことが原因です。上記ブログを読み直すことでこの権限不足に気づき、SignInLocalDevelopmentAccess ポリシーをアタッチすることで無事に問題を解決できました。

もしログインを試してみたいという場合は、上記お気をつけください。