feat(pam): add GCP IAM proxy and gateway handler

[bernie-g]

Description 📣

Adds a CLI-side local proxy that configures gcloud to route through an Infisical gateway, and a gateway-side HTTP forward proxy that performs TLS MITM to inject GCP Bearer tokens into requests.

Companion backend PR: Infisical/infisical#7084

Type ✨

• Bug fix
• New feature
• Improvement
• Breaking change
• Documentation

Tests 🛠️

1. Start a GCP IAM PAM session via infisical pam access
2. Verify gcloud commands (e.g. gcloud compute instances list) work through the proxy
3. Verify proxy settings are reverted on shutdown

---

• I have read the contributing guide, agreed and acknowledged the code of conduct. 📝

[linear]

PAM-315

[infisical-review-police]

💬 Discussion in Slack: #pr-review-cli-290-feat-pam-add-gcp-iam-proxy-and-gateway-handler

Posted by Review Police — reviews, comments, new commits, and CI failures will stream into this channel.

[greptile-apps]

Greptile Summary

This PR adds GCP IAM support to the PAM system via a two-sided TLS MITM proxy: a CLI-side local proxy that configures gcloud to route through it, generates a self-signed CA, and tunnels traffic to the gateway; and a gateway-side handler that receives the CA cert+key, terminates TLS, and injects the GCP Bearer token into outbound requests.

• CLI side (gcp-proxy.go): Generates an ephemeral ECDSA CA, binds a local TCP listener on 127.0.0.1, writes gcloud configuration to route traffic through the proxy, then forwards raw connections through the relay to the gateway. Cleanup on shutdown reverts all gcloud config properties and removes temp files.
• Gateway side (handlers/gcp/proxy.go): Receives the CA cert+key from the client, performs TLS MITM for HTTPS CONNECT tunnels, validates that the target is a *.googleapis.com host, and injects the Authorization: Bearer header before forwarding to GCP — but the host check can be bypassed via an absolute-form request URL (SSRF risk).
• Supporting changes: pam-proxy.go caps GCP credential fetch to 1 hour (matching GCP token lifetime), and uploader.go routes GCP sessions through the HTTP-events upload path alongside Kubernetes.

Confidence Score: 3/5

The gateway-side proxy has a host-validation bypass that allows the forwarding target to be overridden by an absolute-form request URL, which could reach internal cloud endpoints from the gateway host.

The gateway's handleRequest checks req.Host against the GCP allowlist but then overwrites the forwarding target with req.URL.Host when an absolute URL is present, without re-validating it. The gateway may run in a cloud environment where internal metadata endpoints are reachable, making this a real forwarding risk that should be fixed before the feature ships. The CLI-side proxy and session management changes are straightforward and look correct.

packages/pam/handlers/gcp/proxy.go — the handleRequest function needs a second isGCPHost check on req.URL.Host before it is used as the forwarding target.

Security Review

• SSRF in handlers/gcp/proxy.go handleRequest: The host allowlist check validates req.Host, but when the request line contains an absolute URL (e.g. GET https://169.254.169.254/... HTTP/1.1 with Host: googleapis.com), req.URL.Host overrides the forwarding target without a corresponding GCP-host check. This allows a crafted request to reach arbitrary internal endpoints — including cloud metadata services — from the gateway.

Important Files Changed

Filename	Overview
packages/pam/handlers/gcp/proxy.go	New gateway-side TLS MITM proxy that injects GCP Bearer tokens; contains an SSRF vulnerability where req.URL.Host can override the validated req.Host, allowing requests to be forwarded to arbitrary internal endpoints, and has no request body size limit.
packages/pam/local/gcp-proxy.go	New CLI-side local proxy that generates a CA, listens on localhost, configures gcloud to route through the proxy, and transmits the CA cert+key to the gateway over the TLS relay. Cleanup and signal handling look solid.
packages/pam/pam-proxy.go	Adds GCP IAM to the supported resource types and caps credential expiry at 1 hour for GCP tokens; routing to the new GCPProxy handler is correct.
packages/pam/session/uploader.go	Adds ResourceTypeGcpIam to the session filename regex and routes GCP sessions through the HTTP-events upload path; log message for GCP uploads mistakenly says "Kubernetes".
packages/pam/session/credentials.go	Adds Token and ServiceAccountEmail fields to PAMCredentials and maps them from the API response; straightforward and correct.
packages/api/model.go	Adds Token and ServiceAccountEmail to PAMSessionCredentials; no issues.
packages/pam/local/access.go	Adds AccountTypeGcpIam constant and routes GCP IAM sessions to startGCPProxy; straightforward dispatch addition.

Comments Outside Diff (1)

1. packages/pam/session/uploader.go, line 696-707 (link)

   Stale log message for GCP session uploads

   The debug log message on line 706 says "Uploading Kubernetes session events" even when fileInfo.ResourceType == ResourceTypeGcpIam. This will make log-based debugging and monitoring difficult if GCP upload failures need to be queried in cloud logging tools.

   Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

_{Reviews (1): Last reviewed commit: "fix(pam): cap GCP credential cache TTL a..." | Re-trigger Greptile}

[gitguardian]

⚠️ GitGuardian has uncovered 1 secret following the scan of your pull request.

Please consider investigating the findings and remediating the incidents. Failure to do so may lead to compromising the associated services or software components.

🔎 Detected hardcoded secret in your pull request

GitGuardian id	GitGuardian status	Secret	Commit	Filename
34388528	Triggered	Generic Database Assignment	77eebc7	packages/pam/local/access.go	View secret

🛠 Guidelines to remediate hardcoded secrets

1. Understand the implications of revoking this secret by investigating where it is used in your code.
2. Replace and store your secret safely. Learn here the best practices.
3. Revoke and rotate this secret.
4. If possible, rewrite git history. Rewriting git history is not a trivial act. You might completely break other contributing developers' workflow and you risk accidentally deleting legitimate data.

To avoid such incidents in the future consider

• following these best practices for managing and storing secrets including API keys and other credentials
• install secret detection on pre-commit to catch secret before it leaves your machine and ease remediation.

---

^{🦉 GitGuardian detects secrets in your source code to help developers and security teams secure the modern development process. You are seeing this because you or someone else with access to this repository has authorized GitGuardian to scan your pull request.}

[veria-ai]

PR overview

All previously flagged issues have been addressed. No open security concerns remain on this pull request.

Security review

No open security issues remain on this pull request.

Fixed/addressed: 2 · PR risk: 0/10