Skip to content

Validate admin API provisioner payloads; minor status-code fixes - #2755

Open
coffee4tw wants to merge 9 commits into
masterfrom
thor/admin-api-input-validation
Open

Validate admin API provisioner payloads; minor status-code fixes#2755
coffee4tw wants to merge 9 commits into
masterfrom
thor/admin-api-input-validation

Conversation

@coffee4tw

@coffee4tw coffee4tw commented Jul 29, 2026

Copy link
Copy Markdown

What

Hardens admin provisioner create/update handling and fixes the provisioner
webhook update response:

  • Centralized structural validation for POST/PUT /admin/provisioners:
    new writes reject missing or nil details and require the linkedca details
    oneof to match the declared provisioner type.
  • No duplicated per-type API rules: provisioner-specific semantic
    validation remains in provisioner.Interface.Init.
  • Bad-request classification: request-controlled conversion and initial
    Init failures return structured 400 errors instead of 500s.
  • Upgrade compatibility: legacy persisted records whose type and details
    do not match can still load during admin-resource reload; only new
    Store/Update writes enforce the invariant.
  • Webhook update PUT returns 200 OK instead of 201 Created (create
    still returns 201).
  • Adds a concise CHANGELOG entry under [Unreleased].

Compatibility

Successful, valid provisioner requests are unchanged. Malformed new writes
now fail with 400s. Read/reload conversion deliberately preserves historical
behavior for legacy mismatched records so an upgrade cannot turn one such
record into a CA startup failure.

The shipped ca.AdminClient treats any status below 400 as success on webhook
update, so the 201→200 correction is compatible with existing clients.

Test plan

  • Table-driven coverage for all supported linkedca provisioner details arms,
    missing details, missing oneofs, and typed-nil inner messages.
  • Regression coverage for type/details mismatches on both Store and Update
    returning 400.
  • Regression coverage proving legacy mismatched records still load through
    the admin-resource conversion path.
  • Coverage for invalid Update Init configuration returning 400.
  • Webhook responder coverage pins update at 200 and leaves create at 201.
  • go test ./... passes on the final pushed checkout.
  • go vet ./authority/... passes.
  • Every commit in the PR has a good SSH signature.

🤖 Generated with Claude Code

https://claude.ai/code/session_01LBsTWD57oxThZz44wVy3EL

coffee4tw and others added 5 commits July 29, 2026 15:27
Authority.UpdateProvisioner wrapped Init() failures as an internal
server error (500), unlike StoreProvisioner which correctly treats
them as a client-side configuration problem (400). Bad or incomplete
provisioner details submitted via UpdateProvisioner now surface as a
400, matching StoreProvisioner's behavior.
PUT (update) is not a resource-creation operation, so it should not
return 201 Created. Verified safe against the shipped ca.AdminClient,
which only checks for status >= 400.
@github-actions github-actions Bot added the needs triage Waiting for discussion / prioritization by team label Jul 29, 2026
@CLAassistant

CLAassistant commented Jul 29, 2026

Copy link
Copy Markdown

CLA assistant check
All committers have signed the CLA.

@coffee4tw
coffee4tw requested a review from a team July 30, 2026 11:12
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

needs triage Waiting for discussion / prioritization by team

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants