LEARN. PRACTICE. GROW.Concept and mechanism
A Jenkins credential has an identifier, type, and scope. A job can know its ID without having access in that context. Start diagnosis with those elements before expanding permissions. Binding should last only as long as needed and expose the secret to the authorized command. Avoid Groovy interpolation of sensitive values; prefer shell expansion within appropriate scope and control command printing. Masking reduces accidental log exposure but does not stop a malicious script extracting the value. An agent shared by untrusted code and privileged releases remains a dangerous boundary even when workspace names differ. Treat execution identity and file access as part of the design.
Guided application
In a fictional deployment, a secret file created inside dir can end up in a workspace-browsable temporary area. Create the binding before entering the subdirectory and confirm actual placement; do not archive sensitive files with test results. If exposure occurs, coordinate containment, rotation, and consumers through the incident process while retaining restricted evidence. For recovery, required key material needs secure custody separate from ordinary backups, with a tested procedure for authorized recombination. Also verify distribution origin: current Jenkins WAR files use documented GPG signatures. An internal fingerprint or an old verification instruction does not establish authenticity of the current download.
Token removed from the workspace but still valid: containment is not established.
Common pitfalls
Masking as sandbox; ID as authorization; encrypted secret without recoverable key; private file as revoked credential.
Related topics: Architecture, agents, and traceability · Pipeline: scope, timing, and evidence · Delivery, approval, and retries
Protect the value, the process using it, and the recovery path.
Reference: Credential storage and scope · Jenkins LTS 2.568.3; Java 21 or 25 runtime