AWS CLI・AIからSSOプロファイルをアドホックにセッション限定で使う

記事の趣旨：configファイルを太らせず「今からこのアカウントに、この権限で入る」をその場で指定し、今使っているシェルやAIのセッションの中だけで有効にしたい。

権限セットの利用

IAM Identity Centerで割り当てられたアカウントへのアクセス権限セットをCLIから利用するには、主に2つの方法があります。
1つはアクセスポータルの「Access keys」から一時認証情報をコピーする方法、もう1つはSSOプロファイルを使う方法です。

Access keysは手軽ですが、コピーした一時認証情報はクリップボードやシェルの履歴に残り、AIエージェントに貼れば会話の履歴にも残ります。
有効期限内なら、誰が持っていても使えてしまいます。

次にSSOプロファイルからの利用ですが、接続情報を ~/.aws/config に登録しておくことで利用できます。config自体には秘密情報を含みません。
通常 ~/.aws/config にプロファイル登録するため、端末のどこからでも利用できます。
今回は、こちらの方法をわけあって少しカスタマイズして利用します。

課題感

私の所属部署は20以上の社内サービスの開発と運用、1つの商材の技術主幹を担当しています。
管理するAWSアカウントは30を超えており、アドホックにいずれかのアカウントに分析や調査で入りたい場面が多々あります。紐づけている権限セットも様々です。その調査をAIとともに行うことが多いです。

~/.aws/config にプロファイルを予め登録して使っていましたが、数が増えるにつれ、めったに使わないアカウントや権限のプロファイルが溜まるのが気になっていました。また、登録したプロファイルは端末のどこからでもAWS CLIで使えるので、自身やAIが利用するプロファイルを取り違えるリスクも気になります。

そこでやりたいのが、問い合わせや障害の調査で 「今からこのアカウントに、この権限で入る」をその場で決めて、作業用シェルやAIのセッションの中だけで有効にする(セッション限定)ことです。

満たしたいこと

1. 秘密情報を人やAIの手に渡さない。渡すのはアカウントIDと権限セット名だけ
2. セッションから見える接続先は1つだけで、ほかのセッションに影響しない
3. ~/.aws/config に何も書かず、追加のツールも入れない。AWS CLI v2とシェルだけで済ませる

とった方法

ということで、SSOプロファイルをその場でセッション専用の一時configに書き、そのセッションからだけ使う形にしました。
私の端末の ~/.aws/config および ~/.aws/credentials は空ファイルです。
鍵になるのは、AWS CLIの次の2つの仕様です。

• SSOプロファイルの定義には秘密情報が含まれない
• AWS_CONFIG_FILE で、セッションが読むconfigファイルの場所を変更できる

この記事では、まず基本編として、標準の aws configure sso を一時configに向けて実行し、同じシェルからClaude Codeを起動する方法を紹介します。IDE拡張のように環境変数を引き継げない場面での使い方も、基本編で扱います。追加のツールも独自のスクリプトも使いません。
そのうえで、ほかのセッションからは接続できないこと、2つのセッションで別々のアカウントにつないでも干渉しないこと、AIが別のアカウントに取り違えてつながらないことを検証します。

最後に応用編として、部署ではこれらをIdentity Centerのポータルアプリで自動生成して使っているので紹介します。
何かの参考になれば幸いです。

全体像

接続先はセッションごと

シェルごとに専用の一時configを作り、AWS_CONFIG_FILE でそこだけを指します。そのシェルから起動したClaude Codeも、同じ一時configを使います。各セッションから見えるプロファイルは1つだけです。

アクセス方法の比較

リポジトリ同梱は、同じアカウント群をずっと触るプロジェクトには向いています。ただ、今回のように「今からこのアカウントを調べたい」という使い方には合いませんでした。
なお、aws-sso-utilのドキュメントにも、一時ファイルにconfigを書く手順があります。本方式は標準の aws configure sso で同じことをし、AIのセッションにも使います。

基本編: 一時configに向けてaws configure sso

事前準備: 端末固有の設定は環境変数に

社内のTLS検査プロキシ用のCAなど、端末ごとの設定は一時configには入れていません。AWS_CA_BUNDLE などの環境変数として端末側に設定しておけば、一時configを作り直しても引き継がれます。TLS検査プロキシのある環境では、ウィザードの通信も証明書エラーで失敗するので、先に設定しておきます。
たとえば ~/.zshrc などに次のように書いておきます(参考: AWS CLIの環境変数)。

export AWS_CA_BUNDLE="$HOME/certs/corp-ca-bundle.pem"
export AWS_DEFAULT_REGION=ap-northeast-1

一時configを作ってログインする

作業を始めるシェルで、次を実行します。

unset AWS_PROFILE AWS_DEFAULT_PROFILE AWS_ACCESS_KEY_ID AWS_SECRET_ACCESS_KEY AWS_SESSION_TOKEN
export AWS_CONFIG_FILE="$(mktemp -d)/config"
export AWS_SHARED_CREDENTIALS_FILE=/dev/null
aws configure sso --profile default

• 1行目は、環境変数の掃除です。これらが残っているとその設定にひっぱられ挙動が変わる可能性があるため綺麗にします。
• 2行目で、毎回新しい一時ディレクトリを作り、その中の config をこのシェルが読むconfigの場所に指定します。ファイルは4行目のウィザードが書きます(参考: mktemp(GNU coreutils))。これによって他セッションからの参照先と分離しています。
• 3行目は、~/.aws/credentials を普段使っている場合も、ここでは参照させないためです。
• 4行目のコマンドを実行するとウィザードが起動するので、sso-session名やstart URLを入力し、一覧からアカウントと権限を選びます。--profile default を付けているので、プロファイル名は聞かれずに default で書かれます。defaultにしておくことで以降のコマンドでプロファイルを指定せずに済みます。

書かれた一時configを cat "$AWS_CONFIG_FILE" で確認してみます。

[default]
sso_session = my-team
sso_account_id = 111111111111
sso_role_name = AWSReadOnlyAccess
region = ap-northeast-1

[sso-session my-team]
sso_start_url = https://example.awsapps.com/start
sso_region = ap-northeast-1
sso_registration_scopes = sso:account:access

aws s3 ls でバケットリストが見えるかを確かめると分かりやすいです。

一時configでもログイン状態を使える

最初の aws configure sso では、ウィザードの途中でブラウザが開き、サインインしてアクセスを承認します。2つ目以降のシェルでもブラウザは開きますが、ブラウザがIdentity Centerにサインインしたままなら、何も操作せずにウィザードに戻ります。一時configは毎回新しく作るので、ウィザードはキャッシュを使わずにトークンを取り直すためです。

取り直したトークンは、configファイルではなくsso-sessionの名前に紐づくキャッシュに保存されます。公式ドキュメントにも、次のように書かれています。

The authentication token is cached to disk under the sso/cache directory with a filename based on the session name.

そのため、一時configを使うシェルやAIのセッションからも、このキャッシュのトークンでそのまま接続できます。

AIから使う: ターミナルから起動する場合

同じシェルから、Claude Codeを起動します。

claude

シェルで設定した環境変数は、そこから起動したClaude Codeにも引き継がれます(公式ドキュメント)。

IDE拡張経由のAIから使う: 環境変数を引き継げない場合

IDE拡張経由でAIエージェントを使う場合などは、ターミナルで export した環境変数が引き継がれないことが多いので、一時configの中身と環境変数の付け方を、指示文でAIに渡します。指示を守るかどうかをAIに任せることになるので、確実性はターミナルから起動する方法より下がります。ただ、~/.aws/config にはプロファイルが無いので、~/.aws/credentials も空なら、AIが環境変数を付け忘れても、別のアカウントにはつながらずエラーになります。

上の手順で作った一時configの中身を cat "$AWS_CONFIG_FILE" で表示し、次のような指示文に貼ります。

例

# svc-a-dev / AWSReadOnlyAccess

このセッションは AWS アカウント svc-a-dev（111111111111）に AWSReadOnlyAccess で接続して作業する。
下の config を、このセッション専用の一時ディレクトリ（無ければ mktemp -d で作る）に config という名前で書く。
以降の AWS コマンドは全部 AWS_CONFIG_FILE=<書いたファイルのパス> AWS_SHARED_CREDENTIALS_FILE=/dev/null を付けて実行し、まず aws sts get-caller-identity で確認する。
トークン切れなら自分でログインせず、同じ環境変数を付けた aws sso login を私に案内して待つ。

```
[default]
sso_session = my-team
sso_account_id = 111111111111
sso_role_name = AWSReadOnlyAccess
region = ap-northeast-1

[sso-session my-team]
sso_start_url = https://example.awsapps.com/start
sso_region = ap-northeast-1
sso_registration_scopes = sso:account:access
```

先頭に見出し行を入れておくと、セッション一覧で接続先を見分けやすくなります。

検証

検証用のアカウント2つ(svc-a-dev と svc-b-stg)と読み取り専用の権限で、それぞれのシェルから aws s3 ls を実行しました。グローバルの ~/.aws/config は空の状態です。

続いて、シェルAとシェルCからそれぞれClaude Codeを起動し、指示を出した結果です。

なお、これは取り違えを防ぐための仕組みで、AIの操作を制限するものではありません。

基本編で残る課題

毎回、決まったコマンドを実行し、対話式でstart URLを指定し、アカウントと権限を選択する手間があります。

これは次の応用編で解消します。

応用編: アクセスポータルに載せたアプリで自動生成

私の部署では、自分に割り当てられたアカウントと権限セットを一覧で表示し、基本編の手順に相当するシェルと指示文をコピーできるアプリ(以下、AWSアカウントアプリ)を作って利用しています。
見た目や使用感は、アクセスポータルに標準でついている「AWS accounts」画面を参考にしています。
アクセスポータルにアプリとして登録し、Identity Centerのサインインをそのまま使います。

アカウント一覧から利用したい権限の「for CLI/Chat」ボタンを押すと、一時configを作るシェルをコピーできるようにしています。

なお、部署には社内CAなどの端末固有の設定を ~/.aws/config の default に書いている人もいるので、生成するシェルには、そこから ca_bundle・output・cli_pager の値だけを読み出して環境変数に引き継ぐ処理も入れています。

構成はざっくりこのような感じです。

サインインユーザーの割り当てからシェルと指示文を組み立てる

まとめ

• SSOプロファイルの定義は秘密情報を含まないので、その場で書いて捨てられる
• 標準の aws configure sso を一時configに向けるだけで、SSOプロファイルをアドホックにセッション限定で使える

SSOプロファイルを、必要なときに必要なセッションでだけ使えるようになりました。
応用編で紹介したアプリも、また機会があれば記事にしたいと思います！

参考リンク

• 共有configファイルと認証情報ファイルの場所(AWS_CONFIG_FILE / AWS_SHARED_CREDENTIALS_FILE)
• AWS CLIでのIAM Identity Center認証の設定
• AWS CLIの環境変数
• 短期認証情報を使ったAWS CLIの認証(Access keys)
• aws-sso-util run-as