Allow commands to be bound to the submitter's certificate

[silug]

Pull Request (PR) description

A command names the node it applies to in its certname parameter, and nothing tied that parameter to the certificate the command was submitted with. Any client permitted to reach /pdb/cmd could therefore replace the facts, catalog, or reports of any node in the fleet, or deactivate it. Forged facts are the sharpest edge of that, since they feed catalog compilation for the node they name.

Submitting for another node is a legitimate need: OpenVox Server submits commands for every agent whose catalog it compiles. So rather than tie every command to its submitter, the new [puppetdb] trusted-submitter-allowlist names the certnames that may do it. Where it is set, any other client may only submit commands for its own certname.

The setting is optional and unset by default, so existing deployments keep working until an operator opts in. The check applies to both command formats, since it runs after request normalization, and it does not constrain requests that presented no certificate at all, which have no name to compare against.

Generated by Claude Code

This Pull Request (PR) fixes the following issues

N/A

[Copilot]

Pull request overview

This PR adds an optional authorization control for the /pdb/cmd command submission endpoint to ensure that, when configured, a client certificate’s CN can only submit commands for its own certname unless the submitter is explicitly allowlisted. This mitigates cross-node command spoofing (notably forged facts) while still supporting legitimate “submit on behalf of” workflows (e.g., OpenVox Server).

Changes:

• Adds submitter-vs-certname authorization middleware to the command HTTP app, backed by a trusted-submitter-allowlist file.
• Wires the new config setting through routing/config and documents it (plus sample config).
• Adds tests covering allowlisted, non-allowlisted, and no-certificate scenarios, including old-format (payload-only) command submissions.

Reviewed changes

Copilot reviewed 7 out of 7 changed files in this pull request and generated no comments.

Show a summary per file

File	Description
src/puppetlabs/puppetdb/http/command.clj	Implements allowlist-backed submitter authorization and wires it into the command middleware stack.
src/puppetlabs/puppetdb/pdb_routing.clj	Passes trusted-submitter-allowlist from config into the command app.
src/puppetlabs/puppetdb/config.clj	Adds schema + accessor for :trusted-submitter-allowlist.
test/puppetlabs/puppetdb/testutils.clj	Extends the command-app test fixture to accept an optional allowlist path.
test/puppetlabs/puppetdb/http/command_test.clj	Adds test coverage for the new submitter authorization behavior.
documentation/configure.markdown	Documents the new trusted-submitter-allowlist setting and its behavior.
config.sample.ini	Adds a commented example for configuring trusted-submitter-allowlist.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[austb]

I think the optional allowlist is a feasible feature for the majority of folks who are not submitting commands from agentless nodes. But I don't think the certname parameter is safe to use as a security check because it may not match the underlying data.

And since OpenVoxDB streams the command data straight to disk for maximum performance. We should not read the POST data at the point of submission because that holds on to the jruby thread in openvox-server for too long.

[austb]

I don't think that OpenVoxDB can use this certname for its certificate check. The actual data stored in the DB is what's in the command's POST body, and there's no requirement that the certname parameter match the certname in the body. So a malicious node could just continue to send their own certname in the parameter while changing the certname in the data to overwrite all the rest of the nodes data.