AWS Vault を Ubuntu に導入する手順｜pass と file バックエンドの選び方

はじめに

AWS CLI を使う際、アクセスキーは既定で ~/.aws/credentials に平文（暗号化されていない状態）で保存されます。この方式は手軽な一方で、PC がマルウェアに感染した場合や、設定ファイルを誤って公開リポジトリにコミットした場合に、長期の認証情報がそのまま漏えいするリスクを抱えています。

このリスクを下げる選択肢が AWS Vault です。AWS Vault は、OS の暗号化キーストアや GPG を使ってアクセスキーを暗号化保管し、コマンド実行時のみ STS による一時的な認証情報を発行するツールです。macOS（Keychain）や Windows（Credential Manager）では導入が比較的容易ですが、Ubuntu などの Linux ではバックエンドの選択と設定でつまずきやすい点があります。

本記事では、Ubuntu 環境で AWS Vault を導入し、安全に運用するまでの手順を解説します。

要点を先に整理すると、現在の AWS Vault は開発元の 99designs 版が開発終了しており、メンテナンスが継続している ByteNess フォークを利用するのが推奨です。Ubuntu ではバックエンドを選ぶ必要があり、手軽さを優先するなら file、OS のキーストアと統合するなら secret-service や pass+GPG が候補になります。いずれの場合も、アクセスキーは暗号化保管され、実行時には有効期限付きの一時認証情報が使われます。

AWS Vault とは（なぜ必要なのか）

AWS CLI でアクセスキーを設定する一般的な方法は aws configure ですが、この方法では認証情報が平文で保存されます。ここでは、その課題と AWS Vault が解決する仕組みを整理します。

平文保存の課題

標準の AWS CLI は、アクセスキー ID とシークレットアクセスキーを ~/.aws/credentials に平文で保存します。このファイルが第三者の手に渡ると、攻撃者は有効期限のない長期の認証情報を入手することになり、リソースの不正利用やデータ漏えいに直結します。とくに、設定ファイルを誤って Git の公開リポジトリにコミットする事故は実際に多く報告されています。

AWS Vault が提供する安全性

AWS Vault は、次の 3 点で認証情報の取り扱いを安全側に寄せます。

• 暗号化保管: ディスク上に平文の認証情報を残さず、OS のキーストアや GPG で暗号化して保管する。
• 一時認証情報: コマンド実行時のみ、STS による有効期限付きの一時認証情報を発行する。漏えいしても一定時間で無効になる。
• 環境の分離: プロファイル単位でアカウントや権限を切り替えやすくする。

参考: ByteNess/aws-vault（README）
“stores IAM credentials in your operating system’s secure keystore”
（IAM 認証情報を OS のセキュアなキーストアに保管します。）
https://github.com/ByteNess/aws-vault

前提条件と環境

本記事は、以下の環境を前提とします。

• OS: Ubuntu Desktop 22.04 LTS または 24.04 LTS（20.04 LTS は標準サポートが 2025 年 5 月末で終了しているため、新しい LTS への移行を推奨します）
• シェル: Bash または Zsh
• 権限: sudo を実行できるユーザー

AWS Vault は単体でも動作しますが、動作確認や実運用では AWS CLI と組み合わせるのが一般的です。未導入の場合は、関連記事『AWS CLI インストール手順 Windows と Ubuntu』を参考に、先に AWS CLI の導入と aws configure を済ませておくことをおすすめします。

AWS Vault のインストール

開発元である 99designs/aws-vault は開発終了が宣言されており、現在は ByteNess/aws-vault がメンテナンスを継続するフォークとして案内されています。インストールはこの後継フォークのリリースから行います。

参考: 99designs/aws-vault（リポジトリ説明）
“This project has been abandoned and it’s not receiving any more updates.”
（このプロジェクトは開発終了し、今後の更新は提供されません。）
https://github.com/99designs/aws-vault

バイナリの取得と配置

以下は amd64（x86_64）向けの例です。バージョンは固定で指定していますが、最新版は ByteNess のリリースページで確認することをおすすめします。

# バージョンは最新を確認して指定（執筆時点の例）
AWS_VAULT_VERSION="v7.11.1"

# 後継フォーク（ByteNess）のリリースからダウンロード
curl -L -o aws-vault \
  "https://github.com/ByteNess/aws-vault/releases/download/${AWS_VAULT_VERSION}/aws-vault-linux-amd64"

# 実行権限を付与して配置
sudo install -m 755 aws-vault /usr/local/bin/aws-vault

# 元ファイルを削除
rm aws-vault

常に最新版を取得したい場合は、バージョンを固定せず releases/latest/download/ を使う方法もあります。

sudo curl -L -o /usr/local/bin/aws-vault \
  "https://github.com/ByteNess/aws-vault/releases/latest/download/aws-vault-linux-amd64"
sudo chmod 755 /usr/local/bin/aws-vault

ARM 系（aarch64）の場合は、ファイル名を aws-vault-linux-arm64 に置き換えます。

バージョン確認

正しく配置できたか確認します。

aws-vault --version
# 出力例: v7.11.1

パッケージマネージャー（apt の非公式リポジトリや Homebrew、Chocolatey など）経由で導入する場合も、配布元が旧 99designs 版を指していないか、導入後にバージョンと挙動を確認することをおすすめします。

Linux でのバックエンドの選び方

AWS Vault は暗号化そのものを内蔵せず、認証情報の保管を OS 側のしくみに委ねます。macOS は Keychain、Windows は Credential Manager が既定で使われますが、Linux では保管先（バックエンド）を選ぶ必要があります。ここが Ubuntu 環境で最初につまずきやすい部分です。

自動選択とバックエンドの比較

現在の AWS Vault は、Linux で次の順にバックエンドを自動選択します。Secret Service が使える環境では secret-service が選ばれ、見つからなければ kwallet → keyctl → pass → passage → file の順にフォールバックします。バックエンドは --backend フラグまたは AWS_VAULT_BACKEND 環境変数で明示的に指定することもできます。

代表的な 3 つのバックエンドを整理すると、以下のとおりです。

選び方の目安としては、デスクトップ GUI をそのまま使うなら secret-service、追加ツールを入れずに最小構成で始めたいなら file、鍵管理を自分の手元で握りたいなら pass+GPG が候補になります。本記事では、手軽に始められる file と、従来から解説してきた pass+GPG の 2 通りを取り上げます。

参考: ByteNess/aws-vault USAGE（バックエンドと環境変数の一覧）
https://github.com/ByteNess/aws-vault/blob/main/USAGE.md

file バックエンドで手軽に始める

追加のツールを導入せずに暗号化保管を始めたい場合は、file バックエンドが選択肢になります。file バックエンドは、パスフレーズで暗号化したファイルを既定で ~/.awsvault/keys/ 配下に保管する方式で、pass や GPG の事前準備が不要です。SSH 接続先やヘッドレスのサーバーでも使いやすい点が利点です。

# file バックエンドを使うよう設定し、~/.bashrc に追記して永続化する
echo 'export AWS_VAULT_BACKEND=file' >> ~/.bashrc
source ~/.bashrc

この状態でプロファイルを登録すると、保管用のパスフレーズの設定を求められます。以降の登録手順は後述の「プロファイル登録と基本操作」と共通です。

なお、AWS_VAULT_FILE_PASSPHRASE 環境変数にパスフレーズを設定すれば対話入力を省けますが、平文の環境変数に保管することになるため、自動化の必要がなければ対話入力のままにしておくことをおすすめします。

pass + GPG バックエンドの構築

OS のキーリングを使わず、GPG による暗号化で鍵を手元管理したい場合は、pass をバックエンドに利用します。pass は GPG で暗号化したファイルとしてパスワードを管理するツールで、AWS Vault と組み合わせることでアクセスキーを暗号化保管できます。

ツールの導入

sudo apt update && sudo apt install -y pass gnupg

GPG 鍵ペアの生成

暗号化に使う鍵を対話形式で作成します。

gpg --full-generate-key

主な入力項目は次のとおりです。

• 鍵の種類: 既定（RSA and RSA）のままで問題ありません。
• 鍵長: 3072 または 4096 を指定します（長いほど安全側ですが、ここでは 4096 を推奨します）。
• 有効期限: 用途に応じて指定します（0 で無期限）。
• 名前・メールアドレス: 鍵を識別するための情報を入力します。
• パスフレーズ: 鍵自体を保護するパスフレーズです。紛失すると復号できなくなるため、確実に控えておくことをおすすめします。

鍵 ID の確認と pass の初期化

作成した鍵の ID（またはメールアドレス）を確認し、パスワードストアを初期化します。

# 鍵の一覧を表示し、pub 行の長い英数字（鍵 ID）を確認する
gpg --list-keys

# 確認した鍵 ID またはメールアドレスで初期化する
pass init "user@example.com"

Password store initialized for ... と表示されれば準備完了です。

GUI のない環境での注意点

AWS Vault は GPG のパスフレーズ入力時にポップアップを表示しようとするため、SSH 接続や GUI のない環境では Inappropriate ioctl for device などのエラーになることがあります。シェルの設定ファイル（~/.bashrc や ~/.zshrc）に以下を追記し、現在の端末で入力できるようにしておくと回避につながります。

# GPG の入力を現在の端末（TTY）に表示させる
export GPG_TTY=$(tty)

追記後は source ~/.bashrc で反映します。

参考: pass（the standard unix password manager）公式サイト
https://www.passwordstore.org/

プロファイル登録と基本操作

プロファイルの作成とキーの登録

バックエンドの準備ができたら、AWS のアクセスキーを登録します。任意のプロファイル名（例: dev-user）を付けて実行します。

aws-vault add dev-user

対話モードになるため、AWS で発行したアクセスキー ID とシークレットアクセスキーを入力します。現行の AWS Vault では、MFA を併用する場合に備えて MFA デバイスの ARN を入力するプロンプトが表示されます。MFA を使わない場合は空欄のまま進めて問題ありません。

Enter Access Key ID: ********************
Enter Secret Access Key: ****************************************
Enter MFA Device ARN (If MFA is not enabled, leave this blank): 
Added credentials to profile "dev-user" in vault

pass+GPG バックエンドを使っている場合は、この登録時に GPG のパスフレーズ入力を求められます。Added credentials to profile "dev-user" in vault と表示されれば登録完了です。

登録しても ~/.aws/credentials には認証情報が書き込まれません。代わりに ~/.aws/config にプロファイル情報のみが追記されます。

[profile dev-user]
# ここにアクセスキーは保存されません

コマンド実行: aws-vault exec

登録したプロファイルで AWS CLI を実行するには exec を使います。このコマンド経由でのみ、一時的な認証情報が環境変数として渡されます。

# 書式: aws-vault exec <プロファイル名> -- <実行したいコマンド>
aws-vault exec dev-user -- aws s3 ls

実際にどの認証情報が渡されているかは、環境変数を確認するとわかります。アクセスキーが登録した長期キー（AKIA…）ではなく、一時キー（ASIA…）に変わっているはずです。

aws-vault exec dev-user -- env | grep AWS

マネジメントコンソールへのログイン: aws-vault login

login を使うと、そのプロファイルの権限でブラウザが開き、AWS マネジメントコンソールにログインできます。

aws-vault login dev-user

MFA を設定している場合も、コマンドライン上で MFA コードを入力することでログインできます。スイッチロール運用をしている場合は、この方法で切り替えの手間を減らせます。

参考: ByteNess/aws-vault USAGE（exec・login などの使い方）
https://github.com/ByteNess/aws-vault/blob/main/USAGE.md

よくあるエラーと対処

Ubuntu 環境では、GPG の設定やバックエンドの選択に起因するエラーが発生することがあります。gpg: decryption failed や前述の Inappropriate ioctl for device などに遭遇した場合は、GPG_TTY の設定やバックエンドの指定を見直すことで解決することが多いです。個別のエラーと対処は、関連記事『AWS CLI & Vault トラブルシューティング』にまとめています。

AWS Vault の向き・不向き

AWS Vault はローカルの開発環境で認証情報を安全に扱うためのツールです。導入前に、適した用途とそうでない用途を把握しておくと判断しやすくなります。

• 向いている用途: 個人の開発端末でのローカル開発や検証、AWS CLI の手動操作。長期キーを平文で持たずに済ませたい場合
• 不向きな用途: 本番ワークロードや CI/CD・自動化パイプライン。対話的なパスフレーズ入力やキーストアの前提が、かえって運用の妨げになる。

本番環境や自動化では、長期キーを配布せずに済む仕組み（EC2 や ECS に付与する IAM ロール、IAM Identity Center による一時認証、CI 側のシークレット管理機能など）を使うのが基本です。AWS Vault は、手元の開発作業で長期キーの平文保存を避けるための選択肢として位置づけると、役割が明確になります。

また、バックエンドごとに次の制約があります。

• pass + GPG: GPG のパスフレーズ入力が前提となるため、無人実行には不向きです。SSH 環境では GPG_TTY の設定が必要になります。
• file: 暗号化の強度は設定するパスフレーズに依存します。推測されにくいパスフレーズを設定することをおすすめします。

まとめ

本記事では、Ubuntu 環境での AWS Vault の導入と、アクセスキーを暗号化保管するしくみを解説しました。開発元の 99designs 版は開発終了しており、現在はメンテナンスが続く ByteNess フォークを使うのが前提となります。バックエンドは環境に応じて選び、用途は開発環境に絞るのが安全側の判断です。

• 認証情報の平文保存はアクセスキー漏えいのリスク要因
• 現行の入手先はメンテナンス継続中の ByteNess フォーク
• Linux はバックエンドの選択が必要で自動選択順あり
• 手軽さ優先なら file、GUI 環境なら secret-service
• 鍵を手元で管理するなら pass と GPG の構成
• aws-vault exec で一時認証情報を使いコマンド実行
• 本番や CI ではなく開発環境向けのツール

以上、最後までお読みいただきありがとうございました。