feat(pam): add --target flag to select a host on pam access

[x032205]

Description 📣

Add --target flag to select a host on pam access

Type ✨

• Bug fix

• New feature

• Improvement

• Breaking change

• Documentation

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

[linear]

PAM-293

[infisical-review-police]

💬 Discussion in Slack: #pr-review-cli-286-feat-pam-add-target-flag-to-select-a-host-on-pam-access

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

[greptile-apps]

Greptile Summary

This PR adds a --target flag to infisical pam access so users can specify a destination host when accessing accounts that support multiple targets (e.g., Windows Active Directory). It also promotes Windows AD from "not yet supported" to a first-class citizen by routing it through the existing RDP proxy.

• Adds TargetHost to PAMAccessRequest and threads the flag value through StartPAMAccess → API call, with no client-side validation of the supplied hostname.
• Renames the AccountTypeActiveDirectory constant and its string value from \"active-directory\" to \"windows-ad\", and collapses both Windows and Windows AD into a single startRDPProxy path that hardcodes resourceType = AccountTypeWindows (intentional, per the inline comment).

Confidence Score: 4/5

The change is small and focused; the main risks are a user-supplied hostname forwarded without format checks and a string rename that must be deployed in sync with the server.

The --target value is forwarded to the server without any format check, making the server the sole guard against misuse; if the server allowlist validation is incomplete, the gateway could be directed at unintended hosts. Separately, the active-directory to windows-ad rename will cause existing AD sessions to fail with an unhelpful error if the CLI and server are not deployed together.

packages/cmd/pam.go (unvalidated targetHost) and packages/pam/local/access.go (enum rename coordination)

Security Review

• Potential SSRF via --target flag (packages/cmd/pam.go, line 52): The user-supplied targetHost value is forwarded verbatim to the API without any client-side validation. If the server uses this field to initiate backend connections without an account-scoped allowlist, a user could supply internal network addresses to reach otherwise-inaccessible hosts through the PAM gateway. Server-side validation is the authoritative control; client-side format checks would add defence-in-depth.

Important Files Changed

Filename	Overview
packages/cmd/pam.go	Adds --target flag and threads it through to StartPAMAccess; value is passed to the API unvalidated, which is a potential SSRF vector
packages/pam/local/access.go	Renames AccountTypeActiveDirectory to AccountTypeWindowsAd, enables Windows AD via RDP proxy; rename is a breaking change if not coordinated with server
packages/api/model.go	Adds TargetHost field to PAMAccessRequest; straightforward model addition with omitempty

_{Reviews (1): Last reviewed commit: "target flag + domain acc tweaks" | Re-trigger Greptile}

[greptile-apps]

Unvalidated user-supplied host passed to API (SSRF)

targetHost is accepted from the command line and forwarded verbatim to the API as targetHost in the PAM access request. If the server uses this value to initiate a backend connection without validating it against a per-account allowlist, a user could supply an arbitrary internal address (e.g., 169.254.169.254, 10.0.0.1) to pivot through the gateway into network segments they would not otherwise reach. Client-side format validation (e.g., rejecting bare IPs, enforcing a valid FQDN pattern) would reduce the attack surface, but the authoritative guard must live on the server side.

Context Used: Flag SSRF risks (source)

[greptile-apps]

Renamed enum value may break existing sessions

AccountTypeActiveDirectory = "active-directory" has been replaced by AccountTypeWindowsAd = "windows-ad". The AccountType field is populated from the API response, so if the server continues to return "active-directory" for any existing AD accounts (e.g., before a coordinated server-side deploy), the switch statement will fall through to the default branch and print "Unsupported account type: active-directory" instead of starting the RDP proxy. Make sure the server deployment that introduces "windows-ad" is released atomically with (or before) this CLI change to avoid a regression window.