実際にやってみた

以下のドキュメントを見ながらやってみた。

https://cloud.google.com/run/docs/configuring/secrets

Secretを登録する

Google Cloudの管理コンソールにアクセスし、シークレットを作成する。

https://cloud.google.com/secret-manager/docs/creating-and-accessing-secrets

今回は諸々の設定はすべてデフォルトのままにした。

サービスアカウントのIAM設定をする

Cloud Runにデプロイを行うサービスアカウントからシークレットを参照できるようにする必要があるらしい。

通常はDefault compute service accountという名前のついているサービスアカウントがデプロイ時に使用される。こいつにSecret Manager Secret AccessorロールをつければOK。

管理コンソールから当該アカウントに権限を付与した。

Cloud Run設定を更新する

以下のコマンドをうち、Cloud Runサービスにシークレットを登録した。

シークレットをCloud Runから読み取る方法としては以下の２パターンが用意されているらしい。

上記のコマンドでは、環境変数として公開している。Node.jsアプリケーションから参照するので、process.env経由でアクセスできると都合が良かったため。今回は使わなかったが、たとえばGoogle Cloudのservice account credentialのJSONファイルなんかはそのままファイルとしてアクセスできたほうが圧倒的に都合が良いだろう。

感想

あまり人に見られたくないアプリケーションの秘密情報は結構どこにでもあるもので、秘密といいながらエンジニアならだいたいだれでもアクセスできるところにおいてあってモヤモヤする運用になっていることがよくある。

従来はアプリケーションの構成の都合そうせざるを得なかったみたいなこともあるのだろうが、これからはSecret Managerのような機能を正しく運用することにより、秘密情報をちゃんと秘密に扱う（より詳細な権限管理を行う）ことが当たり前になるだろうなとおもった。

バージョンの概念が存在しているあたり、人の入れ替えのようなイベントが発生した時点でちゃんとシークレットを更新して古い記憶を無効化せよという意志が感じられた。

便利な世の中になった。