はじめに

DX開発事業部の田村です。
2026年10月7日、Cloud Run の SSH が Preview になりました。

Cloud Run release notes  |  Google Cloud Documentation
Google Cloud Documentation

4月の Next ’26 のレポートで紹介した、動いているコンテナに gcloud で入れる機能です。

【Google Cloud Next '26】Cloud Runが大幅進化！注目アップデートを徹底紹介
DX開発事業部 フルスタックセクションの田村です。Google Cloud Next 2026 のイベントレポートを現地よりお届けいたします。今回は「What's new in Cloud Run」セッションを聴いてきました。Cloud Runのプロダクトチームに加え、Replitのエンジニアリング副社長Scott Edward氏、そしてAnthropicのエンジニアMimi氏が登壇するという珍しい構成でした。Cloud Runの今の立ち位置セッションは「Cloud Run gives you on-demand computers」という一文から始まりました。10秒で0から1万コンテナまでスケールアップ、使った分だけ100ミリ...
iret.media

実際に稼働中のCloud Runインスタンスに接続して、その使用感の確認や業務でのユースケースを整理しました。

TL;DR

TL;DRまとめ グラフィックレコーディング

Cloud Run SSH とは

接続は IAP の TCP 転送を通り、認証は OS Loginを使用しています。sshd などはセッションの間だけコンテナに追加されます。

Troubleshoot Cloud Run with SSH  |  Google Cloud Documentation
Google Cloud Documentation

リソース SSH
サービス（第2世代） 使える。--ssh で有効にする
Cloud Run Instances 使える。最初から有効
サービス（第1世代）、ジョブ、ワーカープール 使えない

ただ、ロールにはジョブ用の権限（run.jobs.sshRoot）があり、gcloud にも alpha 版の隠しコマンド gcloud alpha run jobs ssh が入っていました。

⚠️ 試してみましたが、2026年10月13日時点ではつながりませんでした。
gcloud がジョブの設定を読み取れず、トンネルも bad destination or port で拒否されます。

今後、対象が広がるのかもしれません。

そのほかの制限は次のとおりです。

  • セッションは最大24時間。操作がないと1時間で切れる
  • 料金は下りの通信量。SSH の間はインスタンスを動かし続けようとするので、その分もかかる
  • インスタンスが0台なら、SSH のために起動する

検証環境

Cloud Shellから、東京リージョンの2つのサービスを作成して接続してみました。

サービス 中身
sshverify-slim python:3.12-slim で python3 -m http.server を動かすだけに使用します。
環境変数と、Secret Manager のダミー値（環境変数とファイル）を設定
sshverify-distroless 公式サンプル cloudrun/container/hello。シェルも ls も無い最小イメージとなっています

やってみた

有効にして入る

gcloud beta run services update sshverify-slim --ssh

--ssh で有効化した直後

設定はサービスのアノテーション（run.googleapis.com/ssh-enabled）に入るだけなので、動いているサービスにそのまま付けられていました。

gcloud beta run services ssh sshverify-slim

SSH で接続した直後の表示

10秒ほどで root@localhost に入れました。
接続先のリビジョンやインスタンスが最初に表示されます。特定のインスタンスに入りたいときは --instance で指定します。

サービスの詳細画面にも「SSH」ボタンが増えていました。押すと Cloud Shell が開き、上のコマンドが入力された状態になります。

サービスの詳細画面の SSH ボタン

ssh コマンドでも入れる

ドキュメントには OpenSSH の設定例がありましたのでこちらも試してみます。

Host cloud-run-ssh
  HostName cloud-run-default
  User root
  IdentityFile ~/.ssh/google_compute_engine
  CertificateFile ~/.ssh/google_compute_engine_cert/PROJECT_ID_REGION_service_SERVICE-cert.pub
  HostKeyAlias cloud-run-default
  IdentitiesOnly yes
  StrictHostKeyChecking no
  UserKnownHostsFile /dev/null
  ProxyCommand gcloud beta run start-iap-tunnel --project_number=PROJECT_NUMBER --project_id=PROJECT_ID --workload_type=service --deployment_name=SERVICE/revisions/REVISION --region=REGION --iap-tunnel-url-override=wss://REGION.ssh.run.app/v4

そのままでは「Please ensure your execution environment is set to gen2」というエラーになったため、ProxyCommandに--deployment_name のリビジョン名（/revisions/REVISION）と、--iap-tunnel-url-override を追記して実行しました。

ssh コマンドで接続した結果

証明書（5分で失効）は gcloud beta run services ssh を一度実行して作る必要があり、トンネルも gcloud が張ります。
gcloud なしで済むわけではなさそうでしたので、ssh コマンドを前提にしたツールから使いたいとき向けの方法かと思います。

VS Code の Remote-SSH で使ってみた

この ssh の設定を VS Code の Remote-SSH に指定すると、VS Code からもつながりました。エクスプローラーでコンテナの中のファイルを開け、統合ターミナルも使えます。

VS Code の Remote-SSH で接続した画面

そのままでは動作しなかったため一工夫が必要そうです。

  • 手元から VS Code Server を送る方式は失敗しました。コンテナ側の sshd に SFTP が無いため、コンテナ側で curl か wget 等を用いてダウンロードさせる必要があります
  • VS Code Server は展開すると 1.4GB あり、メモリを圧迫する。ファイルシステムがメモリ上にあるので、メモリを 2GiB にしてもぎりぎりだった
  • 証明書が5分で切れるので、再接続のたびに gcloud で作り直す

本番のコンテナに VS Code Server を入れるのは現実的ではなさそうです。開発用の Cloud Run Instances のように、しばらく使い続ける環境なら使い道がありそうです。

ロギングとの使い分け

Cloud Run には Cloud Logging も、gcloud run services describe もあります。デフォルトで規定ログは各サービスに保存されています。
改めてそれぞれのサービスでできることを整理しました。

知りたいこと Logging describe SSH
アプリが実際に受け取った環境変数・Secret ログに出していれば見える 設定だけ 実際の値が見える
マウントしたファイルの中身 × 設定だけ 読める
そのインスタンスから外に届くか 失敗時のエラーだけ 設定だけ その場で試せる
エラーがいつ、どれくらい起きたか 過去も全台分も分かる × ×（入った1台の今だけ）

アプリが標準出力と /var/log に出したものは、Cloud Logging で見られます（ドキュメント）。
もしそれ以外の場所（/tmp など）に書いた場合、ログに出力こそされませんが、SSH で接続して読むことは可能です。ただし、インスタンスが替われば消えますので基本は使わないかと思います。

調査はこれまでどおりログから始め、ログに出ていない値や疎通を確かめたいときに SSH を使って確認する運用で良いと思います。

環境変数はシェルに出てこない

実行ユーザー、環境変数、Secret のファイル

SSH のシェルで echo $APP_ENV としても、空でした。
Cloud Run の環境変数はアプリのプロセスにだけ渡されます。アプリが受け取った値は /proc/1/environ で見られます。

tr '\0' '\n' < /proc/1/environ | grep -E '^(APP_ENV|DB_PASSWORD|K_)'

Secret Manager から入れた値も、ファイルでマウントした Secret もそのまま読むことができました。

なお、slim のイメージには ps も curl もありませんのでプロセスは /proc を確認して、外への疎通確認はイメージに入っている Python で試してみました。

プロセスと外への通信

スクリプトを実行して外部への疎通確認もできました。

シェルのないイメージでも入れた

シェルのないイメージに SSH した結果

シェルが無いので入れないと思っていたら、問題なくSSHで入れました。
/bin にあるのは mksh だけで、SSH のときに Google 側が持ち込んでいるようです。ただ ls すら無く、使えるのはシェルの組み込みコマンドだけのようですので、本格的に調べるのであればツール入りのイメージが必要になります。

運用で押さえておくこと

インスタンスが替わると消える

SSH で /srv/index.html を作成してから外からアクセスしてみると、応答が即時で変わっていることを確認しました。

書き換える前と後の応答

続けて、Killコマンドでアプリのプロセスを止めてインスタンスを落としました。

インスタンスを落としたあとの応答

アプリが止まるとコンテナごと終了するので、SSH の接続も切れてエラーが出ました（想定どおりです）。

新しいインスタンスでは書き換えたファイルが元に戻っていました。Cloud Run インスタンスの揮発性を考えるとこちらも想定通りですね。
SSH は調査だけ、直すのはデプロイで、と決めておくのが安全です。

SSHによるログ記録

誰がどのサービスに入ったかは、OS Login の監査ログ（CheckPolicy）に残っていました。

OS Login の監査ログ

--ssh を付けた操作は、管理アクティビティ ログに残ります。
誰が SSH を開けたかはこちらで追えそうですね。

まとめ

--ssh を付けるだけで、動いているコンテナに root で入ることができました。ログを足して再デプロイする前に、まず中を見に行けるのは大きいかなと思います。

変更は本番に反映されますしコマンドの実行記録は残りませんので、開発とステージングでは気軽に使い、本番は IAP のロールを渡す人を決めてから開けるといったSSH アクセスの運用フローもあらかじめ決めておいた方が良いと考えます。

Cloud Run の使用頻度が増えている昨今、運用監視やデバッグのための機能追加は喜ばしいことですので、記事を参考にSSH 機能をお試しください！

参考