aws-vault vs Granted：macOSでAWSクレデンシャルを安全に管理するツール比較

はじめに

AWSの開発を行う際、~/.aws/credentialsにアクセスキーを平文で保存していませんか？これはセキュリティ上のリスクが高く、万が一ファイルが流出した場合、AWSアカウントが不正利用される恐れがあります。

この記事では、macOSでAWSクレデンシャルを安全に管理するための2つのツール「aws-vault」と「Granted」を比較し、セットアップ手順から日常的な使い方、マルチアカウント運用時のワークフローまでを紹介します。

なぜ平文のクレデンシャルが危険なのか

デフォルトのaws configureを実行すると、アクセスキーが~/.aws/credentialsに平文で保存されます。

[default]
aws_access_key_id = AKIAIOSFODNN7EXAMPLE
aws_secret_access_key = wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

このファイルが以下の経路で流出するリスクがあります：

• dotfilesリポジトリへの誤コミット
• マルウェアによるファイル読み取り
• ディスクバックアップからの漏洩
• 共有端末での他ユーザーからのアクセス

aws-vaultとGrantedは、いずれもOSのキーチェーンにクレデンシャルを暗号化保存し、STSで一時的な認証情報を生成することでこの問題を解決します。

前提・環境

• macOS（Keychain Access対応）
• Homebrew導入済み
• AWS CLIインストール済み
• IAMユーザーのアクセスキー（MFA設定済み）

aws-vault

概要

aws-vaultは、99designs社が開発したGo製のCLIツールです。AWSクレデンシャルをOSのキーチェーンに暗号化して保存し、STSのGetSessionTokenやAssumeRoleを使って一時的な認証情報を生成します。

インストール

brew install --cask aws-vault

初期セットアップ

1. クレデンシャルの保存

aws-vault add my-profile

アクセスキーIDとシークレットキーの入力を求められます。入力した情報はmacOS Keychainに暗号化して保存されます。

ポイント: ~/.aws/credentialsには保存されません。Keychain Access.appで「aws-vault」キーチェーンとして確認できます。

2. ~/.aws/configの設定

[profile my-profile]
region = ap-northeast-1

[profile my-profile-admin]
source_profile = my-profile
role_arn = arn:aws:iam::123456789012:role/AdminRole
mfa_serial = arn:aws:iam::123456789012:mfa/your.name
region = ap-northeast-1

• source_profile: aws-vaultに保存したプロファイル名を指定
• role_arn: AssumeRoleするロールのARN
• mfa_serial: MFAデバイスのARN（IAMコンソールの「セキュリティ認証情報」タブで確認）

3. 動作確認

aws-vault exec my-profile-admin -- aws sts get-caller-identity

MFAトークンの入力を求められ、成功すると以下のような出力が得られます：

{
    "UserId": "AROA3XFRBF23EXAMPLE:session-name",
    "Account": "123456789012",
    "Arn": "arn:aws:sts::123456789012:assumed-role/AdminRole/session-name"
}

macOS Keychain統合の仕組み

1. 専用キーチェーン: aws-vault addで保存されたクレデンシャルは、ログインキーチェーンではなく専用の「aws-vault」キーチェーンに格納されます
2. コード署名: macOSリリースビルドはコード署名されており、Keychainアクセス時の繰り返しのパスワードプロンプトを防ぎます
3. 一時認証情報: 保存された長期クレデンシャルからGetSessionTokenで一時クレデンシャルを生成（デフォルト1時間有効）。アプリケーションには一時クレデンシャルのみが渡されます
4. 確認方法: Keychain Access.appを開き、サイドバーの「aws-vault」キーチェーンから保存された情報を確認できます

よく使うコマンド

よくあるトラブル

「already in subshell」エラー

aws-vault: error: exec: running in an existing aws-vault subshell

すでにaws-vaultのサブシェル内にいる場合に発生します。exitでサブシェルを抜けてから再実行するか、echo $AWS_VAULTで現在のセッションを確認してください。

exit                              # サブシェルを抜ける
aws-vault exec my-profile-admin   # 再度実行

exitはaws-vault固有のコマンドではなく、シェルのビルトインコマンドです。aws-vaultのexecがネストされたシェルプロセスを起動するため、exitでそのシェルを終了すると親シェルに戻ります。

セッション期限切れ

# セッション期限切れでコマンドが失敗する場合
aws-vault clear my-profile-admin  # キャッシュをクリア
aws-vault exec my-profile-admin   # 新しいセッションを取得（MFA再入力）

Granted

概要

Grantedは、Common Fate社が開発したGo製のCLIツールです。aws-vaultと同様にKeychainにクレデンシャルを暗号化保存しますが、サブシェルを使わずに現在のシェルで直接クレデンシャルを切り替えられるのが最大の特徴です。

インストール

brew tap common-fate/granted
brew install granted

インストール後、バージョンを確認します。

granted -v

初回実行時に、シェルプロファイルにエイリアスの追加を求められます。これによりassumeコマンドが使えるようになります。設定後、ターミナルを再起動してください。

初期セットアップ

Grantedは~/.aws/configを読み込むため、aws-vaultと同じ設定ファイルがそのまま使えます。

1. IAMクレデンシャルの安全な保存

Grantedもキーチェーンにクレデンシャルを保存できます。

granted credentials import

このコマンドで~/.aws/credentialsの平文クレデンシャルをシステムキーチェーンに移行します。

2. ~/.aws/configの設定

aws-vaultと同じ設定がそのまま使えます。

[profile my-profile]
region = ap-northeast-1

[profile my-profile-admin]
source_profile = my-profile
role_arn = arn:aws:iam::123456789012:role/AdminRole
mfa_serial = arn:aws:iam::123456789012:mfa/your.name
region = ap-northeast-1

3. 動作確認

assume my-profile-admin

プロファイルを指定せずにassumeだけ実行すると、インタラクティブなファジー検索でプロファイルを選択できます。

assume
# → プロファイル一覧がファジー検索で表示される

よく使うコマンド

aws-vault vs Granted 比較

基本比較

マルチアカウント運用の比較

複数のプロジェクト×環境（stg/prod）を扱う場合、ワークフローに大きな差が出ます。

aws-vault：1シェル1アカウント

aws-vault exec project-a-stg      # サブシェル1
# 作業する...
exit                                # サブシェルを抜ける
aws-vault exec project-b-prod     # サブシェル2（MFA期限切れなら再入力）
# 作業する...
exit
aws-vault exec project-a-stg      # 戻る（MFA期限切れなら再入力）

アカウントを切り替えるたびにexit → execが必要で、シェルのコンテキスト（カレントディレクトリ、環境変数、コマンド履歴）が失われます。

Granted：シェル内で切り替え

assume project-a-stg              # 現在のシェルに環境変数をセット
# 作業する...
assume project-b-prod             # 環境変数を上書きするだけ
# 作業する...
assume project-a-stg              # 戻る、exitは不要

サブシェルを使わないため、シェルのコンテキストを維持したまま切り替えられます。

AWSコンソールアクセスの違い

# aws-vault: 1ブラウザセッションに1アカウント
aws-vault login project-a-stg     # ブラウザでコンソールを開く
aws-vault login project-b-prod    # 上のセッションからログアウトされる

# Granted: 複数アカウントを同時にブラウザで開ける
assume -c project-a-stg           # タブ1: project-a-stg のコンソール
assume -c project-b-prod          # タブ2: project-b-prod のコンソール（別コンテナ）
assume -c project-c-dev           # タブ3: project-c-dev のコンソール

Grantedはブラウザのコンテナ機能を使って、複数のAWSアカウントに同時ログインできます。マルチアカウント運用では非常に便利です。

セッション更新の違い

IAM + MFA構成の場合、セッション期限切れ時の動作が異なります。

補足: MFAトークンの入力自体はどちらのツールでも省略できません。違いは、再認証時にシェルのコンテキストが維持されるかどうかです。

awsumeについて

awsumeは、Grantedと同様に現在のシェルに環境変数をエクスポートする方式のPython製ツールです。autoawsumeによる自動リフレッシュやプラグインシステムなど優れた機能がありますが、以下の理由から本記事ではaws-vaultとGrantedの2択をお勧めします。

• クレデンシャルが~/.aws/credentialsに平文で保存される（Keychain統合なし）
• Python依存（ランタイムのインストールやバージョン管理が必要）
• Go製バイナリと比較してCLIの起動が遅い

どちらを選ぶべきか

aws-vaultが向いているケース

• シンプルなIAM + MFA構成で、少数のアカウントを管理
• チームで既にaws-vaultを使っている（切り替えコストを避けたい）
• 最小限の依存でシングルバイナリを好む

Grantedが向いているケース

• 複数プロジェクト × 複数環境（stg/prod）のマルチアカウント運用
• AWS SSO / IAM Identity Centerを使用（または移行予定）
• 頻繁にアカウントを切り替える開発ワークフロー
• 複数アカウントのAWSコンソールを同時に開きたい

移行について

aws-vaultからGrantedへの移行は比較的簡単です。~/.aws/configの設定はそのまま共用でき、granted credentials importでクレデンシャルを移行できます。両方を同時にインストールしておくことも可能です。

まとめ

aws-vaultとGrantedはどちらもAWSクレデンシャルをKeychainに安全に保存し、一時認証情報で運用できる優れたツールです。

• セキュリティ面は同等: どちらもKeychain暗号化 + STS一時認証
• 日常のワークフローに差が出る: サブシェル方式（aws-vault）vs 環境変数エクスポート方式（Granted）
• マルチアカウントではGrantedに軍配: アカウント切り替えの手軽さ、ファジー検索、複数コンソール同時ログインが便利

今からセットアップするなら、特にマルチアカウント環境ではGrantedをお勧めします。既にaws-vaultを使っていて単一アカウントであれば、無理に移行する必要はありません。

参考

• aws-vault GitHub
• aws-vault USAGE.md
• Granted 公式サイト
• Granted ドキュメント
• Granted Getting Started