ローカルに秘密情報を置かないという選択 – 1Password CLIで実現する安全な.env運用

これまでずっと導入を迷っていたのだけど、昨今のサプライチェーン攻撃を重く受け止めた結果、1Passwordを契約してしまった。3年間で1万円だった。 色々考えたが、もう1Passwordを買うしかなかったと言える。

最近のサプライチェーンがやばすぎる件

最近、と書いたが、実のところ特に最近始まったことでもなく。 詳しくはこちらの記事をご覧いただきたい。

サプライチェーン攻撃への防御策 | blog.jxck.io https://blog.jxck.io/entries/2025-09-20/mitigate-risk-of-oss-dependencies.html

結局、OSSを日常的に利用している以上、いつだってこういうリスクには晒されていたのだったが、昨今のAIを利用した開発のスピードの速さに伴って、コードを真剣に読むことが昔ほど多くなくなってしまった自分の現状も鑑みて、備えを十分にしたほうが良いと改めて思い至った形である。

まあ、これまで.envファイルにシークレット情報を平文でバチバチに書きまくっていた状況に疑問や不安を感じなかったといえば、そんなこともないのだが、いつの間にか日常になって気にならなくっていた。

クラウドサービスのパラメーターストアみたいな感じで使える

それで、1Passwordを使えば何が便利かというと、1Password CLI( op )というソフトウェアを使うことで、クラウド上のパラメータストアみたいな感じで1Passwordを利用することができる。

コードの中に埋め込み用のプレースホルダを用意して、プログラムの実行時にのみ、そこに対してopを通してシークレット情報を流し込む運用をすることで、ローカルの中に一切のシークレット情報を持たないようにするのである。

.envファイルに対して下記のようなプレースホルダを記述し

# .env
SECRET1=op://vault-name/item-name/section-name/api-key1
SECRET2=op://vault-name/item-name/section-name/api-key2

下記のような形で実行する

$ op run --env-file=.env -- python app.py

これによって.envファイルは特にシークレット情報ではなくなり、GitHubなどに上げてしまっても良いものになる。（さすがにPublicで上げるのは気持ち悪いし、1Passwordの内部構造を晒すことになるので非推奨ではある。）

1Password自体はそれをインストールしている端末であればどこからでも利用できるものであるので、自分のアカウントでログインしていれば、どの端末でもこの .env ファイルを同じように利用できる。（各端末で op signin による認証は必要）

AI時代のセキュリティ意識

AIの進歩でコードレビューの支援は強化されつつあるが、AI自身が不正コードを生成するリスクもあるため、完全な防壁にはならない。

それに、実は上記の方法でも完璧とは言い難い。冒頭で紹介した記事にも書かれている通り、もっと固くしようと思えば、プロジェクト環境自体をコンテナで運用しつつ、コンテナの起動時にopを使ってシークレット情報を流し込むというものになると思う。

ただ、コンテナを使って開発するというのもなかなか面倒だ。なにかパッケージを一つ追加で入れるたびにリビルドしないといけない。

というか、サプライチェーンの問題を真剣に受け止めると、brewやaptでインストールするソフトウェア全般に警戒しなければならず、考えれば考えるほど仮想環境層を挟まないと何もできない事になってしまい、それはちょっときつすぎる、ということで折衷案として、ローカルには決してシークレット情報を置かない運用というものを考えた結果が今回の記事の内容になる。

皆さんにおかれても、より良い方法があればぜひ教えてほしい。