Cloud Workstationsを構築する際の考慮事項を整理してみた #cm_google_cloud_adcal_2024

クラスメソッドのGoogle Cloud Advent Calendar 2024
#Google Cloud (GCP)
#Cloud Workstations
suto
2024.12.12
データ事業本部のsutoです。

この記事はクラスメソッドの Google Cloud アドベントカレンダー2024 の12日目の記事です。
プロジェクトメンバーの開発環境としてCloud Workstationsを導入する場合、どのような機能があってどのような考慮事項があるのかを整理してみました。
Workstationsの導入を検討するにあたって、「開発環境の利便性としてどのくらいなのか」、「自組織のセキュリティ基準と照らし合わせてどこまでの制御ができるのか」などを一定まで判断する際の参考になればと思います。
 Cloud WorkstationsとはCloud Workstations は Google Cloud において、マネージドなリモート開発環境を提供するサービスです。
Cloud Workstations を開発環境として利用することで、以下のようなメリットがあります。
一貫した開発環境を共有でき、開発者ごとでライブラリの有無やバージョンに差が生じることがなくなる。
ローカルに開発環境を準備することなく、必要なときにすぐに環境を用意できる。
環境へのアクセスはIAMによる認証認可があり、Provate Service Connect経由でVPC 内に Compute Engine VM インスタンスとして作成されるため、セキュアな環境が構築できる。
利用イメージとして、コンテナで稼働している開発環境(Visual Studio Code 等)にブラウザでIDE を開いて利用します。
よって、Amazon Workspacesのような仮想デスクトップサービス(DaaS)とはコンセプトが違うサービスです。
 アーキテクチャWorkstationsのアーキテクチャは以下の図の通りで、主に以下のポイントをおさえていればいいと思います。
GoogleのマネージドネットワークにあるWorkstationsクラスターのコントローラとゲートウェイにIAMによる認証認可を用いて接続
Workstationsのインスタンスへは、Provate Service Connectを経由したプライベート通信となる
インスタンス起動時に永続ディスクを接続するので、コンテナとのセッションを停止しても内部のデータとファイルを保持できる
Workstationsのコンポーネント（リソース）は主に以下の3つです
クラスター(Cluster)：
後述のconfigrationとWorkstationをグルーピングするもので、どのリージョン、VPCサブネットに配置するかを設定
ユーザーはクラスターのGatewayとControllerを通してworkstationに接続できる

構成(configuration)：
後述のworkstationの起動テンプレートで、コンテナイメージ、マシンタイプ、ディスク、サービスアカウントなどを定義

インスタンス(workstation)：
configurationをもとに作成される開発環境

 要件ごとの整理まずは以下の要素ごとにCloud Workstationsの機能を整理してみました。
 ネットワークパブリッククラスター
クラスターへのアクセスは外部のどこからでも可能
VPC-Service Controls(VPC-SC)はサポート外のため、利用するにはWorkstations APIをVPC-SCから除外する必要がある
プライベートクラスター
クラスターへのアクセスはプライベート通信である必要がある（Cloud VPNやCloud InterConnectの構成が必要）
VPC-SCのサービス境界内でも利用可能のため、ネットワークはセキュアな閉域網として構築可能
具体的な構築手順はこちら
 セキュリティIAMを使用したアクセス制御
リソースの作成／削除などの操作(Workstations API)に対するユーザー権限をIAMで制御
Workstations APIのアクセス制限
(2024/11/25時点でプレビュー)Access Context ManagerとChrome Enterprise Premiumを使った設定
コンソール操作やgcloudコマンド実行に対して制限が可能(IP制限、デバイス制限、地域制限など)
VPCにおけるファイアウォールルール関連
インスタンスの通信は、VPCのファイアウォールで制御可能
最低限、クラスターのControllerの外部IPとの通信は許可する必要がある

インスタンスから他リソースへのアクセス
インスタンスに設定するサービスアカウントで制御
インスタンスへの直接ssh
インスタンスへ直接SSHを設定することが可能
ベストプラクティスでは設定をOFFにすることを推奨

インスタンスからの外部アクセス
インスタンスのパブリックIP付与の有無を設定できる
ベストプラクティスでは設定を無効化することを推奨
外部通信が必要な場合、限定公開のGoogleアクセス or Cloud NAT使用の検討を行う

VPC-SCによるGoogle APIへのアクセス

- VPC-SCを構成することでアカウントの組織ポリシー方面からのアクセス制御も併せて実施
Compute Engine のセキュリティオプション
要件によって、Shielded VM、Confidential VMの設定が可能
暗号化
暗号化は「Google が所有および管理する鍵」または「Cloud KMSによる顧客管理の暗号鍵」のどちらかを使用可能
ベストプラクティスでは、最小権限の原則をより適切にサポートするために、Cloud KMSリソースとCloud Workstations リソースを別々のプロジェクト内に保持することをおすすめしている(参考)
 コンテナイメージベースイメージ
Code-OSS で構築されたベースエディタ
ターミナル画面では、gcloud、docker、git等のコマンドがデフォルトで利用可能
開発環境としてVisual Studio Code(VS Code)を利用
ローカルのVS Codeと接続して開発が可能

JetBrains IDE ベースのエディタ
IntelliJ IDEA や PyCharm など、各プログラム言語用に構成されたコンテナイメージが用意されている
ローカルの JetBrains IDE を使用してコードを開発が可能

カスタムイメージ
ベースイメージの環境では足りない拡張機能などをユーザーでカスタマイズしたコンテナや外部のコンテナを利用可能
コンテナのイメージ更新、パッチ適用、コンテナ内にインストールしたツールのセキュリティ対策はユーザー自身でメンテする必要がある
コンテナイメージの管理やビルドの自動化をCloud Build、Artifact Registryで構成しておくことをおすすめする

 インスタンスの運用インスタンスの作成
オプション「Limit number of created workstations per user」で、1ユーザーが作成可能なインスタンス数の上限を設定することができる
(2024/11/25時点でプレビュー)インスタンスを指定してクローンを簡単に作成することも可能
作成したインスタンスの構成変更
作成済みのインスタンスであっても、停止中にconfigでマシンタイプを編集すると即時設定が反映される
ディスクの追加、ストレージのサイズ変更は、作成時の設定を変更することはできない
クイック スタート ワークステーション
通常モードではインスタンス起動に数分必要だが、この設定をしておけば、早い場合は 10 秒ほどで起動状態とすることが可能
オンにすると、通常起動している状態と同等の料金が発生する
自動スリープ
一定時間どのユーザーにも操作がなかった場合自動停止することができる(15分～12時間)
自動シャットダウン
インスタンス起動したタイミングを軸にセッションの有無に関係なく強制停止することができる(6時間後～24時間後)
VS codeの拡張機能
外部アクセスとして Open VSX Registryから検索してインストール可能だが、拡張機能への信頼性はユーザーでチェックし判断する必要がある
Googleでは open-vsx.org の運用や、ホストされている拡張機能の検証は行わないため

インスタンスのイメージ更新とパッチ適用
ベースイメージでは、インスタンスの停止→再起動のタイミングで最新に更新される仕様
永続ストレージの削除ポリシー
インスタンス削除時、アタッチしていた永続ディスクを一緒に削除するか保持するかを選択可能
 ログ監査ログ
Cloud Audit Logsで記録可能
ディスクやインスタンスの割り当てといった「ユーザー定義の監査ログ」も設定可能(ただし課金対象)
コンテナの出力ログ
Cloud Logging に送信される
VPCフローログ
Workstationインスタンスのトラフィックを記録する目的としても、VPCフローログをオンにしておくと良い
 最後に利用者ごとの要件は様々あると思いますが、

セキュリティのベストプラクティスにある以下の項目について、なるべく設定することを推奨します。
インスタンス(workstation)のパブリックIP付与を無効
外部アクセスルートは、必要に応じて「限定公開のGoogleアクセス」「Cloud NAT」「別のネットワーク経由のルーティング設計」を検討

インスタンス(workstation)への直接sshの無効
クラスターとのトンネル経由で接続などの方法を利用する方針で検討
VPCフローログを有効化

VPC-SCでGoogleサービスを制限
workstationはサービス境界の外となるので、境界内のサービスへのアクセス制御VPC-SC側でも設定しておく

ユーザーのIAM権限を最小限に設計にする

　- 開発環境の利用のみのユーザーとworkstations環境の管理者で役割を分けて、それぞれに必要最低限の権限のロールを付与
カスタムイメージ更新のパイプラインを構築する
カスタムイメージを使う場合、コンテナイメージの再ビルドの自動化、コンテナ内の安全性チェックの仕組みを設定し運用

Cloud KMS の権限
Separation of duties(職掌分散)にもとづいて、なるべくCloud KMS リソースと Cloud Workstations リソースを別々のプロジェクトに保持

以上
明日12/13はhanzawa.yuyaさんです。よろしくお願いします！