WSLで1Password CLIを安全に使う

WSL内の開発コマンドへ1Passwordの値を渡したいとき、最初に迷うのはWindows版のop.exeを呼ぶか、Linux版のopを使うかです。ここを曖昧にしたまま設定を共有すると、認証の場所、パス、標準入出力の境界が増えます。

この記事では、WSLでLinuxの開発ツールを実行する前提で、Linux版の1Password CLIを使う構成を調べる。確認したのは、公式の導入手順、op runとop readの使い分け、OTP属性の読み取りです。CLIを使えば秘密が自動的に安全になる、という意味ではありません。

まず実行するOSとCLIをそろえる

1Password CLIの導入ガイドは、WindowsとLinuxでインストール手順を分けています。WSL内のプロセスへ値を渡すなら、まず次の対応で考えると境界を説明しやすいです。

コマンドを実行する場所	基本のCLI	確認すること
PowerShellやWindowsアプリ	Windows版	Windows側のPATHと認証状態
WSL内のBash、Zsh、開発ツール	Linux版	WSL側のPATHと認証状態

WSLからWindowsのop.exeを呼ぶ構成が常に不安全ということではありません。ただし、Windows側のセッションをLinux側のプロセスへ橋渡しする設計になるため、チームで再現する手順が増えます。まずは実行環境と同じ側のCLIで認証できることを確認し、連携が必要な場合だけ別構成を検討します。

導入直後に確認する範囲

インストール後は、秘密の値を表示せず、CLIのバージョンと認証主体だけを確認します。

op --version
op whoami

op whoamiが失敗したときに、すぐ設定ファイルをコピーするのは避けます。デスクトップアプリ連携がWSLで期待どおり使えるかは環境に依存するため、まずLinux側の公式認証手順を確認します。自動処理では、個人のセッションを流用するより、用途を限定したサービスアカウントを検討します。

開発プロセスには`op run`を使う

スクリプトで秘密を使う方法では、secret referenceを含むテンプレートから実行時だけ環境変数を作る方法が説明されています。設定ファイルには実値ではなく参照を置きます。

DATABASE_URL=op://Development/App Database/url
API_TOKEN=op://Development/App API/token

実行時にだけ解決します。

op run --env-file=.env.tpl -- pnpm dev

この方法は、平文の.envを生成して作業ツリーへ残す時間を減らせます。ただし、子プロセスが環境変数をログへ出力すれば漏れる。set -xを有効にしたシェル、デバッグログ、例外レポートも確認対象です。op runは漏えい経路を消すのではなく、値の存在する場所と時間を狭める手段と捉えるのが正確です。

単一の値には`op read`を使う

1つの値を標準入力で受け取れるコマンドなら、op readを使う方が引数へ埋め込むより扱いやすいです。

op read "op://Development/App API/token" | some-command --token-stdin

コマンドが--token VALUEしか受け付けない場合、値がプロセス一覧、シェル履歴、デバッグ出力へ残る可能性があります。標準入力、環境変数、専用のcredential helperのどれを受け付けるかを、呼び出すコマンド側の仕様で確認します。

TOTPではURIと現在値を分ける

otpauth:// URIには、ワンタイムパスワードを計算する共有シードが含まれます。短時間で変わる6桁のコードより長期的な秘密であるため、ログ、Issue、チャット、画面共有へ貼りません。

現在のコードだけが必要なら、op readのリファレンスにあるOTP属性を読みます。

op read "op://Private/Service Login/one-time password?attribute=otp"

Vault、項目名、フィールド名は実際の保管内容に合わせます。otpauth:// URIを取り出すのは、認証器の移行や復旧など、目的と保管先を決めた作業に限定します。

失敗したときに値を表示しない

認証が通らないときは、秘密そのものではなく、次のような状態を確認します。

実行しているopがWindows版かLinux版か
op whoamiが示すアカウントとVaultが想定どおりか
secret referenceのVault、項目、フィールド名が正しいか
set -xやデバッグログが無効か
子プロセスが環境変数を記録していないか

echo $SECRET、env、コマンド引数へ値を埋めた実行は、確認のためでも避けます。すでにログや履歴へ出た疑いがあるなら、履歴を消すだけでなく、先に該当する秘密をローテーションします。

この構成の範囲

WSL内のLinuxプロセスだけを対象にするなら、Linux版CLI、op run、標準入力という組み合わせで経路を説明しやすいです。WindowsアプリとWSLの両方で同じVaultを使う場合は、認証方式とプロセス境界を別途設計する必要があります。

結局、1Password CLIの目的は秘密を簡単に取り出すことではありません。必要なプロセスへ、必要な時間だけ、監査できる経路で渡し、値を表示・保存・再利用する機会を減らすことです。