artifactory 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-artifactory-access-token

Custody

customer_vault

Injection

header (Authorization)

A JFrog Platform access token, held in the client's own secret manager. Token issuance is external: an administrator creates a scoped token in the JFrog Platform UI (User Management | Access Tokens) or via the Create Token REST API, and the deployment's custody job stores the result under this reference. The stored material must be the complete Authorization header value (scheme included): 'Bearer ' followed by the access token — JFrog documents using an access token as a bearer token in the Authorization header. JFrog also accepts a reference token as the password half of HTTP Basic authentication; this pack registers the Bearer header form only. Expiry and revocation behavior, stated honestly: tokens are created with an expiry (default one hour; zero means non-expiring and valid until actively revoked), and JFrog's revocable-expiry-threshold (default six hours) means a token created with a shorter lifetime CANNOT be revoked — it remains valid until it expires naturally. Disabling token issuance, or removing the creating admin, does NOT invalidate already-issued tokens; only an explicit revoke of a revocable token, or resetting the token certificates (which revokes ALL tokens), terminates one. Prefer the shortest expiry that covers the deployment's renewal cadence, or a refreshable token renewed by the custody job; an expired value fails closed. Least privilege: create the token with group scopes granting only the permissions the enabled capabilities need (read on the bound repositories; deploy/delete only where the write capabilities are enabled) — never an admin-scoped token FOR THE READ, AQL, DEPLOY AND ITEM-DELETE CAPABILITIES. The repository create and delete capabilities are different: JFrog documents repository administration as requiring an administrator, so this pack registers those two capabilities against a SEPARATE reference (secret-ref-artifactory-admin-token) holding an admin-permission credential — a deployment that cannot justify an admin credential must remove those two capabilities rather than widen the main token. Note also that delete operations require the user or group to hold delete permission per JFrog's documentation. 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.

• artifactory-instance (api, internal): https://artifactory-server.invalid/artifactory

The endpoint host 'artifactory-server.invalid' is a reserved non-production placeholder (an RFC 2606 reserved TLD): substitute the customer's own JFrog Platform Deployment host before enabling, in every endpoint, in the resource locator and in every egress allowlist entry. The allowlist matches exactly, so endpoints and allowlist must be substituted together, and substitution is a required deployment step. REPO_KEY and FILE_PATH in the endpoint paths are placeholders: bind them to the repository key and the item path this capability governs before enabling. This pack registers only Artifactory's documented REST API: listing repositories, storage item info, AQL search, artifact deploy, item delete, repository create and repository delete. Tiering rationale: reads and the read-only AQL query sit at the R0 floor. Artifact deploy (PUT on the item path) is registered as create AND update at the R2 floor: uploading an artifact adds a new binary and, with Artifactory's default non-unique snapshot layouts or release paths, does not destroy other artifacts — but where a repository layout permits overwriting an existing path, a deploy replaces the stored binary, so the update action is declared, and this registration cannot restrict the bytes a caller uploads. Repository create is R2 create; its request body is the full repository configuration, which this registration does not constrain. Item delete and repository delete sit at the R3 floor: delete is one of the IRREVERSIBLE ACTIONS (delete, send, pay, deploy, approve, share and transfer). Repository delete removes the repository and every artifact in it — Artifactory's trash can (when enabled) retains deleted ITEMS but not a deleted repository's configuration — and this registration makes no restoration claim. Search honesty: AQL is a POST carrying a query body (a raw AQL statement, Content-Type text/plain) used read-only — it performs no mutation, so it is registered as a read at the R0 floor with the body shape noted here; the statement itself is unrestricted AQL and can enumerate anything the token's user may read. Documented exclusions: this pack does not register permission-target management (PUT/DELETE /api/security/permissions/...), user or group management, the Access token REST API (token issuance is an external custody process — see the credential note), Empty Trash Can (POST /api/trash/empty — a permanent purge of soft-deleted items, distinct from item delete and deliberately left out), replication configuration, system import/export, and all Xray and Distribution APIs. Source limitation, stated for the reviewer: in this review session the individual JFrog operation pages for repository listing, storage item information, AQL, artifact deploy and repository create/delete could not be retrieved — get-repositories returned 404, deploy-artifact and create-repository returned placeholder/navigation content, and the fetched artifactory-rest-apis index page states JFrog hosts its OpenAPI specifications per project rather than on these pages. The registered methods and existence were taken from the operation index rendered on JFrog's fetched Delete Item page, and the paths are Artifactory's long-standing documented paths. Confirm each path and request contract against the target deployment's own API documentation before enabling — that confirmation is why this pack remains a draft.

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

• https://jfrog.com/help/r/jfrog-rest-apis/delete-item (retrieved 2026-09-21)
• https://jfrog.com/help/r/jfrog-platform-administration-documentation/access-tokens (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.