C#で開発していて、DBの接続情報、トークン、各種URLを設定ファイルへ書いていました。GitHubでソース管理し、PRを使う運用へ変えるなら、このままではまずいと思いました。
プライベートリポジトリなら大丈夫、と言い切れません。万が一漏れたとき、接続文字列やトークンまでそのまま見えてしまいます。モロバレです。まずい。
そこで、ローカル開発で使うDB接続情報やデバッグ用トークンを、.NET の User Secrets へ分けました。
GitHubとPR運用を始める前に、設定を分けた
GitHubでソース管理し、PRを使うことで、生産性が劇的に上がるとまでは思っていません。私の体感では微増です。
それでも、履歴とレビューを残せるため、運用は少し安定します。モダンな形にしておけば外部の人を招きやすいし、プロジェクトを離れた人が別の現場へ行ったときにも困りにくい。巨人の肩に乗るような感覚で、一般的な開発フローへ寄せておきたかったのです。
ただし、ソースを共有する範囲が広がるなら、設定も見直さなければいけません。リポジトリに置くものと、個人の環境に置くものを分けました。
このプロジェクトでの置き場所
設定をすべて User Secrets に寄せたわけではありません。値の性質と、どこで使うかで分けています。
| 置き場所 | 置いているもの |
|---|---|
| appsettings.json | 各種テンプレートの相対パスなど、定義として変わらないもの |
| 環境変数 | 個人ごとに割り当てた外部ライブラリのID・トークン・ハッシュ値、コマンドでリリースするための環境ごとの定義 |
| User Secrets | デバッグで使うDB接続情報やトークン |
環境変数の中にもトークンのような機密情報はあります。環境変数だから安全、という意味ではありません。リポジトリへ書かず、環境ごと・個人ごとに分離して扱うための置き場所です。
appsettings.jsonには、誰が使っても変わらない定義だけを残しました。ここに接続情報まで混ぜると、設定の変更なのか秘密の値の変更なのかが分かりにくくなります。
User Secrets でやったこと
User Secrets は、開発中の秘密情報をプロジェクトツリーとは別のユーザープロファイルへ置く仕組みです。プロジェクトには UserSecretsId を持たせ、値そのものはソース管理に入れません。
導入時は、公式ドキュメントにあるコマンドを実行しました。
dotnet user-secrets init
dotnet user-secrets set "<キー名>" "<開発用の値>"
dotnet user-secrets list
私が分けたのは、デバッグで使うDB接続情報とトークンです。ソースに値を書かないだけでも、PRの差分やリポジトリの閲覧時に余計な緊張をしなくて済みます。
一方で、User Secrets は秘密情報の保管庫ではありません。Microsoft Learnにもあるとおり、値は暗号化されず、開発用の仕組みです。環境変数も一般に平文で保持されます。本番環境やCI/CDの秘密情報まで、同じやり方で済ませるつもりはありません。
このあたりは、公式の User Secrets の説明 と ASP.NET Core の構成 を確認しました。公式の仕組みをそのままなぞるのではなく、今のプロジェクトでどの値をどこへ置くかの判断材料として使っています。
分けてみて分かったこと
User Secrets を入れたことで、秘密の値をソース管理から外せました。これは一歩前進です。
ただ、最初のクローン時に必要な環境変数や接続文字列を自動で作る仕組みは、まだありません。新しく参加する人には、必要な値を渡し、手作業で設定してもらう場面が残ります。
ここは User Secrets 単体の問題ではなく、初回セットアップ全体の問題でした。実際の秘密の値までリポジトリから配ることはできません。
次にやるなら、リポジトリにはキー名と設定手順だけを置き、実際の値を渡す経路は別に管理したいです。そのうえで、セットアップ用のスクリプトや検証コマンドで「必要な値がそろっているか」だけを確認できるようにする。
いまは、秘密をリポジトリへ戻さずに、初回セットアップの手作業をどこまで減らせるかを考えています。
コメント