jenkins v1.0.0

The pack names a reference, never a secret. Installing a pack registers capabilities and makes them governable; registration is not connectivity. The credential is created at the provider and held in the client's own secret manager under the reference the pack names, and deployment testing is still required to show the credential path works and cannot be bypassed.

Reference

secret-ref-jenkins-api-token

Custody

customer_vault

Injection

header (Authorization)

A Jenkins API token for a dedicated service user on the customer's own controller, held in the client's own secret manager. The stored material must be the complete Authorization header value: the word Basic, one separating space, then the base64 encoding of <jenkins-username>:<api-token>. Jenkins documents HTTP Basic authentication with a username and that user's API token for scripted clients, that requests must send the header preemptively because the controller answers unauthenticated requests with 403 rather than challenging with 401, and that tokens are created, revoked and regenerated on the user's own security page ($root/me/security) — revoking a token, or regenerating it, invalidates the previously issued value; Jenkins documents no built-in token expiry, and creating another token does not invalidate existing ones, so the invalidation paths are explicit revocation, regeneration, or removal of the owning user. Jenkins also documents that requests authenticated with a username and API token are exempt from CSRF crumb requirements, which is why this pack registers the API-token scheme rather than session authentication. Use a dedicated least-privilege service user: Overall/Read and Job/Read cover the three read capabilities; job.build.trigger additionally needs Job/Build on the specific jobs only — grant it only where the trigger is enabled, and nothing broader. Renewal ownership sits with an external deployment process: the executor injects the stored value verbatim and performs no token lifecycle itself, and it must never substitute a different credential without an approved pack change. Executor hygiene: the value must live only in executor memory for the lifetime of a call, must never be written to logs, traces or diagnostics, and must not appear in crash dumps; a deployment that cannot meet that bar must not enable the pack.

• jenkins-controller (api, internal): https://jenkins-instance.invalid/

The endpoint host 'jenkins-instance.invalid' is a reserved non-production placeholder (an RFC 2606 reserved TLD): the installer MUST substitute the real controller host into the endpoints, the resource locator and the egress allowlist together — the allowlist matches exactly, so all three must be substituted as one — and re-review the pack before enablement; allowlisting the reserved host does not make an unsubstituted pack safe. The registered shapes assume a controller mounted at the root of its host; a controller mounted under a context path (for example https://host/jenkins) requires substituting that path prefix into every endpoint and the resource locator as part of the host substitution — changing only the authority is not enough. JOB_NAME in the endpoint paths is a placeholder the deployment substitutes at registration time, before enabling, with exactly one URL-encoded job-name segment — a top-level job name. Jobs nested in folders live under the explicit nested shape /job/FOLDER/job/JOB/... with each segment individually encoded; do not encode a folder hierarchy into the JOB_NAME segment, and a deployment that needs a nested job substitutes the full nested path as its own reviewed pack change. Jenkins documentation is instance-version-dependent: the remote API is documented as a generic .../api/ pattern on every object, and the instance's own .../api/ pages are the definitive reference for what each object exposes — confirm the registered paths against the instance before enablement. The CSRF exemption for API-token authentication is documented for Jenkins 2.222 and later. This pack registers only endpoints the Jenkins documentation describes: the top-level /api/json listing, a job's /api/json record, the /computer/api/json agent list, and POST /job/JOB_NAME/build. Documented exclusions: buildWithParameters (which would let the caller inject build parameters beyond what the job defines), build stop and abort, console output and log fetch, job create, delete, copy and configuration, credentials domains, script console, node and agent management, crumb issuance, and every endpoint outside the registered list — a documented exclusion, not an approximated capability; each addition is a pack change and requires its own review. Tiering rationale: reads sit at the R0 floor. job.build.trigger is registered as deploy at the R3 floor because scheduling a build runs the job's configured pipeline, which commonly performs deployments, and deploy is one of the IRREVERSIBLE ACTIONS (delete, send, pay, deploy, approve, share and transfer). AAES has not been certified by the Jenkins project; reviewable default, not a vendor guarantee.

Draft review record dated 2026-09-21 · Reviewer: aaes-eng (an opaque id that resolves internally to the responsible reviewer)

• https://www.jenkins.io/doc/book/using/remote-access-api/ (retrieved 2026-09-21)
• https://www.jenkins.io/doc/book/system-administration/authenticating-scripted-clients/ (retrieved 2026-09-21)
• https://www.jenkins.io/doc/book/security/csrf-protection/ (retrieved 2026-09-21)
• https://javadoc.jenkins.io/hudson/model/ComputerSet.html (retrieved 2026-09-21)

A pack review is not a vendor or examiner attestation. A retrieval date says when a source page was read; it does not by itself establish what the page said then. No pack is vendor-endorsed, and none has been connectivity-tested against a live vendor tenant.