View the index of available developer guides
Plugins commonly store user credentials and similar secrets, like API keys, access tokens, or just user names and passwords, to interface with other systems and services.
Plugins that store such secrets need to be careful how they store them.
With simple String fields that get serialized to disk as plain text, a number of problems can occur:
On many systems, large parts of the Jenkins home directory is accessible to other user accounts, allowing to retrieve credentials stored on disk as plain text.
Backups of Jenkins home can be compromised, disclosing secrets, even when excluding the secrets/ directory.
String fields are round-tripped in configuration forms as plain text even if the value is hidden in a password field, so can be accessed via the HTML page source code. This even applies to users who only have the Extended Read permission.
The easiest solution to all of the above is to store the password as a Secret.
The key to decrypt secrets is stored in the secrets/ directory which has the highest protection, and is recommended to be excluded from backups.
Secret fields are round-tripped in their encrypted form, so that their plain-text form cannot be retrieved by users later.
If a user only has the Extended Read permission, the secret is simply removed from output.
A more advanced option is to integrate with Credentials Plugin. See its documentation for more information.
The easiest way to store secrets is to store them in a field of the type Secret. Jenkins will transparently handle the encryption and decryption.