🔷

[AWS CLI] aws login利用の考察 -OAuth2.0とパスキーを考える-

に公開
AWS
Security
OAuth 2
AWS CLI
Passkey (パスキー)
tech

はじめに

11/19に発表されたaws loginコマンドを使ってみた所感をまとめる。
aws loginを実行することで、ブラウザのAWSコンソール画面に遷移し、ブラウザでの認証を通じてAWS CLIを利用できる。v2.32.0以降で使用可能。
従来のアクセスキー管理での手間や漏洩リスクを避けられる点で、代替手段として有望視される。

コマンド実行時の内部ではOAuth2.0の認可の仕組みが用いられている。
ブラウザでの認証が前提となるが、特にMFA環境での認証時に、パスキーの利用が便利であった。
本記事では、以下の内容を取り扱う。

  • aws login: 使い方と運用考察
  • OAuth2.0: loginコマンド内部での仕組み
  • パスキー: MFAがあるAWS環境での活用方法

脚注内での引用は、以下のAWS Securityブログを参照している。
https://aws.amazon.com/jp/blogs/security/simplified-developer-access-to-aws-with-aws-login/

aws loginの仕組み -OAuth2.0を用いた認可-

OAuth2.0 認可コードグラント/PKCE有りでの認可が行われている。
loginコマンドと銘打っているが、実際はAWSコンソール画面での認証を通過した後、認証済みIAMユーザの権限を一時的に委譲するため、CLI側としては認可の扱いである。
実行には、signin:AuthorizeOAuth2Access, signin:CreateOAuth2Tokenの2つの権限が必要[1]。

callbackされてきたcodeを使ってTokenを要求し、発行されたToken（アクセスキー相当）をprofileに格納しているとみられる。
このTokenは、OAuthでのAccessTokenそのものというより、AWS側の内部でSTSセッション相当の一時クレデンシャルへ変換の上、返却していると思われる。

またTokenについては、認可コードグラントを経て発行された一時クレデンシャル（先述のSTSセッション/CLIのアクセスキーに相当）が、15分に設定されている[2]。
Tokenの更新に用いるRefreshTokenが、最大12時間の設定になっているようである。
RefreshToken失効後は、最初のコンソール画面認証からやり直しになる（※動作未確認だが、その辺はOAuthの仕様に則っているはずであり、上述の記事内にも言及がある）。

STSセッションの性質上、永続的に有効ではないため、万が一漏洩が起きても侵害のリスクは下がることが期待される。

aws-login
aws login実行時

aws-login-cache-token-structure
.aws/login/cache内のToken構造

aws loginの特徴比較

導入によるメリット・デメリットを考えてみた。

➕ メリット

  • やはりアクセスキーから離脱できるのは大きい。
    • 管理の放置、漏洩のリスク低下に役立つのが最大のメリット。
    • 複数profileの使い分けから解放されるのも嬉しいポイント。
    • aws ssoの場合だと、複数Sessionが最初から選択可能なのも便利そう[3]。
  • 認可の仕組みが明快であり、必要なポリシーも少ないため、アクセスキー発行が不許可の環境で特に効力を発揮する。
    • アクセスキー不可ゆえにCLI操作を諦めていた環境で導入できると、作業効率の向上が期待できる。

➖ デメリット

  • ブラウザの認証を必ず挟むため、環境によっては逆に操作が煩雑になる。
    • Google Authenticator等TOTPによるMFAだと、特に複数環境での操作の煩雑さが増大する。
    • MFAのある認証時の利便性向上の考察については後述する。
  • 自動化の処理とはやや相性が悪い。
    • ブラウザの認証確認操作で途中で止まるため。

aws loginの使い方考察

有志の情報によると、11/22現在はCDK非対応のようで、AWS CLIの操作に用いるのが適しているとのことである。
自分なりにアクセスキーから移行する上での向き・不向きの環境を考えてみた。
aws loginは強力だが万能ではないため、影響度合いの少ない環境から段階的に移行してみて、リスク低減を図る運用が現実的に思われる。今後のアップデートにも期待したい。

⭕️ 移行に向いている環境

  • 短時間だけ、または簡単なAWS CLI操作を行う環境
  • しばらくAWS CLI操作をしていない等、アクセスキー維持管理の必要性が薄い環境
  • 検証目的で、試しに使ってみたい環境

🔺 移行に向いていない環境

  • デプロイ時のシェルスクリプトなど、途中で止まらず一貫した操作が行われて欲しい環境
  • GithubActionsでの実行など、ブラウザでの認証を想定していない環境
  • CDK構築など、現状ではできない用途目的でAWS CLIを使っている環境

aws login認証時の工夫 -パスキーをMFA環境で活用する-

aws login利用では必ずブラウザでの認証が挟まるのが特徴である。MFA設定済みAWS環境の場合、毎回MFA操作も込みでログインが必要である。短時間に複数環境を切り替えるような運用の場合、MFA操作がネックになりやすい課題が見えた。

そこで、MFA設定済みAWS環境での、ブラウザ操作を楽にすることを考える。
TOTPだと毎回認証コードのアプリを開きながらコード入力が必要なため、複数環境切り替えとの相性が悪い。
Yubikey等セキュリティキーや、パスキーの使用の方が便利である。今回はパスキーを使用することにした。

パスキーの技術仕様

パスキーは、公開鍵暗号を使った認証方式である。
サービスごとにRPID（Relying Party ID）という識別子の単位で、1セットの公開鍵・秘密鍵を作成する。
RPIDはサービスが認証対象として正規に使用するドメインを指し、配下のサブドメインも同一RPIDとして扱われる。
作成された鍵ペアのうち、秘密鍵はデバイス側が保持して、公開鍵のみサービス側に登録される。

認証時はチャレンジレスポンス方式を取る。サービス側からチャレンジの乱数が送られ、デバイス側が秘密鍵で署名し返却することで、署名の検証を行う。
検証結果の値が正しければ、本人として認証される。

パスキーをAWS環境で導入する場合

1Passwordのパスキーが扱いやすかった。

Mac御用達のiCloud キーチェーンのパスキーではAWS環境毎に識別できず、MFA用のパスキーを上書きしてしまった。
調べるとWebAuthnの仕様で、RPIDに紐づいており、AWSの場合は「*.signin.aws.amazon.com」で1つのサービスとして扱われるためらしい。

1Passwordの場合、同一のRPIDに対して複数Credentialをアプリ側で管理できる実装になっている。
そのため、AWSサービスのような一見同じドメインでも環境が異なるサービスに強い。
また1Passwordはクラウド上にパスキーも同期して管理するため、物理媒体のような破損の懸念がないのも強み。
筆者の場合、複数のAWS環境を短時間に切り替えて操作することが多いため、1Passwordのパスキーにより、作業効率が目に見えて向上した。

最後に

aws loginのリリースにより、AWS CLI環境の柔軟さが広がったと思う。特にアクセスキーに対する有効な手段を打ち出されたのは、使用者として大変ありがたく思う。今後のアップデートも楽しみである。
またOAuth2やパスキーなど、aws loginの仕組みや運用の考察を通して、認証認可の仕組みを深掘れたのも良かった。特にパスキーをはじめとしたWebAuthn, FIDO2周辺の分野は寡聞ゆえ、知見を深めていきたい。

参考記事

脚注

  1. The aws login command is controlled by two IAM actions: signin:AuthorizeOAuth2Access and signin:CreateOAuth2Token. Use the SignInLocalDevelopmentAccess managed policy or add these actions to your IAM policies to allow IAM users and IAM roles with console access to use this feature.

    ↩︎

  2. Regardless of the console sign-in method you choose, the temporary credentials issued by the aws login command are automatically rotated by the AWS CLI, AWS Tools for PowerShell and AWS SDKs every 15 minutes. They are valid up to the set session duration of the IAM principal (maximum of 12 hours). After reaching the session duration limit, you will be prompted to log in again.

    ↩︎

  3. If you have already signed into the AWS Management Console, the browser provides you with the option to select your active IAM role session from federated sign-in to the console. This enables you to switch between 5 active AWS sessions if you have multi-session support enabled on your AWS Management Console.

    ↩︎

Discussion