# Day7 IAP > IAM based Auth

2026 iThome 鐵人賽

DAY 7

自我挑戰組

和AI學習gcp - 建立對話代理系列第 7 篇

18th鐵人賽

jojomango

2026-08-07 22:25:05

84 瀏覽

分享至

參考文件 iap

IAP (Identity-Aware Proxy) 的核心邏輯就是把「身份驗證（Authentication）」從應用程式中抽離出來，交給 Google 來守門

當然另一個要求就是使用者必須要使用google登入

另外IAP必須使用load balancer, IAP只能掛載在load balancer上

不過load balancer會有每個月固定20美金的收費考量我們實驗環境也有開銷的限制, 更改GKE為cloud run, 限制使用者的機制改為Google IAM 認證 (IAM-based Auth)

我們會採用firebase auth, 使用情境上會在client服務要求使用者google登入, 登入後會拿到一個id token, 並且把這個token塞入header, 之後的bff服務就會檢查這個token, 看是否為公司員工並且放行

在預設情況下，Cloud Run 是跑在 Google 託管的公共網路環境中。這會產生兩個大問題，而 VPC Connector 正是為了解決它們：

1. 存取「隱身」的資源 (內網連通)

之後我們會建立資料庫（Cloud SQL）。為了安全，我們會把資料庫的 Public IP 關掉，只給它一個 10.x.x.x 的內網 IP。

沒有 Connector：Cloud Run 就像是在外網的人，完全看不見也連不到內網的資料庫。
有了 Connector：Cloud Run 的流量會鑽進這條隧道，直接出現在 bank-ai-vpc 裡，從而能夠存取 10.x.x.x 的資源。

2. 獲得「固定」的出發地 (固定出口 IP)

爬蟲任務需要這個。

沒有 Connector：Cloud Run 的爬蟲每次出發去抓 OWASP 官網時，出口 IP 都不固定（Google 有成千上萬個動態 IP）。如果對方網站有防禦機制，可能會被當作惡意流量封鎖。
有了 Connector：後可以設定 Cloud Run 所有的流量都走這條隧道。配合之後會蓋的 Cloud NAT，可以讓爬蟲擁有一個「固定且專屬」的公司靜態 IP。

今日實作

今天會做兩件事

1. VPC Connector：建立「雙向」的特權通道

進入內部：它是 Cloud Run 訪問 VPC 內「私有資源」（如明天的資料庫）的專屬傳送門。
固定對外：它讓 Cloud Run 所有的流量（包含抓取 OWASP 資訊）都集中到 VPC 內，為我們之後設定「固定出口 IP (Cloud NAT)」鋪好了路。

2. Cloud Run (BFF) + IAM：定義「誰能執行程式」

實體定義：定義了 BFF 的基礎規格與身分證（Service Account）。
門禁規則：透過 run.invoker 權限，你成功實踐了「身分驗證」。這確保了只有持有公司 Google 憑證的請求，才能讓這段程式碼跑起來。

先要enable serverless VPC access api

https://console.cloud.google.com/apis/library/vpcaccess.googleapis.com?project=

接著在 /terraform/network.tf 中加入VPC connector

# VPC connector
resource "google_vpc_access_connector" "main_connector" {
  name   = "vpc-connector"
  region = "asia-east1"
  # 使用我們 Day 6 準備好的 10.8.0.0/28 子網
  subnet {
    name = google_compute_subnetwork.connector_subnet.name
  }
  machine_type  = "e2-micro"
  min_instances = 2
  max_instances = 3
}

enable cloudrun admin api

https://console.cloud.google.com/apis/library/run.googleapis.com?project=

接著新增一個tf檔

/terraform/cloudrun.tf

# 1. 定義 Cloud Run 服務 (BFF)
resource "google_cloud_run_v2_service" "bff_service" {
  name     = "chatbot-bff"
  location = "asia-east1"

  # 銀行級安全：只允許透過認證的請求 (取代 IAP 的方案)
  ingress = "INGRESS_TRAFFIC_ALL"

  template {
    # 連結我們 Day 5 做的 Service Account
    service_account = google_service_account.chatbot_bff_sa.email

    vpc_access {
      # 連結你剛剛做好的隧道
      connector = google_vpc_access_connector.main_connector.id
      # 強制所有流量 (包含連外網) 都走 VPC 隧道
      egress = "ALL_TRAFFIC"
    }

    containers {
      # TODO: 先用 Google 的範例 Hello 鏡像，之後再換成bff的image
      image = "us-docker.pkg.dev/cloudrun/container/hello"

      ports {
        container_port = 8080
      }
    }
  }
}

# 2. 權限設定：只准你自己 (公司帳號) 訪問 目前就是只有自己可以觸發cloud run
resource "google_cloud_run_v2_service_iam_member" "allow_me" {
  location = google_cloud_run_v2_service.bff_service.location
  name     = google_cloud_run_v2_service.bff_service.name
  role     = "roles/run.invoker"
  # TODO: 暫時設定為自己可以觸發cloud run, 之後要改成公司成員都可以觸發
  member = "user:q9898989@gmail.com"
}

接著也用 terraform plan terraform apply 命令來更新遠端的gcp

成功apply後應該可以在cloud run看到定義的 ‘chatbot-bff’

點擊這個resource進去後有個test 點選

右側欄最下方點擊 test in cloud shell

在terminal中第一次應該會引導你google登入

接著會帶入測試的cmd, 執行後應該會看到恭喜

也就是執行成功了

在這邊順便簡述cloud run, 簡單地說就是一個serverless的服務, 在我們熟悉的網頁訪問, 實際上都有個機器在接收我們訪問的請求, 回傳網頁需要的檔案(html, css, js), 而通常這些server都是持續開機運行等待請求, 而serverless就是只有在請求進來時才啟動, 並回應請求, 對於一個實驗性質的專案, 我們的流量一定會集中在上班時段, 而且是少數人觸發, 使用serverless的服務更省費用, 並且如前提到我們可以避開使用load balancer, 額外省下花費, 畢竟這個專案的核心目的是在於探所converstional agent, 不是在滿足24h的訪客情求

後來我發現 connector也會收費一天大概會產生要15元台幣左右的花費

而且已經是最低階最少實體(e2-micro, 2 instance)