IAP経由のSSHはどこまで監査できるのか。OS LoginとVMログを実測した

Sat, 12 Sep 2026 00:00:00 +0900

概要
#

外部IPを付けず、tcp/80 も開けずに、VM 上の HTTP を見たい。IAP の SSH ポートフォワードでできます。許可するのは IAP の範囲からの tcp/22 だけです。

ただ、そのあとに困ることが2つあります。

誰に何の権限を渡せばいいのか。 公式の手順どおりに書いたつもりで、自分では繋がるのに他の人が繋がらない、ということが起きます。

誰が何をしたか、どこまで残るのか。 踏み台を置かない構成なので、監査の材料がどこにあるのか分かりにくくなります。

この2つを実測します。接続手順そのものはサンプルの README にあるので、ここでは扱いません。

Google Cloud の Compute Engine を触ったことがある人向けです。外部IPなしの VM への接続経路を決めようとしている場面を想定しています。IAP の Web アプリ向け機能と、Organization Policy による追加要件は扱いません。

Sat, 05 Sep 2026 00:00:04 +0900

「Terraformはマシンを作る、中で動くものはAnsible」という分担はよく聞きます。ところがその受け渡しは自動では繋がりません。

実際に、terraform applyが35 addedと出た一方で、VMの中ではAnsibleが失敗していました。terraform planも差分なしのままです。Terraformから見ると、この失敗はどこにも現れません。

GCEにOps AgentとNginxを入れる最小構成で、この境界を実測します。

対象読者は、TerraformでGCEを作ったことがあり、Ansibleを書いたことがある人です。それぞれの入門は扱いません。

Ansible制御ノードからのpush型実行、Ansible Vaultは扱いません。今回はVM上でのlocal実行です。

Google Cloud CLI、Terraform
Billingが有効な検証用Google Cloud Project
GCE、GCS、IAPを操作できるGoogleアカウント
VM内でsudoを実行できること。掲載した手動再実行やログ確認に要る。roles/compute.osLoginだけでは足りず、roles/compute.osAdminLoginが要る
検証時のバージョン：Terraform 1.14.5、google 7.46.0、Debian 12、nginx 1.22、Ansible 2.14（Debian 12 の apt が入れる版）、Ops Agent 2.x

Ansible と Ops Agent の細かい版は記録していません。挙動が変わりうるので、再現するなら ansible --version と google_cloud_ops_agent_engine --version を控えておきます。