概要
本記事はパスワードマネージャーサービス 1Password で2025年に使ってみた/試してみた機能の紹介です。全体的に
- クレデンシャルを外部保存させない機能
- クレデンシャルを円滑に外部連携する機能
の拡充が進んだ印象でした。
本記事では以下の3機能について記載します。
- Service Accounts
- Environments ※ β版
- Shell Plugins ※一部 β版 CLI 利用が必要
なお、本記事は2025年11月時点での情報を元にしています。特にβ版の内容は本記事の内容と参照時点の内容で異なる可能性があります。
補足:1Password(パスワードマネージャー)について
システムを扱っていると必ずクレデンシャルの管理が必要になります。システムの利用者としても
- ID
- Password
- ワンタイムパスワードのコード
- PassKey
- など
があり、システムの開発・運用者になると、上記に加えて
- 管理者等の特別な権限に対して必要な情報
- システムが内部的で利用している情報
- 環境変数
- サービスのAPI Key
- など
これらがシステム×環境数分あり、切り替えて使う必要があります。人間の記憶に残すには多すぎる情報でどこかに保存するしかないでしょう。
管理情報が多くなると単純なパスワードを使ったり、認証情報を使いまわすケースも出てきます。本記事では触れませんが、1Passwordにはパスワードジェネレーターや、Watchtower(パスワードの使いまわし、多要素認証・パスキーが使えるのに使っていないなど)によるセキュリティスコア評価機能もありますし、組織用途の監査などの機能もあります。
管理のみであれば極論、認証認可、履歴管理のある近年のファイル共有サービスを使っても実現可能です(実際、一部のOSSの同種のツールは共有のためのバックエンドをそうしていた記憶があります)。しかし、クレデンシャルを利用するツール/サービスからの連携が円滑にできなければ単純に使いづらいですし、人手を挟むことによるミスも起こりえます。1PasswordはブラウザからSSH鍵、シェルのCLI、サービス間連携など、連携機能を拡張することで安全性と利便性のを同時に高める取り組みをしていると思います。
名前は「パスワード」マネージャーですが、セキュリティの三要素を考慮してクレデンシャルを適切に管理するためのツールだと個人的には考えています。
Service Accounts
機能概要
名前の通りの機能で、主にツール/サービス間連携のために使われるアカウントです。詳細は公式ページの
を参照してください。
ざっくり言うと Google Cloud のサービスアカウント (特定の Google アカウントに紐づかず、権限付与ができて、認証情報が払い出せるアカウント)に近いものだと思っています。
現状ステータス: 利用中
リリース当初はサービスアカウントが参照できる保管庫(クレデンシャルのグループのこと。英語表記で Vault )の数や付与できる権限に制約があった記憶ですが、現状あまり問題ない範囲の制約になっていると思います。
業務では主に後述する 「Environments」 で機能提供される 1Password -> AWS Secret Manger 方向のクレデンシャルの同期に使っています。1Password が 1Password/load-secrets-action という Actions を提供していることもあって、同期のバッチとしてGitHub Actions を利用して実現しています。
GitHub と AWS の間は OpenID Connect によるものなので、認証情報を GitHub 上に保存する必要がないのですが、Service Accounts を利用した場合は Service Accounts の認証情報を GitHub 上(GitHub Secrets)に保存する必要があります。このユースケースのセキュリティ向上のための開発が進んでいる状態だと思われます。
Environments
2025年11月時点では β版の機能です。最新の情報は公式ドキュメントを参照してください。
機能概要
1Password CLI と先述した Service Accounts を使うと 1Password とツール/システムの自動化が可能なのですが、Service Accounts ではどうしても認証情報をどこかに保存する必要があります。また、
公式にもあるように、現状提供されているのは以下2機能のようです。
-
AWS Secrets Manager との SAML 連携による 1Password 上のクレデンシャル同期
- サービス間のSAML連携でユーザ/サービスアカウントなどの認証情報不要なのがポイント
-
端末上の .env ファイル管理
- ローカルにファイルがなくてよいというのがポイント
知ったきっかけ
元々端末上の .env ファイルは 1Password CLI の Secret unique identifiers を使って op://~ の形式でファイルに記載し、 op run --env-file foo.env で埋め込んで利用する方法を採用していました。
公式の設定ファイルのチュートリアルの例に倣うと以下のように aws.env を
AWS_SECRET_ACCESS_KEY=op://prod/aws/secret-key
AWS_ACCESS_KEY_ID=op://prod/aws/access-key
作成し
op run --env-file aws.env -- target.sh
で実行します。
これでも大分便利なのですが、場合によっては値の埋め込みが必要なケースもあり、値が埋め込まれた .env がローカルに残ったり、 .gitignore の設定が不十分なレポジトリではコミットされかけたりという問題がありました。
SSH鍵などはローカルにファイルを置かず、1Password上だけで対応できるようになっているので、同様のソリューションがないかと調べていたのがきっかけです。
現状ステータス:情報収集・検証のみ
β版の機能の時点で職場のセキュリティーポリシー的に採用にはならないのですが、多少不便さがあっても代替手段があるので、導入検討にはまだしばらくかかりそうな印象でした。
- AWS Secrets Manager との SAML 連携による 1Password 上のクレデンシャル同期
- 「Service Accounts」 の項目で書いた自前の仕組みがあるため
- 端末上の
.envファイル管理- (慣れたメンバー/プロジェクトであれば) 現状で大きく問題が出ていない
ただ、 .env ファイルの管理に関しては個人開発では使っていこうと思います。
-
op://~の URI を人が読んで理解できる形式にするには 1Password のエントリの記載を英語で書いていかないといけない(微妙に所々でこの制約がある) - 1Password のエントリの記載を自由に記載すると
op://~側の記述だけ見てもなんの情報かよく分からず、時間が経つと調べなおす(結果、値を埋め込んだファイルを作ってしまうことも)
と、現状多少やりにくいことがあるので。
Shell Plugins
2025年11月時点では β版の 1Password CLIでしか利用できない Pluign があります。β版が必要なものは公式ドキュメントのプラグイン詳細ページのタイトルに「Beta」の記載があります。そちらを確認して利用してください。
Use 1Password Shell Plugins to securely authenticate any CLI - 1Password Developer
機能概要
1Password 上にあるクレデンシャルを CLI をユーザからは通常のコマンド実行で受け取って実行ができるようにする機能という理解です。
内部的には 1Password CLI + plugins.sh というシェルを利用してコマンドにクレデンシャルを渡すブリッジを作り、最後に元のコマンドにエイリアスを作成する ( op plugin run -- commandX )という内容になっています。
知ったきっかけ
諸事情で現在 AWS CLI の認証に使っている MFA の見直しが必要になり、 OTP の利用方法の再検討が必要になりました。AWS CLI でも
- MFA ディバイスと OTP を指定して一時クレデンシャルを取得する
- 上記で取得した一時クレデンシャルを元にコマンドを実行
という2ステップを踏むことで対応が可能なのは知っていました(参考: AWS CLI を使用して MFA トークンで AWS リソースへのアクセスを認証する方法を教えてください。 - AWS re:Post )。加えて、以下の点から何かしらの補助ツールを整えないといけないなとは思いました。
- MFA ディバイスの ARN が必要 = 人によって違う設定が必要
- OTP 入力の必要がある = Authenticator を参照する必要がある(ちょっと面倒)
そこでツールを探している中で 1Password Shell Plugins の AWS CLI 対応を発見したという次第です。
困りごと その1: 公式の Shell Plugins は提供コマンドすべての ON/OFF しか対応していない
「このコマンドは1Password Shell Pluginを使いたいが、このコマンドは使いたくない」という個別適応要件への対応が提供されていません。
公式ドキュメントには
- Open your plugins.sh file file.
- Remove the alias for the plugin you want to stop using. For example, alias aws="op plugin run -- aws".
- Save the file.
- Open a new terminal window or source your shell profile for the change to go into effect.
Shell Plugins > Guides > Temporarily stop using a shell plugin - 1Password Developers
と、1Password 提供の plugins.sh を直接編集するように案内があります。
バージョンアップなどで元に戻ってしまう可能性もあり、トラブルシュートが面倒になりそうな方法でした。
GitHub 上でも以下のような issue が起票されていました。
発端としては alias を使うと別途設定を追加しないとシェルの補完が効かなくなってしまうという問題です。例えば zsh だと上記の issue でも言及があるように setopt completealiases の追加が必要です。上記 issue も 2024年2月に Open されて 2025年11月 時点でクローズされていません。ユーザ側で何かしらのワークアラウンドを取る必要がありそうです。
同 issue ではalias を使う代替手段としてシェルの関数を利用する方法を記載しています。例えば bash/zsh で AWS CLI だけ元のコマンドを利用したければ以下を設定ファイルに記載する想定です。
aws() { command aws "$@" }
command コマンドでエイリアスやシェル関数で上書きされた設定を無視して元のコマンドとして呼ぶということですね。
Shell Plugins が読み込まれている状況でも
command aws ~
で呼び出せば元々の AWS CLI が呼び出せはしますが、スクリプト中にある内容だと記述の変更も必要ですし、あまりよい方法でもないかなとは思いました。
困りごと その2: 利用したいサービスで β版の 1Password CLI を使えなかった
この問題は時間が経過すれば対応されるはずなので、あくまで「2025年11月時点で」という話です。
具体的には Terraform がそうだったのですが
- Shell Plugins を使うためには β版の 1Password CLI を利用するのがセキュリティーポリシー的にネック
- Stable版の Shell Plugins で対応するワークアラウンドが Shell Plugin を使わない場合とあまり変わらないような手数
ので、まだ使い時ではないのかなと判断しました。
現状ステータス:利用見送り
2025年11月時点では Shell Plugins の導入は見送りました。
Shell Plugins は導入による利便性よりもトラブルシューティングが増えそう、また、トラブル発生時の切り分け考慮点が多くなりそうという観点からです。
また、この検討の後に aws login コマンドがリリースされて代替手段が確保できそうだというのも理由です(参考:Simplified developer access to AWS with ‘aws login’ - AWS Security Blog )。
おわりに
1Password で2025年に使ってみた/試してみた以下3機能について書きました。
- Service Accounts
- Environments
- Shell Plugins
Service Accounts は Environements が正式版になったら AWS Secrets Manager との連携箇所はリプレイスの検討。
.env ファイルの管理は個人開発で試してみて Environments が正式版になったら導入を検討。
Shell Plugin はまだしばらく様子見(困りごと その1 の話でどのみちワークアラウンドを作らないといけないので)。
という状態になりそうです。
参考・関連記事
AWSでお世話になっているクラスメソッド社の記事を参照することが多いので記載します。
-
1Password Environmentsで.envファイルを管理できるようになったので試してみた:Environmentsで
.envを管理する例 - 1Password CLIのShell PluginsでAWS CLIやAWS CDKの操作をするまでのステップを整理してみた:Shell Plugins でAWS CLI と AWS CDK の対応をした例
- zshでawsコマンドをエイリアスに設定したらAWS CLIのタブ補完が効かなくなった!その解消方法:Shell Plugins の困りごと その1の一部の話。公開時期が同時期で驚きました
かなりの量の記事があるので、昔は代理店をしているのかと勘違いしていたのですが代理店ではないんですよね。職場で代理店を通すようにコーポレート部門から依頼を受けて調査した時に知りました。