Skip to content

fix(provider-security): ChefVault Bearer auth for ref probes - #2

Open
OnlineChef wants to merge 2 commits into
mainfrom
fix/provider-security-bearer
Open

fix(provider-security): ChefVault Bearer auth for ref probes#2
OnlineChef wants to merge 2 commits into
mainfrom
fix/provider-security-bearer

Conversation

@OnlineChef

@OnlineChef OnlineChef commented Aug 1, 2026

Copy link
Copy Markdown
Contributor

Summary

  • CPM ChefVaultProviderSecurityClient now sends Authorization: Bearer $CHEF_PROVIDER_SECURITY_TOKEN on protected /v1/refs/* calls; /healthz stays unauthenticated.
  • Optional workload identity via CHEF_WORKLOAD_ID, CHEF_HOST_ID, and CHEF_ACTOR → matching x-chef-* headers when set.
  • cpm policy doctor reports chefvaultReachable (healthz) and chefvaultAuthenticated (Bearer probe) separately so a live health endpoint no longer implies ref access works.
  • Unit tests cover Bearer header wiring, missing-token failure, 401/403 messaging, and doctor auth split.

Context

Closes the cross-repo auth gap after #1 (CPM provider-security plane) and OnlineChefGroep/chefgroep-vault#86 (ChefVault provider-security HTTP with Bearer on /v1/refs/*). CPM previously probed refs without a token and could report ChefVault as healthy while every ref inspection would fail at runtime.

Operator contract

Env Purpose
CHEF_PROVIDER_SECURITY_URL Base URL (existing)
CHEF_PROVIDER_SECURITY_TOKEN Bearer token for /v1/refs/*
CHEF_WORKLOAD_ID / CHEF_HOST_ID / CHEF_ACTOR Optional identity headers (must match Vault token binding)

Test plan

  • npm test (79 tests, incl. test/chefvault-client.test.ts)
  • cpm policy doctor distinguishes reachable vs authenticated (mocked in tests)

Made with Cursor


View with [code]smith
Need help on this PR? Tag @codesmith-bot with what you need. Autofix is enabled.

Greptile Summary

This change adds ChefVault credentials and optional workload-identity headers to protected ref probes while keeping health checks unauthenticated, and updates policy doctor to report reachability and authentication separately.

Focused execution confirmed that protected-ref timeouts, rate limits, and server failures are reported as successful authentication. With a healthy /healthz response, policy doctor can therefore show chefvaultAuthenticated=yes even though protected ref inspection is unavailable.

Confidence Score: 4/5

T-Rex T-Rex Logs

What T-Rex did

  • T-Rex produced a proof for a posted P1 finding.
  • T-Rex produced a second proof for the same posted P1 finding.
  • The contract-validation run showed the fail-closed expectation failed 3/3 due to authentication being true for timeout, 429, and 500, while the reproduction run passed 6/6 for the same scenarios.
  • Artifacts summarizing the fail-closed and reproduction results, plus the TypeScript sources, were attached for review.

View all artifacts

T-Rex Ran code and verified through T-Rex

Comments Outside Diff (1)

  1. General comment

    P1 Protected-ref probe errors are treated as successful authentication

    • Bug
      • When inspectRef() returns a timeout/network error or a non-401/403 HTTP error such as 429 or 500, probeAuthentication() returns { ok: true }. With a successful /healthz, policy doctor consequently reports chefvaultAuthenticated: true and does not add chefvault-unauthenticated.
    • Cause
      • probeAuthentication() only rejects error strings containing (401) or (403) and unconditionally accepts every other failed protected-ref result as evidence that the token was accepted.
    • Fix
      • Only treat the intentionally expected non-auth response (currently 404, if that is the service contract) as authenticated. Return { ok: false, error: status.error } for network failures and all other non-2xx responses.

    T-Rex Ran code and verified through T-Rex

Fix All in Cursor Fix All in Codex Fix All in Claude Code Fix All in Conductor

Prompt To Fix All With AI
### Issue 1
src/provider-security/chefvault-client.ts:77-81
**Non-auth failures pass authentication**

`probeAuthentication` rejects only 401 and 403 responses, then treats every other failed protected-ref probe as proof that the credentials were accepted. A timeout or network error, 429 rate limit, or 500 server error therefore returns `ok: true`; when `/healthz` succeeds, `policy doctor` reports `chefvaultAuthenticated=yes` and omits the authentication issue even though it cannot inspect the protected ref. Only the intentionally expected non-auth response, such as a 404 if that is the service contract, should count as successful authentication; transport and other HTTP failures must remain failures.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

Reviews (1): Last reviewed commit: "fix(provider-security): send Bearer auth..." | Re-trigger Greptile

Greptile also left 1 inline comment on this PR.

CPM policy ref inspection now uses CHEF_PROVIDER_SECURITY_TOKEN and optional
X-Chef-* identity headers on /v1/refs/* while leaving /healthz unauthenticated.
Doctor reports chefvaultReachable vs chefvaultAuthenticated separately.

Co-authored-by: Cursor <cursoragent@cursor.com>
@qodo-code-review

Copy link
Copy Markdown

ⓘ Qodo reviews are paused because your trial has ended. Ask your workspace admin to add credits to resume reviews. Manage billing

@coderabbitai

coderabbitai Bot commented Aug 1, 2026

Copy link
Copy Markdown

Review Change Stack

📝 Walkthrough

Summary by CodeRabbit

  • New Features

    • Added ChefVault bearer-token authentication support.
    • Added optional workload identity headers for provider security requests.
    • Policy diagnostics now report ChefVault reachability and authentication separately.
    • Configuration output indicates whether a provider security token is set.
  • Bug Fixes

    • Improved diagnostics for missing, invalid, or unauthorized ChefVault tokens.
    • Protected reference checks now provide clearer authentication errors.
  • Tests

    • Added coverage for authentication, authorization headers, identity metadata, and diagnostic scenarios.

Walkthrough

ChefVault now supports bearer-token and workload-identity headers. Protected reference inspection and authentication probing distinguish missing, rejected, and accepted credentials. Policy doctor and CLI output report ChefVault reachability and authentication separately.

Changes

ChefVault authentication

Layer / File(s) Summary
ChefVault authentication client
src/provider-security/config.ts, src/provider-security/chefvault-client.ts, test/chefvault-client.test.ts
The client resolves bearer tokens and identity headers. Health checks remain unauthenticated. Protected requests require a token and report distinct 401 and 403 errors.
Policy doctor and CLI reporting
src/provider-security/types.ts, src/provider-security/policy-ops.ts, src/cli.ts, test/provider-security.test.ts
Policy doctor probes authentication after a successful health check. Results and CLI output expose separate reachability and authentication statuses. Tests cover missing, invalid, and valid tokens.

Estimated code review effort: 3 (Moderate) | ~20 minutes

Sequence Diagram(s)

sequenceDiagram
  participant PolicyDoctor
  participant ChefVaultProviderSecurityClient
  participant ChefVault
  PolicyDoctor->>ChefVaultProviderSecurityClient: create client
  PolicyDoctor->>ChefVaultProviderSecurityClient: health()
  ChefVaultProviderSecurityClient->>ChefVault: request /healthz
  ChefVault-->>ChefVaultProviderSecurityClient: health status
  PolicyDoctor->>ChefVaultProviderSecurityClient: probeAuthentication()
  ChefVaultProviderSecurityClient->>ChefVault: request protected reference
  ChefVault-->>ChefVaultProviderSecurityClient: authentication status
  PolicyDoctor-->>PolicyDoctor: report reachability and authentication
Loading

Possibly related PRs

Poem

A token hops through headers bright,
The vault checks every request right.
Health says “reachable”; auth says “true,”
The doctor reports both views.
“Binky!” cheers the rabbit crew.

🚥 Pre-merge checks | ✅ 5
✅ Passed checks (5 passed)
Check name Status Explanation
Docstring Coverage ✅ Passed Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.
Title check ✅ Passed The title clearly and concisely summarizes the main Bearer authentication change for ChefVault reference probes.
Description check ✅ Passed The description directly explains the ChefVault authentication, identity headers, policy doctor changes, tests, and operator configuration.
Linked Issues check ✅ Passed The description references specific related issues and explains how this pull request addresses them.
Out of Scope Changes check ✅ Passed The listed changes remain focused on ChefVault authentication, policy doctor reporting, configuration, and related tests.
✨ Finishing Touches
📝 Generate docstrings
  • Create stacked PR
  • Commit on current branch
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch fix/provider-security-bearer

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@src/provider-security/chefvault-client.ts`:
- Around line 70-82: Update probeAuthentication to preserve the accepted-token
behavior only for the expected 404 response, while returning ok: false for 500
responses, transport errors, and other unexpected failures; retain the existing
401/403 failure handling. Add regression tests covering a 500 response and a
rejected fetch call, using inspectRef and probeAuthentication behavior as the
relevant symbols.
🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

  • Push a commit to this branch (recommended)
  • Create a new PR with the fixes

ℹ️ Review info
⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: 09aba9e1-68c5-4f30-889c-c48daa460ee2

📥 Commits

Reviewing files that changed from the base of the PR and between a23e57f and 5dddc9c.

📒 Files selected for processing (7)
  • src/cli.ts
  • src/provider-security/chefvault-client.ts
  • src/provider-security/config.ts
  • src/provider-security/policy-ops.ts
  • src/provider-security/types.ts
  • test/chefvault-client.test.ts
  • test/provider-security.test.ts

Comment thread src/provider-security/chefvault-client.ts
Co-authored-by: Codesmith <codesmith-bot@users.noreply.github.com>
Comment on lines +77 to +81
if (status.error?.includes("(401)") || status.error?.includes("(403)")) {
return { ok: false, error: status.error };
}
// 404 and other non-auth failures mean the token was accepted.
return { ok: true };

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P1 Non-auth failures pass authentication

probeAuthentication rejects only 401 and 403 responses, then treats every other failed protected-ref probe as proof that the credentials were accepted. A timeout or network error, 429 rate limit, or 500 server error therefore returns ok: true; when /healthz succeeds, policy doctor reports chefvaultAuthenticated=yes and omits the authentication issue even though it cannot inspect the protected ref. Only the intentionally expected non-auth response, such as a 404 if that is the service contract, should count as successful authentication; transport and other HTTP failures must remain failures.

Artifacts

Fail-closed expectation fails for timeout, HTTP 429, and HTTP 500

  • Executed the focused Vitest fail-closed expectation; all three cases received `true` authentication instead of `false`, confirming the defect.

Focused runtime reproduction passes for direct probe and policy doctor

  • Executed six focused tests against the real client and policy-doctor paths; timeout, 429, and 500 each produced authenticated results.

Fail-closed expectation test source

  • Authored Vitest source that invokes the actual authentication probe for each failing protected-ref outcome and expects it to fail closed.

Direct probe and policy-doctor reproduction test source

  • Authored Vitest source that exercises actual client and policy-doctor functions with healthy health checks and failing protected-ref probes.

View artifacts

T-Rex Ran code and verified through T-Rex

Prompt To Fix With AI
This is a comment left during a code review.
Path: src/provider-security/chefvault-client.ts
Line: 77-81

Comment:
**Non-auth failures pass authentication**

`probeAuthentication` rejects only 401 and 403 responses, then treats every other failed protected-ref probe as proof that the credentials were accepted. A timeout or network error, 429 rate limit, or 500 server error therefore returns `ok: true`; when `/healthz` succeeds, `policy doctor` reports `chefvaultAuthenticated=yes` and omits the authentication issue even though it cannot inspect the protected ref. Only the intentionally expected non-auth response, such as a 404 if that is the service contract, should count as successful authentication; transport and other HTTP failures must remain failures.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

Fix in Cursor Fix in Codex Fix in Claude Code Fix in Conductor

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant