feat(proxy): Add support for secret update using SSE

[adilsitos]

Description 📣

Allow support to update secrets using SSE (server sent events)

Type ✨

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

Tests 🛠️

• Created a new secret management project
• Create a universal identity machine policy
• Start the proxy pointing to the server (default port is 8080)
• Create some secrets using the interface
• Try to fetch using the API (check the bash code below)
• Update the secret using the interface
• Check the SSE connection was opened (check the logs)
• Try to fetch it again (using the API)
• Check the request was cached.

curl --location 'http://localhost:8081/api/v4/secrets/test?type=shared&projectId=66b56e25-7db3-49c3-8014-f96407852d54&environment=prod' \
--header 'Authorization: Bearer tokwn'

---

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

[linear]

ENG-4525 Add event subscriptions to Infisical Proxy

[greptile-apps]

Greptile Summary

This PR adds demand-driven SSE (Server-Sent Events) support to the Infisical proxy, allowing real-time cache invalidation when secrets are created, updated, or deleted. When --use-sse is enabled, the static periodic refresh loop is disabled and replaced by per-project SSE connections that are opened lazily on the first secret request. On a mutation event, affected cache entries are collected, purged, and immediately re-fetched using the original per-user tokens — correctly addressing the authorization concern from the previous review cycle.

Key changes:

• New packages/proxy/sse.go: SSEManager, SSEAuthState, connectSSEForProject, parseSSEStream, handleSSEEvent, and refetchSecretsAfterSSEEvent implement the full SSE lifecycle with exponential-backoff retry, re-authentication, and cache resync on reconnect.
• packages/proxy/cache.go: New CollectAndPurgeByMutation method reads cached entries before evicting them so they can be replayed with the original tokens.
• packages/proxy/resync.go: StartBackgroundLoops gains a sseEnabled flag; when true the secrets-refresh ticker channel is replaced with a nil (never-firing) channel.
• packages/cmd/proxy.go: Three new flags (--use-sse, --client-id, --client-secret), SSEManager initialisation, and a refactor of the cache-serving path into helper functions.

Issues found:

• SSEAuthState is never pre-authenticated, so the very first SSE connection per project always fails with 401 before the retry loop obtains a token and reconnects, creating a window in which early events can be missed.
• The bufio.Scanner in parseSSEStream uses the default 64 KB line-size cap; large payloads (e.g., bulk import mutations) can trigger a scan error, force a reconnect, and silently drop the oversized event.
• EnsureSubscription and its call-site in proxy.go both log the same message, producing duplicate log entries on every secret request.
• No documentation exists for the new flags or the SSE operating mode.

Confidence Score: 3/5

Safe to merge with caveats — the authorization fix is solid, but the missing initial authentication creates a guaranteed-failure first connection per project and a small event-loss window that should be addressed before production use.

The core authorization concern from the previous review cycle has been properly resolved. However, a P1 logic issue remains: SSEAuthState starts with an empty token, making every project's first SSE connection guaranteed to receive a 401. While the retry loop recovers, it introduces a window where early mutation events can be silently dropped, leaving the cache stale. The 64 KB scanner line-limit is also a real reliability gap for large batch events. Together these two issues are material enough to warrant fixes before merge.

packages/proxy/sse.go — initial token not set in SSEAuthState and default scanner line-size limit both need attention.

Important Files Changed

Filename	Overview
packages/proxy/sse.go	New file implementing SSE-based cache invalidation. Key issues: SSEAuthState starts with an empty token so the first connection for every project always fails with 401 before retrying; default scanner line limit can silently drop large events.
packages/cmd/proxy.go	Adds --use-sse, --client-id, --client-secret flags and wires up SSEManager/SSEAuthState. Cache-serving logic refactored into helper functions. No documentation exists for the new flags yet.
packages/proxy/cache.go	Adds CollectedCacheEntry type and CollectAndPurgeByMutation method to support SSE-triggered refetch. Logic mirrors the existing PurgeByMutation but additionally reads the full entry before eviction so it can be replayed. No issues found.
packages/proxy/resync.go	StartBackgroundLoops updated to accept sseEnabled flag. When SSE is active, the static-secrets refresh ticker is replaced with a nil channel so its case never fires. Clean and correct implementation.
.gitignore	Adds the compiled infisical binary to .gitignore. Correct and necessary.

_{Reviews (2): Last reviewed commit: "change to use httpclient" | Re-trigger Greptile}

[greptile-apps]

--client-secret passed on the command line is visible in the process list

On Linux/macOS, any user with ps aux or access to /proc/<pid>/cmdline can read all command-line arguments, including --client-secret. Consider reading the secret from an environment variable (INFISICAL_CLIENT_SECRET) or a --client-secret-file flag instead.

[adilsitos]

@varonix0 this does not seem to be a huge problem for me, but if you think this is a security problem, I can change it to read this data from other places. I'm also curious to know what are other approaches we could use to have it better (I think that using an env variable for this might not make sense)

[greptile-apps]

This is a real security concern, especially for production environments:

Why it matters:

• Any user on the system can see it: ps aux | grep proxy or cat /proc/<pid>/cmdline
• Shell history may store it: infisical proxy start --client-secret mysecret123
• Container orchestrators (K8s, Docker) often log command-line arguments
• Security scanners flag this pattern

Why env vars aren't much better:

• Still visible in /proc/<pid>/environ (though slightly harder to access)
• Container runtimes and orchestration systems often log them too

Best approach for your use case:
Add a --client-secret-file flag that reads from a file with restricted permissions:

clientSecretFile := cmd.Flags().GetString("client-secret-file")
if clientSecretFile != "" {
    secretBytes, err := os.ReadFile(clientSecretFile)
    if err != nil {
        log.Fatal(err)
    }
    clientSecret = strings.TrimSpace(string(secretBytes))
} else {
    clientSecret = cmd.Flags().GetString("client-secret")
}

Usage:

echo "mysecret" > /etc/infisical/client-secret
chmod 600 /etc/infisical/client-secret
infisical proxy start --client-secret-file /etc/infisical/client-secret

This is the standard pattern used by production tools (Docker, Kubernetes secrets, etc.) and works well in containerized environments where secrets are mounted as files.

[adilsitos]

@greptile check the comments added and the changes. See if the problems still make sense. Update the summary

[adilsitos]

@varonix0 I thought about creating a fallback to the pooling policy in case this happens. The idea is to call the resync static here in a go routine, using a new context. I would also create a new context inside the SSEManager so it is possible to cancel it when the SSE connection happens again. But I'm not sure if this makes sense here, please let me know what you think