Cloud Runでテストサービスを構成したメモ

Cloud RunにSeleniumベースのテストサービスを構築した(先日のDocker作成)

で、本番環境で動かす時にこのサービスは非公開だけど非公開のRunって初めて構成したのでセキュリティをどうするのかと検討。

このサービスの呼び出し元はアプリビルド時の動作確認と、定期ヘルスチェックの2つ。 Cloud Build&Schedulerってことで、Google Cloud内部なのでIAMとかで簡単に構成できる気がする。

Cloud Runの設定でセキュリティタブに認証項目がある。

認証が必要
Cloud IAM を使用して承認済みユーザーを管理します。

うん、この設定ならIAMで認証できて中に認証とか組む必要ないね。

では、これはどう動くのか?
一言で言ってAuthorizationヘッダーで適切な権限のあるトークンが与えられることを確認している。

Schedulerの場合は簡単、スケジュールの設定で「実行内容を構成する」にあるAuthヘッダーの項目で「OIDCトークンを追加」を選択して「Cloud Run起動元」の権限があるSAを選択すれば勝手にやってくれる。

 Buildの場合は、gcloudコンテナのbashエントリーポイントで gcloud auth print-identity-token を実行すればトークンが取得できる。
 複数のステップで共有する場合はWorkspaceを使って保存して使い回すと早い(Googleのコンテナで/workspace/配下はビルド実行中に引き継げる一時ストレージなので、トークン取得ステップで
gcloud auth print-identity-token > /workspace/token.txt
とかすれば、以降のステップでは /workspace/token.txt を取得すれば良い)
 一つのステップの中だけで完結する場合は変数に入れて、
token=$(gcloud auth print-identity-token)&&curl -H “Authorization: Bearer $token”
みたいな感じでAuthorizationヘッダを付加して叩いてやれば良い。 Googleのドキュメントにあるサンプルは大文字TOKENだけど、Buildでは$大文字はBuild自体が置換するのでそんなの無いよエラーを吐くので、小文字でなければならないところは注意。
 BuildのSAに「Cloud Run起動元」の権限を付与しておく(今回はRunをデプロイするためにRun管理者のロールが付いていたので追加付与は不要だったが、Run以外をデプロイするだけのSAとかの場合は必要)

 オンプレとかだと鍵認証とかを自分で組み込んだりする必要が出るけど、クラウドの場合はこういった権限管理の仕組みがあるから手軽に実現できて良いね。

 開発段階でテストを実行したい場合・・・通常ならWebに対するテストは開発リポジトリにpushしたらトリガで開発にデプロイして、テストを起動して結果確認となるので、開発用Buildトリガを仕込んで、条件を開発ブランチにpushされた時にして、cloudbuild.yamlで普通に開発環境deployまで実行して、その後にテストを叩くステップを入れてやる。
 deployまでだとビルドの結果はデプロイが成功したかっていう状態だけど、テストステップを追加すればdeployした結果テストが通ったかっていうアプリケーションレイヤーでの成功を一目で確認できる。

(4)


カテゴリー: LAMP[Linux, Apache, MySQL, PHP]   パーマリンク

コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です