Conversation
Adds --enroll-method=gcp to gateway start and gateway systemd install. The gce type reads an identity token from the instance metadata server, covering Compute Engine VMs and GKE workload identity; the iam type signs a JWT through the IAM Credentials API, using ADC or a key file. Both carry the gateway ID as the token audience and re-authenticate on every start, so no credential is written to disk.
|
💬 Discussion in Slack: #pr-review-cli-400-feat-gateway-gcp-enrollment Posted by Review Police — reviews, comments, new commits, and CI failures will stream into this channel. |
Contributor
 |
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
![veria-ai[bot]](https://avatars.githubusercontent.com/in/1723776?s=60&v=4){kind=small}
Contributor
PR overviewAll previously flagged issues have been addressed. No open security concerns remain on this pull request. Security reviewNo open security issues remain on this pull request. Fixed/addressed: 1 · PR risk: 0/10 |
bernie-g
changed the title
Addresses PR review findings. The signed IAM JWT carried only sub and aud, so a captured login request stayed a valid proof forever. It now carries iat and a 5 minute exp, which the backend requires. A service account key path under a home directory installed fine and then failed on every service start, because the unit runs with InaccessibleDirectories=/home and no working directory. The install now rejects a relative path, a path under /home, and a missing file.
Clears GO-2026-6348, GO-2026-6441 and GO-2026-6443, which govulncheck flags as non-allowlisted. These predate this branch and also fail on main; the advisories were published after main last ran green.
The e2e tests are their own module and share the root dependency graph, so `go test` there fails with 'updates to go.mod needed' until it is tidied alongside.
The key path was read for every gcp login, so a stray INFISICAL_GCP_IAM_SERVICE_ACCOUNT_KEY_FILE_PATH left over from machine identity auth made a plain gce login fail for no visible reason. It is read only for the iam type now, and passing the flag with gce fails at install time rather than producing a service that never starts. The systemd path check also cleans the path first and covers /tmp, which the unit makes private.
On a Compute Engine instance the usual cause is the default scopes omitting iamcredentials, which the error never mentioned. It pointed at the API and the IAM role instead, neither of which is the problem.
The three login methods post to the same endpoint and get the same body back, so aws, gcp and kubernetes each had an identical response struct and a call function differing only in type names. They share GatewayLoginResponse and CallGatewayLogin now. The request types stay per-method: aws sends a signed STS request where the other two send a JWT, and each struct documents what its own method puts on the wire.
…pport-gcp-authentication-for-gateway # Conflicts: # go.mod
|
| GitGuardian id | GitGuardian status | Secret | Commit | Filename | |
|---|---|---|---|---|---|
| 37072668 | Triggered | Username Password | 9d69ea3 | packages/gateway-v2/test_connection_oracle_test.go | View secret |
🛠 Guidelines to remediate hardcoded secrets
- Understand the implications of revoking this secret by investigating where it is used in your code.
- Replace and store your secret safely. Learn here the best practices.
- Revoke and rotate this secret.
- 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.
carlosmonastyrski
approved these changes
Sep 18, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description 📣
Adds
--enroll-method=gcptogateway startandgateway systemd install, so a gateway on Compute Engine or GKE enrolls with no credential written to disk. Backend side is Infisical/infisical#8143.The
gcetype reads an identity token from the instance metadata server and theiamtype signs a JWT through the IAM Credentials API; both use the gateway ID as the token audience and re-authenticate on every start.Type ✨
Tests 🛠️
Verified on a real Compute Engine VM and a GKE cluster with Workload Identity, in the foreground and as a systemd service, both reaching gateway registration.