fix(helm): support authenticated ServiceMonitor scrapes

[brtydse100]

TLDR

Problem this solves:

• ServiceMonitor scrapes omit required /metrics authorization
• Master-key fallback would expose proxy administrator credentials

How it solves it:

• Reads a dedicated LiteLLM key from an existing Secret
• Renders supported Prometheus Operator authorization with strict validation

User Flow

Before: an operator enables the ServiceMonitor, but Prometheus receives 401 responses because the scrape has no authorization header

1. They create a Kubernetes Secret containing a dedicated LiteLLM key
2. They enable serviceMonitor and reference that Secret in Helm values
3. Prometheus sends GET http://litellm:4000/metrics/
4. The scrape has no authorization header and receives 401

After: the same configuration produces authenticated scrapes and Prometheus can collect LiteLLM metrics

1. They create a Kubernetes Secret containing a dedicated LiteLLM key
2. They enable serviceMonitor and reference that Secret in Helm values
3. Prometheus sends GET http://litellm:4000/metrics/
4. The scrape includes the Secret-backed bearer credential and receives 200

Relevant issues

Linear ticket

Pre-Submission checklist

Please complete all items before asking a LiteLLM maintainer to review your PR

• I have added meaningful tests
• My PR passes all CI/CD checks (e.g., lint, format, unit tests)
• My PR's scope is as isolated as possible; it only solves 1 specific problem
• I have received a Greptile Confidence Score of at least 4/5 before requesting a maintainer review (Greptile reviews automatically once the PR is opened; only comment @greptileai to re-request a review after pushing changes)

Delays in PR merge?

If you're seeing a delay in your PR being merged, ping the LiteLLM Team on Slack (#pr-review)

Screenshots / Proof of Fix

Shared command:

helm template metrics helm/litellm-helm \
  --show-only templates/servicemonitor.yaml \
  --set serviceMonitor.enabled=true \
  --set serviceMonitor.authSecret.enabled=true \
  --set serviceMonitor.authSecret.name=litellm-prometheus-key \
  --set serviceMonitor.authSecret.key=token

Before (d0a815d)

1. Run the shared command against the merge base
2. Observe that the endpoint ends without authentication

scheme: http

After (cd12c77)

1. Run the same command against the PR tip
2. Observe that the endpoint reads bearer credentials from the configured Secret

scheme: http
authorization:
  credentials:
    name: "litellm-prometheus-key"
    key: "token"

Type

Bug Fix

Documentation

Test

Caveats (if any)

• Cluster-level scrape verification requires a Prometheus Operator deployment

Final Attestation

• The tests check the right things, including the edge cases, and regressions in the respective real-world customer use-cases are not possible after this PR

[greptile-apps]

Greptile Summary

This PR adds opt-in bearer-token authentication for Prometheus Operator ServiceMonitor scrapes against the LiteLLM /metrics endpoint, addressing 401 failures when require_auth_for_metrics_endpoint is enabled.

• Adds serviceMonitor.authSecret.{enabled,name,key} values and renders the Prometheus Operator v1 authorization.credentials (SecretKeySelector) block only when opted in, with required guards on both name and key so misconfiguration fails fast at helm template time.
• Drops the previous master-key fallback entirely in favour of requiring an explicit dedicated secret reference, and ships a five-case helm-unittest suite covering the default-off, unauthenticated, authenticated, and both missing-field error paths.

Confidence Score: 5/5

• The change is safe to merge: it is entirely opt-in, does not alter any existing defaults, and the only non-trivial path (rendering the authorization block) is validated by required guards and covered by tests.
• All changes are additive and gated behind a new authSecret.enabled: false default. The template logic is straightforward, the Prometheus Operator v1 authorization.credentials stanza is correctly structured, and the helm-unittest suite covers all meaningful branches including the error paths for missing name and key.
• No files require special attention.

Important Files Changed

Filename	Overview
helm/litellm-helm/templates/servicemonitor.yaml	Adds an authorization.credentials block (Prometheus Operator v1 format) guarded by authSecret.enabled, with required validation on both name and key. Indentation aligns correctly with other endpoint fields. No fallback to master-key secret.
helm/litellm-helm/tests/servicemonitor_tests.yaml	New helm-unittest suite covering: default off, unauthenticated on, authenticated on, and both required-field validations. All cases are meaningful and correctly assert template failure for missing name/key.
helm/litellm-helm/values.yaml	Adds authSecret block nested under serviceMonitor with safe defaults (enabled: false, empty name and key). No existing defaults changed.
helm/litellm-helm/README.md	Documents the new serviceMonitor.authSecret.* values in the reference table and adds a usage example. Content is accurate and matches the template behaviour.
helm/litellm-helm/Chart.yaml	Bumps chart version from 1.1.1 to 1.1.2, which is the correct semver patch increment for a new opt-in feature.

_{Reviews (7): Last reviewed commit: "fix(helm): support authenticated Service..." | Re-trigger Greptile}

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[veria-ai]

PR overview

This pull request updates the Helm deployment configuration and documentation to support authenticated ServiceMonitor scrapes.

One security issue has been addressed, but the production deployment examples still explicitly enable plaintext HTTP. Users who copy these examples could expose bearer tokens and administrative credentials to a network-positioned attacker; the risk depends on deploying the example without adding TLS.

Open issues (1)

• Low: Production deployment examples opt into plaintext HTTP — README.md:451

Fixed/addressed: 1 · PR risk: 4/10

[veria-ai]

Low: Production deployment examples opt into plaintext HTTP

The module defaults fail closed unless TLS is configured, but this new production-oriented example explicitly sets allow_plaintext_alb = true and the GCP example does the same with allow_plaintext_lb = true on line 515. Users who copy the snippets deploy the proxy over HTTP, letting a network attacker capture LiteLLM bearer tokens and admin credentials; keep these flags commented out or show a certificate/domain placeholder instead.

[CLAassistant]

All committers have signed the CLA.

[Sameerlite]

Thanks for your contribution! A few things to get this ready:

• CI is failing — are the failures related to your change? If they're pre-existing or flaky, a quick note would be helpful.

We're also triggering a Greptile code review:

@greptileai

[brtydse100]

Thanks for your contribution! A few things to get this ready:

• CI is failing — are the failures related to your change? If they're pre-existing or flaky, a quick note would be helpful.

We're also triggering a Greptile code review:

@greptileai

Hey,
Thank you for the reply, as far as i know my code is not the reason for the CI failing

[brtydse100]

@greptile-apps

[Sameerlite]

Thanks for the PR! A couple of things to get this over the finish line:

• The CI checks are currently failing — could you take a look? If any failures are pre-existing or unrelated to your change, a quick note in a comment helps us move faster.

Once those are addressed we'll take another look — appreciate the contribution!

[brtydse100]

Ye, I checked the CI checks and from what i can tell they are nor failing because of my pr

[Dentling]

what's the current state of this?
Prometheus needs the auth, since the latest change.

So this functionality in the helm-chart is needed.

[brtydse100]

Hi,
I'm still waiting for a response from the admins.
The feature is basically complete and ready to ship

[mubashir1osmani]

too many unnecessary changes in here, we have sonnet 5 already and a GCP template in the README.

could you explain your problem and what the PR does to solve it ?

[brtydse100]

Yes, the problem I encountered was that if you enabled the ServiceMonitor in the values.yaml in the helm chart, you woudln't receive any metrics from LiteLLM because of a new change that requires authentication in the form of a bearer token to access the /metrics endpoint.
My solution to the problem is adding an option to set your own auth secret or use the default master key for authentication to the /metrics endpoint.

[brtydse100]

@Sameerlite

[codspeed-hq]

Merging this PR will not alter performance

✅ 31 untouched benchmarks

---

_{Comparing brtydse100:feat/fix-authorization-error-in-service-monitor (7bad2db) with litellm_internal_staging (2162da5)}

[brtydse100]

@greptileai

[brtydse100]

@Sameerlite

[brtydse100]

@Sameerlite

I rebased this PR onto the current litellm_internal_staging and addressed the earlier feedback

• reduced to one focused commit touching five Helm files
• removed the insecure master-key fallback and require an explicit metrics credential secret
• added five focused ServiceMonitor test cases
• bumped the chart version to 1.1.3
• helm lint passes and all 102 Helm unit tests pass
• the repository pre-commit gate passes

Could you please review it or assign an appropriate Helm maintainer?