fix(relay): support --enroll-method in systemd install

[AhmedAburady]

Description

Closes #261

The bug (high level)

infisical relay start supports --enroll-method=token (and aws), which uses a one-time
enrollment token to authenticate against the V2 relay API. This avoids the legacy
machine-identity auth path that triggers the dashboard warning:

"Authenticated via Machine Identity (Legacy) — This relay is still using machine identity.
We recommend creating a new relay."

However, infisical relay systemd install did not expose --enroll-method. The generated
systemd unit runs infisical relay start with no flags, relying entirely on
/etc/infisical/relay.conf. Since that file never contained any enrollment variables, a
systemd-managed relay always fell back to legacy machine-identity auth on every boot — there
was no way to run a systemd relay using the newer enrollment flow.

The fix (low level)

1. packages/cmd/relay.go (relay systemd install) — added --enroll-method (token|aws)
   and --relay-id flags. Auth validation is now a switch on the enroll method:
   • token: requires --token (treated as a one-time enrollment token)
   • aws: requires --relay-id (falls back to the INFISICAL_RELAY_ID env)
   • "" (legacy): unchanged behavior
   • anything else: rejected with a clear error
2. packages/relay/systemd.go (InstallRelaySystemdService) — extended to accept
   enrollMethod and relayID, and to write the matching variables to relay.conf:
   • token → INFISICAL_RELAY_ENROLL_METHOD=token + INFISICAL_RELAY_ENROLLMENT_TOKEN=<token>
   • aws → INFISICAL_RELAY_ENROLL_METHOD=aws + INFISICAL_RELAY_ID=<id>
   • legacy → INFISICAL_TOKEN / INFISICAL_RELAY_AUTH_SECRET exactly as before
3. packages/cmd/relay.go (relay start) — the enrollment-token path now falls back to the
   INFISICAL_RELAY_ENROLLMENT_TOKEN env var (it previously read the token only from --token,
   so a flagless systemd invocation could never supply it). Mirrors how the aws path already
   falls back to INFISICAL_RELAY_ID.
4. packages/relay/enroll.go — added the INFISICAL_RELAY_ENROLL_METHOD_KEY constant (the
   env name was previously a string literal) and reused it in both relay start and the
   systemd installer.

Backward compatibility

When --enroll-method is omitted, behavior is identical to before: INFISICAL_TOKEN (org) or
INFISICAL_RELAY_AUTH_SECRET (instance) is written, and no enrollment variables are added.

Type of change

• Bug fix (non-breaking change which fixes an issue)

Testing

Built and tested on a real Linux server (systemd):

sudo infisical relay systemd install --name=homelab --enroll-method=token \
  --token=gwe_... --domain=https://<instance> --host=192.168.1.35
sudo systemctl start infisical-relay

Service logs confirm the enrollment flow (no machine identity):

INF Enrolling relay with enrollment token...
INF Relay enrolled successfully. Access token saved to /etc/infisical/relays/homelab.conf
INF Successfully connected relay and received certificates via v2 API
INF Relay server started successfully
INF TLS server listening on :8443 for clients
INF SSH server listening on :2222 for gateways

/etc/infisical/relay.conf contains INFISICAL_RELAY_ENROLL_METHOD=token and
INFISICAL_RELAY_ENROLLMENT_TOKEN=..., and no INFISICAL_TOKEN. Legacy install (no
--enroll-method) was verified to still write INFISICAL_TOKEN as before.

Before (current main) — flag doesn't exist:

After — enrollment install + service starts and enrolls:

Dashboard confirms Token Auth (not Machine Identity Legacy):

Checklist

• I have read the contributing guidelines
• My changes are backward compatible
• I have tested my changes

[greptile-apps]

Greptile Summary

This PR fixes a gap where infisical relay systemd install had no way to use the V2 enrollment-token or AWS auth flows, forcing systemd-managed relays onto the legacy machine-identity path. It adds --enroll-method and --relay-id flags to the install command, extends InstallRelaySystemdService to write the matching env vars to relay.conf, and adds an INFISICAL_RELAY_ENROLLMENT_TOKEN env fallback in relay start so the token written by the installer is picked up on boot.

• relay systemd install gains --enroll-method=[token|aws] and --relay-id; auth validation is restructured into a switch that covers all three paths (token enrollment, AWS STS, legacy machine-identity).
• relay start now falls back to INFISICAL_RELAY_ENROLLMENT_TOKEN env when --token is absent and --enroll-method=token, mirroring the existing AWS INFISICAL_RELAY_ID fallback.
• enroll.go promotes the INFISICAL_RELAY_ENROLL_METHOD env name to a named constant reused across both files.

Confidence Score: 3/5

The change is otherwise well-structured and backward-compatible, but there is one incorrect-behavior path in the install command that can cause silent misconfiguration.

In relaySystemdInstallCmd, token is read once at the top of the handler using INFISICAL_TOKEN as its env fallback, before enrollMethod is examined. When an admin has INFISICAL_TOKEN set in their environment and runs systemd install --enroll-method=token without explicitly passing --token, the machine-identity token is silently accepted as the enrollment token, passes the non-empty check, and gets written to relay.conf. The systemd service then starts and fails to enroll with an opaque API error — the mistake is not caught at install time.

packages/cmd/relay.go — specifically the token-reading logic in relaySystemdInstallCmd around line 294 and the EnrollMethodToken switch case at line 349.

Important Files Changed

Filename	Overview
packages/cmd/relay.go	Adds --enroll-method and --relay-id flags to relay systemd install and adds env fallback for the enrollment token in relay start; has a bug where INFISICAL_TOKEN is silently used as the enrollment token when --enroll-method=token and the flag is omitted
packages/relay/systemd.go	Extends InstallRelaySystemdService to write INFISICAL_RELAY_ENROLL_METHOD and corresponding credential vars; relay.conf is written with 0600 permissions; logic mirrors the cmd-layer switch cleanly
packages/relay/enroll.go	Adds INFISICAL_RELAY_ENROLL_METHOD_KEY constant and aligns spacing; clean, no issues

Comments Outside Diff (1)

1. packages/cmd/relay.go, line 294-352 (link)

   Wrong token type silently accepted when INFISICAL_TOKEN is set in the environment

   The token variable is read unconditionally from the --token flag with INFISICAL_TOKEN as the env fallback (line 294), before enrollMethod is known. When an operator runs systemd install --enroll-method=token --name=... --host=... and has a machine-identity INFISICAL_TOKEN set in their shell (a common scenario for admins), the validation at line 351 passes (token != ""), and the machine-identity token is written to relay.conf as INFISICAL_RELAY_ENROLLMENT_TOKEN. The systemd service then fails to start with a confusing enrollment error, not at install time.

   Compare with relay start (line 114–116), which correctly falls back to INFISICAL_RELAY_ENROLLMENT_TOKEN (not INFISICAL_TOKEN) when enrollMethod == token. The install command should do the same: inside the EnrollMethodToken switch case, override token from INFISICAL_RELAY_ENROLLMENT_TOKEN when the flag was not explicitly set, before the emptiness check.

   Prompt To Fix With AI

   This is a comment left during a code review.
   Path: packages/cmd/relay.go
   Line: 294-352
   
   Comment:
   **Wrong token type silently accepted when `INFISICAL_TOKEN` is set in the environment**
   
   The `token` variable is read unconditionally from the `--token` flag with `INFISICAL_TOKEN` as the env fallback (line 294), before `enrollMethod` is known. When an operator runs `systemd install --enroll-method=token --name=... --host=...` and has a machine-identity `INFISICAL_TOKEN` set in their shell (a common scenario for admins), the validation at line 351 passes (`token != ""`), and the machine-identity token is written to `relay.conf` as `INFISICAL_RELAY_ENROLLMENT_TOKEN`. The systemd service then fails to start with a confusing enrollment error, not at install time.
   
   Compare with `relay start` (line 114–116), which correctly falls back to `INFISICAL_RELAY_ENROLLMENT_TOKEN` (not `INFISICAL_TOKEN`) when `enrollMethod == token`. The install command should do the same: inside the `EnrollMethodToken` switch case, override `token` from `INFISICAL_RELAY_ENROLLMENT_TOKEN` when the flag was not explicitly set, before the emptiness check.
   
   How can I resolve this? If you propose a fix, please make it concise.

   

Prompt To Fix All With AI

Fix the following 1 code review issue. Work through them one at a time, proposing concise fixes.

---

### Issue 1 of 1
packages/cmd/relay.go:294-352
**Wrong token type silently accepted when `INFISICAL_TOKEN` is set in the environment**

The `token` variable is read unconditionally from the `--token` flag with `INFISICAL_TOKEN` as the env fallback (line 294), before `enrollMethod` is known. When an operator runs `systemd install --enroll-method=token --name=... --host=...` and has a machine-identity `INFISICAL_TOKEN` set in their shell (a common scenario for admins), the validation at line 351 passes (`token != ""`), and the machine-identity token is written to `relay.conf` as `INFISICAL_RELAY_ENROLLMENT_TOKEN`. The systemd service then fails to start with a confusing enrollment error, not at install time.

Compare with `relay start` (line 114–116), which correctly falls back to `INFISICAL_RELAY_ENROLLMENT_TOKEN` (not `INFISICAL_TOKEN`) when `enrollMethod == token`. The install command should do the same: inside the `EnrollMethodToken` switch case, override `token` from `INFISICAL_RELAY_ENROLLMENT_TOKEN` when the flag was not explicitly set, before the emptiness check.

_{Reviews (1): Last reviewed commit: "fix(relay): support --enroll-method in s..." | Re-trigger Greptile}