Expondo com Segurança um Servidor MCP Stateful no Cloud Run

TL;DR

• Eu queria operar páginas que requerem login do Google a partir do n8n via Playwright MCP
• A abordagem sidecar é fácil, mas tem lacunas do ponto de vista de autenticação e isolamento de equipe
• Eu construí uma defesa em profundidade com ingress: internal + IAM (roles/run.invoker) + autenticação de serviço para serviço via tokens de ID + um proxy de autenticação em Go + Secret Manager
• Para o MCP com estado, defina maxScale=1 para parar a escalabilidade e evitar que sessões sejam transferidas para outra instância

Público-alvo

• Pessoas que desejam executar um servidor MCP no Cloud Run
• Pessoas que desejam automatizar operações em páginas que requerem login do Google usando Playwright MCP
• Pessoas que compartilham n8n entre várias equipes e desejam lidar com páginas que requerem logins do Google por equipe via Playwright MCP
• Pessoas que desejam configurar autenticação de serviço para serviço no Cloud Run (tokens de ID + IAM) de uma maneira prática

Contexto

O ponto de partida foi: eu queria operar e capturar páginas que requerem login do Google, como Looker Studio, a partir de fluxos de trabalho do n8n. O Playwright MCP parecia que poderia fazer isso funcionar, então eu tentei. Mas, uma vez que tentei colocá-lo em operação, encontrei os seguintes desafios.

• Como o n8n é compartilhado entre várias equipes, eu quero alternar estados de login por conta de equipe
• Eu não quero um endpoint do Playwright MCP que "qualquer um possa acessar" em primeiro lugar

O Problema: Lacunas na Configuração Sidecar

A primeira coisa que vem à mente é executar o playwright-mcp como um sidecar na mesma instância do Cloud Run que o n8n. É fácil, mas tem lacunas em relação aos desafios acima.

[Antes: configuração perigosa]
┌─ Instância do Cloud Run ─────────────────────────┐
│  n8n (porta 5678)                             │
│        │ localhost:3000 (sem autenticação necessária)   │
│        ▼                                     │
│  playwright-mcp (porta 3000)                  │
│        ※ mantém sessão logada no Google      │
└──────────────────────────────────────────────┘

Como é um sidecar, o playwright-mcp não é visível de fora. No entanto, o n8n dentro da mesma instância pode acessar localhost:3000 sem nenhuma autenticação.

Porque o playwright-mcp está mantendo o estado logado no Google (Storage State):

• Qualquer um que possa construir fluxos de trabalho no n8n pode usar as credenciais de login compartilhadas
• Não pode acomodar casos de uso onde cada equipe precisa de uma conta diferente

Esse é o resultado. Remover o sidecar e dividi-lo em um serviço separado do Cloud Run os desacopla, mas apenas dividir deixa "deve ser exposto à internet ou apenas dentro da VPC?" e "como fazemos a autenticação?" no ar.

Arquitetura da Solução

No final, adotei a seguinte configuração.

[Depois: configuração de defesa em profundidade]

n8n (Cloud Run, ingress=internal)
 │  Mcp-Auth-Key: <chave API por equipe>
 │  Caminho: /playwright-mcp-team-a/...
 │
 │  ※ n8n tem vpc-access-egress=all-traffic, então o tráfego
 │    é roteado para o Cloud Run interno via a VPC
 ▼
auth-proxy (Cloud Run, ingress=internal)
 │  - Verifica Mcp-Auth-Key
 │  - Escolhe o backend pelo primeiro segmento da URL
 │  - Anexa o token de ID da própria conta de serviço e encaminha
 ▼
playwright-mcp-team-a (Cloud Run, ingress=internal, maxScale=1)
   - IAM: roles/run.invoker é concedido apenas ao SA do auth-proxy
   - Ao receber, o Cloud Run verifica o token de ID
   - O Storage State é montado via Secret Manager

Existem 4 camadas defensivas. Elas são portões empilhados em série, e se qualquer uma delas for violada, o significado das camadas restantes se enfraquece.

Vou cobrir como o token de ID e o IAM se entrelaçam em detalhes na seção de autenticação de serviço para serviço abaixo.

Persistindo o Estado de Login do Google: storage-state

O Playwright tem uma opção --storage-state que permite salvar e reutilizar informações de sessão logada (cookies e localStorage) como um arquivo. Armazenar isso no Secret Manager e montá-lo como um volume do Cloud Run permite que você mantenha o estado de login mesmo após uma inicialização a frio.

volumes:
  - name: playwright-storage-state
    secret:
      secretName: PLAYWRIGHT_STORAGE_STATE
      items:
        - key: "1"
          path: storage-state.json
containers:
  - name: playwright-mcp
    args:
      - "--storage-state=/etc/playwright/storage-state.json"
    volumeMounts:
      - name: playwright-storage-state
        mountPath: /etc/playwright
        readOnly: true

Quando você quiser atualizar o estado de login, basta fazer login novamente em outra máquina e registrar o novo storage-state.json como uma nova versão no Secret Manager. Reiniciar o serviço irá capturá-lo.

Implementando mcp-auth-proxy (Go)

Eu implementei um serviço leve que lida com autenticação e proxy reverso em Go. A fundação do proxy reverso é apenas a biblioteca padrão net/http/httputil.ReverseProxy, e eu apenas adiciono google.golang.org/api/idtoken para obter tokens de ID.

Lista de Backends

Este é o único lugar que você toca ao adicionar uma nova equipe.

var routeSpecs = []struct {
    PathID        string
    APIKeyEnv     string
    BackendURLEnv string
}{
    {
        PathID:        "playwright-mcp-team-a",