Exempt /liveness and /readiness from auth#10
Merged
Conversation
Kubernetes liveness and readiness probes can't carry Bearer tokens or API keys, so authenticating them gates the router's own readiness on having a valid token, which is a chicken-and-egg problem when JWT verification is enabled: /readiness -> 401 -> probe fails -> pod NotReady -> service has no ready endpoints -> platform's find_router_url returns None -> the orchestrator bypasses the router entirely -> no per-run metrics The endpoints expose no sensitive data — just 'process is alive' and 'at least one worker is ready' — so it's safe to leave them open. User-facing /health and /health_generate keep auth.
ApprovabilityVerdict: Needs human review This PR removes authentication checks from You can customize Macroscope's approvability policy. Learn more. |
Merged
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
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.
Kubernetes liveness and readiness probes can't carry Bearer tokens or API keys, so authenticating them gates the router's own readiness on having a valid token. When JWT verification is enabled this becomes a chicken-and-egg problem:
/readiness→ 401 → probe fails → pod NotReady → service has no ready endpoints → upstream consumers (e.g. the platform'sfind_router_url) fall back to bypassing the router → no per-run metricsToday this only matters once you turn on
--jwt-public-key-path(or--api-key-validation-urls), so prod is unaffected. But it blocks the JWT rollout the moment you flip it on.The probes expose no sensitive information — just "process is alive" and "at least one worker is ready" — so it's safe to leave them open. User-facing
/healthand/health_generatekeep auth.Companion to PrimeIntellect-ai/platform#914 and #6.
Note
Medium Risk
Changes authentication behavior by making two endpoints publicly accessible, which could be abused for lightweight service discovery but exposes only minimal status information.
Overview
Removes the auth check from
/livenessand/readinessso Kubernetes probes continue to work when JWT or API-key validation is enabled.Adds an explicit comment documenting why these endpoints are intentionally unauthenticated, while
/health(and other routes) remain protected byauthorize_request.Reviewed by Cursor Bugbot for commit 6dcbd14. Bugbot is set up for automated code reviews on this repo. Configure here.
Note
Exempt /liveness and /readiness endpoints from authentication
The
/livenessand/readinesshandlers in server.rs no longer extract headers or callauthorize_request. Both endpoints now unconditionally return the router's liveness/readiness response, making them accessible without credentials.Macroscope summarized 6dcbd14.