The following plugin provides functionality available through
Pipeline-compatible steps. Read more about how to integrate steps into your
Pipeline in the
Steps
section of the
Pipeline Syntax
page.
The path of the secret in the vault server as described here.
secretValues
secretValues
Array / List of Nested Object
vaultKey : String
vaultKey : String
The vault key whose value will populate the environment variable.
envVar : String
envVar : String (optional)
The environment variable to set with the value of the vault key.
If field is left empty. The value from vault key will be used for environment variable.
isRequired : boolean
isRequired : boolean (optional)
A toggle to determine if the given Vault secret value must be present in your secret
If checked, the value is required; the plugin will throw an error if the value is not found in the secret.
engineVersion : int
engineVersion : int (optional)
The vault K/V engine version. Currently supports versions 1 or 2. (Only applicable when using vaults Key/Value secrets engine. See here)
If set to default it will use what is configured on folder or global configuration.
configuration (optional)
Nested Object
disableChildPoliciesOverride : boolean
disableChildPoliciesOverride : boolean (optional)
If set, this will disable any child folder or job from overriding the job policies. This prevents the escalation of privileges by subfolders or jobs.
engineVersion : int
engineVersion : int (optional)
The vault K/V engine version. Currently supports versions 1 or 2. (Only applicable when using vaults Key/Value secrets engine. See here)
If set to default it will use what is configured on folder or global configuration.
failIfNotFound : boolean
failIfNotFound : boolean (optional)
policies : String
policies : String (optional)
The Vault policies to use when requesting a token for a job, separated by newlines. If left empty, this will use all policies from the configured authentication. This is useful for AppRole authentication where the AppRole can have many policies attached it and divide up the policies per job based on the job folder or name. This allows you to restrict access on specific jobs or folders. Each policy can use the following tokens to templatize the policies:
${job_base_name} - equal to the JOB_BASE_NAME env var
${job_name} - equal to the JOB_NAME env var
${job_name_us} - same as ${job_name} with slashes converted to underscores
${job_folder} - the folder of the job (JOB_NAME - JOB_BASE_NAME without the trailing slash)
${job_folder_us} - same as ${job_folder} with slashes converted to underscores
${node_name} - equal to the NODE_NAME env var
For example, a policy list such as:
pol_jenkins_base
pol_jenkins_job_base_${job_base_name}
pol_jenkins_folder_us_${job_name_folder_us}
pol_jenkins/folder/${job_folder}
pol_jenkins_job_us_${job_name_us}
pol_jenkins/job/${job_name}
Would result in six policies being applied to each job run. If the JOB_NAME was "folder1/folder2/job1" and the JOB_BASE_NAME was "job1", the policies applied would be:
pol_jenkins_base
pol_jenkins_job_base_job1
pol_jenkins_folder_us_folder1_folder2
pol_jenkins/folder/folder1/folder2
pol_jenkins_job_us_folder1_folder2_job1
pol_jenkins/job/folder1/folder2/job1
Please note that the AppRole should have all policies configured as token_policies and not identity_policies, as job-specific tokens inherit all identity_policies automatically.
prefixPath : String
prefixPath : String (optional)
skipSslVerification : boolean
skipSslVerification : boolean (optional)
timeout : int
timeout : int (optional)
vaultCredential
vaultCredential (optional)
Nested Choice of Objects
$class: 'VaultAppRoleCredential'
$class: 'VaultAppRoleCredential'
scope
Determines where this credential can be used.
System
This credential is only available to the object on which the credential is associated. Typically you would use system-scoped credentials for things like email auth, agent connection, etc, i.e. where the Jenkins instance itself is using the credential. Unlike the global scope, this significantly restricts where the credential can be used, thereby providing a higher degree of confidentiality to the credential.
Global
This credential is available to the object on which the credential is associated and all objects that are children of that object. Typically you would use global-scoped credentials for things that are needed by jobs.
In general, a credential is defined in one place (e.g., the credentials configuration page under "Manage Jenkins") and then used in another place (e.g., when connecting to a new SSH build agent). The scope allows you to say "this credential is only used by these places" by looking at the relationship between the two locations.
Values:SYSTEM, GLOBAL, USER
id : String
An internal unique ID by which these credentials are identified from jobs and other configuration. Normally left blank, in which case an ID will be generated, which is fine for jobs created using visual forms. Useful to specify explicitly when using credentials from scripted configuration.
description : String
An optional description to help tell similar credentials apart.
roleId : String
secretId
Type:class hudson.util.Secret
path : String
namespace : String (optional)
The Vault Namespace the mount path is located. If the auth mount path is on the root namespace use "/", if namespace is empty the global namespace or credential namespace will be used if specified.
Note: Namespaces are a feature of Vault Enterprise.
usePolicies : boolean (optional)
If checked and policies are defined in the Vault plugin configuration, a child token will be provisioned after authenticating with Vault with only the configured policies. See the Vault plugin configuration policies for more information.
$class: 'VaultAwsIamCredential'
$class: 'VaultAwsIamCredential'
scope
Determines where this credential can be used.
System
This credential is only available to the object on which the credential is associated. Typically you would use system-scoped credentials for things like email auth, agent connection, etc, i.e. where the Jenkins instance itself is using the credential. Unlike the global scope, this significantly restricts where the credential can be used, thereby providing a higher degree of confidentiality to the credential.
Global
This credential is available to the object on which the credential is associated and all objects that are children of that object. Typically you would use global-scoped credentials for things that are needed by jobs.
In general, a credential is defined in one place (e.g., the credentials configuration page under "Manage Jenkins") and then used in another place (e.g., when connecting to a new SSH build agent). The scope allows you to say "this credential is only used by these places" by looking at the relationship between the two locations.
Values:SYSTEM, GLOBAL, USER
id : String
An internal unique ID by which these credentials are identified from jobs and other configuration. Normally left blank, in which case an ID will be generated, which is fine for jobs created using visual forms. Useful to specify explicitly when using credentials from scripted configuration.
description : String
An optional description to help tell similar credentials apart.
mountPath : String (optional)
namespace : String (optional)
The Vault Namespace the mount path is located. If the auth mount path is on the root namespace use "/", if namespace is empty the global namespace or credential namespace will be used if specified.
Note: Namespaces are a feature of Vault Enterprise.
role : String (optional)
The IAM role to authenticate with. If this is left blank, Vault will use the role in the sts:GetCallerIdentity response.
serverId : String (optional)
The value to supply in the X-Vault-AWS-IAM-Server-ID header of the sts:GetCallerIdentity request. This must match the value configured in the Vault AWS IAM auth method if the header is required.
usePolicies : boolean (optional)
If checked and policies are defined in the Vault plugin configuration, a child token will be provisioned after authenticating with Vault with only the configured policies. See the Vault plugin configuration policies for more information.
$class: 'VaultGCPCredential'
$class: 'VaultGCPCredential'
scope
Determines where this credential can be used.
System
This credential is only available to the object on which the credential is associated. Typically you would use system-scoped credentials for things like email auth, agent connection, etc, i.e. where the Jenkins instance itself is using the credential. Unlike the global scope, this significantly restricts where the credential can be used, thereby providing a higher degree of confidentiality to the credential.
Global
This credential is available to the object on which the credential is associated and all objects that are children of that object. Typically you would use global-scoped credentials for things that are needed by jobs.
In general, a credential is defined in one place (e.g., the credentials configuration page under "Manage Jenkins") and then used in another place (e.g., when connecting to a new SSH build agent). The scope allows you to say "this credential is only used by these places" by looking at the relationship between the two locations.
Values:SYSTEM, GLOBAL, USER
id : String
An internal unique ID by which these credentials are identified from jobs and other configuration. Normally left blank, in which case an ID will be generated, which is fine for jobs created using visual forms. Useful to specify explicitly when using credentials from scripted configuration.
description : String
An optional description to help tell similar credentials apart.
role : String
audience : String
namespace : String (optional)
The Vault Namespace the mount path is located. If the auth mount path is on the root namespace use "/", if namespace is empty the global namespace or credential namespace will be used if specified.
Note: Namespaces are a feature of Vault Enterprise.
usePolicies : boolean (optional)
If checked and policies are defined in the Vault plugin configuration, a child token will be provisioned after authenticating with Vault with only the configured policies. See the Vault plugin configuration policies for more information.
$class: 'VaultGithubTokenCredential'
$class: 'VaultGithubTokenCredential'
scope
Determines where this credential can be used.
System
This credential is only available to the object on which the credential is associated. Typically you would use system-scoped credentials for things like email auth, agent connection, etc, i.e. where the Jenkins instance itself is using the credential. Unlike the global scope, this significantly restricts where the credential can be used, thereby providing a higher degree of confidentiality to the credential.
Global
This credential is available to the object on which the credential is associated and all objects that are children of that object. Typically you would use global-scoped credentials for things that are needed by jobs.
In general, a credential is defined in one place (e.g., the credentials configuration page under "Manage Jenkins") and then used in another place (e.g., when connecting to a new SSH build agent). The scope allows you to say "this credential is only used by these places" by looking at the relationship between the two locations.
Values:SYSTEM, GLOBAL, USER
id : String
An internal unique ID by which these credentials are identified from jobs and other configuration. Normally left blank, in which case an ID will be generated, which is fine for jobs created using visual forms. Useful to specify explicitly when using credentials from scripted configuration.
description : String
An optional description to help tell similar credentials apart.
accessToken
Type:class hudson.util.Secret
mountPath : String (optional)
namespace : String (optional)
The Vault Namespace the mount path is located. If the auth mount path is on the root namespace use "/", if namespace is empty the global namespace or credential namespace will be used if specified.
Note: Namespaces are a feature of Vault Enterprise.
usePolicies : boolean (optional)
If checked and policies are defined in the Vault plugin configuration, a child token will be provisioned after authenticating with Vault with only the configured policies. See the Vault plugin configuration policies for more information.
$class: 'VaultKubernetesCredential'
$class: 'VaultKubernetesCredential'
scope
Determines where this credential can be used.
System
This credential is only available to the object on which the credential is associated. Typically you would use system-scoped credentials for things like email auth, agent connection, etc, i.e. where the Jenkins instance itself is using the credential. Unlike the global scope, this significantly restricts where the credential can be used, thereby providing a higher degree of confidentiality to the credential.
Global
This credential is available to the object on which the credential is associated and all objects that are children of that object. Typically you would use global-scoped credentials for things that are needed by jobs.
In general, a credential is defined in one place (e.g., the credentials configuration page under "Manage Jenkins") and then used in another place (e.g., when connecting to a new SSH build agent). The scope allows you to say "this credential is only used by these places" by looking at the relationship between the two locations.
Values:SYSTEM, GLOBAL, USER
id : String
An internal unique ID by which these credentials are identified from jobs and other configuration. Normally left blank, in which case an ID will be generated, which is fine for jobs created using visual forms. Useful to specify explicitly when using credentials from scripted configuration.
description : String
An optional description to help tell similar credentials apart.
role : String
mountPath : String (optional)
namespace : String (optional)
The Vault Namespace the mount path is located. If the auth mount path is on the root namespace use "/", if namespace is empty the global namespace or credential namespace will be used if specified.
Note: Namespaces are a feature of Vault Enterprise.
usePolicies : boolean (optional)
If checked and policies are defined in the Vault plugin configuration, a child token will be provisioned after authenticating with Vault with only the configured policies. See the Vault plugin configuration policies for more information.
$class: 'VaultTokenCredential'
$class: 'VaultTokenCredential'
scope
Determines where this credential can be used.
System
This credential is only available to the object on which the credential is associated. Typically you would use system-scoped credentials for things like email auth, agent connection, etc, i.e. where the Jenkins instance itself is using the credential. Unlike the global scope, this significantly restricts where the credential can be used, thereby providing a higher degree of confidentiality to the credential.
Global
This credential is available to the object on which the credential is associated and all objects that are children of that object. Typically you would use global-scoped credentials for things that are needed by jobs.
In general, a credential is defined in one place (e.g., the credentials configuration page under "Manage Jenkins") and then used in another place (e.g., when connecting to a new SSH build agent). The scope allows you to say "this credential is only used by these places" by looking at the relationship between the two locations.
Values:SYSTEM, GLOBAL, USER
id : String
An internal unique ID by which these credentials are identified from jobs and other configuration. Normally left blank, in which case an ID will be generated, which is fine for jobs created using visual forms. Useful to specify explicitly when using credentials from scripted configuration.
description : String
An optional description to help tell similar credentials apart.
token
Type:class hudson.util.Secret
$class: 'VaultTokenFileCredential'
$class: 'VaultTokenFileCredential'
scope
Determines where this credential can be used.
System
This credential is only available to the object on which the credential is associated. Typically you would use system-scoped credentials for things like email auth, agent connection, etc, i.e. where the Jenkins instance itself is using the credential. Unlike the global scope, this significantly restricts where the credential can be used, thereby providing a higher degree of confidentiality to the credential.
Global
This credential is available to the object on which the credential is associated and all objects that are children of that object. Typically you would use global-scoped credentials for things that are needed by jobs.
In general, a credential is defined in one place (e.g., the credentials configuration page under "Manage Jenkins") and then used in another place (e.g., when connecting to a new SSH build agent). The scope allows you to say "this credential is only used by these places" by looking at the relationship between the two locations.
Values:SYSTEM, GLOBAL, USER
id : String
An internal unique ID by which these credentials are identified from jobs and other configuration. Normally left blank, in which case an ID will be generated, which is fine for jobs created using visual forms. Useful to specify explicitly when using credentials from scripted configuration.
description : String
An optional description to help tell similar credentials apart.
filepath : String
vaultCredentialId : String
vaultCredentialId : String (optional)
vaultNamespace : String
vaultNamespace : String (optional)
vaultUrl : String
vaultUrl : String (optional)
wrap([$class: 'VaultBuildWrapper']): Vault Plugin
vaultSecrets
Array / List of Nested Object
path : String
path : String
The path of the secret in the vault server as described here.
secretValues
secretValues
Array / List of Nested Object
vaultKey : String
vaultKey : String
The vault key whose value will populate the environment variable.
envVar : String
envVar : String (optional)
The environment variable to set with the value of the vault key.
If field is left empty. The value from vault key will be used for environment variable.
isRequired : boolean
isRequired : boolean (optional)
A toggle to determine if the given Vault secret value must be present in your secret
If checked, the value is required; the plugin will throw an error if the value is not found in the secret.
engineVersion : int
engineVersion : int (optional)
The vault K/V engine version. Currently supports versions 1 or 2. (Only applicable when using vaults Key/Value secrets engine. See here)
If set to default it will use what is configured on folder or global configuration.
configuration (optional)
Nested Object
disableChildPoliciesOverride : boolean
disableChildPoliciesOverride : boolean (optional)
If set, this will disable any child folder or job from overriding the job policies. This prevents the escalation of privileges by subfolders or jobs.
engineVersion : int
engineVersion : int (optional)
The vault K/V engine version. Currently supports versions 1 or 2. (Only applicable when using vaults Key/Value secrets engine. See here)
If set to default it will use what is configured on folder or global configuration.
failIfNotFound : boolean
failIfNotFound : boolean (optional)
policies : String
policies : String (optional)
The Vault policies to use when requesting a token for a job, separated by newlines. If left empty, this will use all policies from the configured authentication. This is useful for AppRole authentication where the AppRole can have many policies attached it and divide up the policies per job based on the job folder or name. This allows you to restrict access on specific jobs or folders. Each policy can use the following tokens to templatize the policies:
${job_base_name} - equal to the JOB_BASE_NAME env var
${job_name} - equal to the JOB_NAME env var
${job_name_us} - same as ${job_name} with slashes converted to underscores
${job_folder} - the folder of the job (JOB_NAME - JOB_BASE_NAME without the trailing slash)
${job_folder_us} - same as ${job_folder} with slashes converted to underscores
${node_name} - equal to the NODE_NAME env var
For example, a policy list such as:
pol_jenkins_base
pol_jenkins_job_base_${job_base_name}
pol_jenkins_folder_us_${job_name_folder_us}
pol_jenkins/folder/${job_folder}
pol_jenkins_job_us_${job_name_us}
pol_jenkins/job/${job_name}
Would result in six policies being applied to each job run. If the JOB_NAME was "folder1/folder2/job1" and the JOB_BASE_NAME was "job1", the policies applied would be:
pol_jenkins_base
pol_jenkins_job_base_job1
pol_jenkins_folder_us_folder1_folder2
pol_jenkins/folder/folder1/folder2
pol_jenkins_job_us_folder1_folder2_job1
pol_jenkins/job/folder1/folder2/job1
Please note that the AppRole should have all policies configured as token_policies and not identity_policies, as job-specific tokens inherit all identity_policies automatically.
prefixPath : String
prefixPath : String (optional)
skipSslVerification : boolean
skipSslVerification : boolean (optional)
timeout : int
timeout : int (optional)
vaultCredential
vaultCredential (optional)
Nested Choice of Objects
$class: 'VaultAppRoleCredential'
$class: 'VaultAppRoleCredential'
scope
Determines where this credential can be used.
System
This credential is only available to the object on which the credential is associated. Typically you would use system-scoped credentials for things like email auth, agent connection, etc, i.e. where the Jenkins instance itself is using the credential. Unlike the global scope, this significantly restricts where the credential can be used, thereby providing a higher degree of confidentiality to the credential.
Global
This credential is available to the object on which the credential is associated and all objects that are children of that object. Typically you would use global-scoped credentials for things that are needed by jobs.
In general, a credential is defined in one place (e.g., the credentials configuration page under "Manage Jenkins") and then used in another place (e.g., when connecting to a new SSH build agent). The scope allows you to say "this credential is only used by these places" by looking at the relationship between the two locations.
Values:SYSTEM, GLOBAL, USER
id : String
An internal unique ID by which these credentials are identified from jobs and other configuration. Normally left blank, in which case an ID will be generated, which is fine for jobs created using visual forms. Useful to specify explicitly when using credentials from scripted configuration.
description : String
An optional description to help tell similar credentials apart.
roleId : String
secretId
Type:class hudson.util.Secret
path : String
namespace : String (optional)
The Vault Namespace the mount path is located. If the auth mount path is on the root namespace use "/", if namespace is empty the global namespace or credential namespace will be used if specified.
Note: Namespaces are a feature of Vault Enterprise.
usePolicies : boolean (optional)
If checked and policies are defined in the Vault plugin configuration, a child token will be provisioned after authenticating with Vault with only the configured policies. See the Vault plugin configuration policies for more information.
$class: 'VaultAwsIamCredential'
$class: 'VaultAwsIamCredential'
scope
Determines where this credential can be used.
System
This credential is only available to the object on which the credential is associated. Typically you would use system-scoped credentials for things like email auth, agent connection, etc, i.e. where the Jenkins instance itself is using the credential. Unlike the global scope, this significantly restricts where the credential can be used, thereby providing a higher degree of confidentiality to the credential.
Global
This credential is available to the object on which the credential is associated and all objects that are children of that object. Typically you would use global-scoped credentials for things that are needed by jobs.
In general, a credential is defined in one place (e.g., the credentials configuration page under "Manage Jenkins") and then used in another place (e.g., when connecting to a new SSH build agent). The scope allows you to say "this credential is only used by these places" by looking at the relationship between the two locations.
Values:SYSTEM, GLOBAL, USER
id : String
An internal unique ID by which these credentials are identified from jobs and other configuration. Normally left blank, in which case an ID will be generated, which is fine for jobs created using visual forms. Useful to specify explicitly when using credentials from scripted configuration.
description : String
An optional description to help tell similar credentials apart.
mountPath : String (optional)
namespace : String (optional)
The Vault Namespace the mount path is located. If the auth mount path is on the root namespace use "/", if namespace is empty the global namespace or credential namespace will be used if specified.
Note: Namespaces are a feature of Vault Enterprise.
role : String (optional)
The IAM role to authenticate with. If this is left blank, Vault will use the role in the sts:GetCallerIdentity response.
serverId : String (optional)
The value to supply in the X-Vault-AWS-IAM-Server-ID header of the sts:GetCallerIdentity request. This must match the value configured in the Vault AWS IAM auth method if the header is required.
usePolicies : boolean (optional)
If checked and policies are defined in the Vault plugin configuration, a child token will be provisioned after authenticating with Vault with only the configured policies. See the Vault plugin configuration policies for more information.
$class: 'VaultGCPCredential'
$class: 'VaultGCPCredential'
scope
Determines where this credential can be used.
System
This credential is only available to the object on which the credential is associated. Typically you would use system-scoped credentials for things like email auth, agent connection, etc, i.e. where the Jenkins instance itself is using the credential. Unlike the global scope, this significantly restricts where the credential can be used, thereby providing a higher degree of confidentiality to the credential.
Global
This credential is available to the object on which the credential is associated and all objects that are children of that object. Typically you would use global-scoped credentials for things that are needed by jobs.
In general, a credential is defined in one place (e.g., the credentials configuration page under "Manage Jenkins") and then used in another place (e.g., when connecting to a new SSH build agent). The scope allows you to say "this credential is only used by these places" by looking at the relationship between the two locations.
Values:SYSTEM, GLOBAL, USER
id : String
An internal unique ID by which these credentials are identified from jobs and other configuration. Normally left blank, in which case an ID will be generated, which is fine for jobs created using visual forms. Useful to specify explicitly when using credentials from scripted configuration.
description : String
An optional description to help tell similar credentials apart.
role : String
audience : String
namespace : String (optional)
The Vault Namespace the mount path is located. If the auth mount path is on the root namespace use "/", if namespace is empty the global namespace or credential namespace will be used if specified.
Note: Namespaces are a feature of Vault Enterprise.
usePolicies : boolean (optional)
If checked and policies are defined in the Vault plugin configuration, a child token will be provisioned after authenticating with Vault with only the configured policies. See the Vault plugin configuration policies for more information.
$class: 'VaultGithubTokenCredential'
$class: 'VaultGithubTokenCredential'
scope
Determines where this credential can be used.
System
This credential is only available to the object on which the credential is associated. Typically you would use system-scoped credentials for things like email auth, agent connection, etc, i.e. where the Jenkins instance itself is using the credential. Unlike the global scope, this significantly restricts where the credential can be used, thereby providing a higher degree of confidentiality to the credential.
Global
This credential is available to the object on which the credential is associated and all objects that are children of that object. Typically you would use global-scoped credentials for things that are needed by jobs.
In general, a credential is defined in one place (e.g., the credentials configuration page under "Manage Jenkins") and then used in another place (e.g., when connecting to a new SSH build agent). The scope allows you to say "this credential is only used by these places" by looking at the relationship between the two locations.
Values:SYSTEM, GLOBAL, USER
id : String
An internal unique ID by which these credentials are identified from jobs and other configuration. Normally left blank, in which case an ID will be generated, which is fine for jobs created using visual forms. Useful to specify explicitly when using credentials from scripted configuration.
description : String
An optional description to help tell similar credentials apart.
accessToken
Type:class hudson.util.Secret
mountPath : String (optional)
namespace : String (optional)
The Vault Namespace the mount path is located. If the auth mount path is on the root namespace use "/", if namespace is empty the global namespace or credential namespace will be used if specified.
Note: Namespaces are a feature of Vault Enterprise.
usePolicies : boolean (optional)
If checked and policies are defined in the Vault plugin configuration, a child token will be provisioned after authenticating with Vault with only the configured policies. See the Vault plugin configuration policies for more information.
$class: 'VaultKubernetesCredential'
$class: 'VaultKubernetesCredential'
scope
Determines where this credential can be used.
System
This credential is only available to the object on which the credential is associated. Typically you would use system-scoped credentials for things like email auth, agent connection, etc, i.e. where the Jenkins instance itself is using the credential. Unlike the global scope, this significantly restricts where the credential can be used, thereby providing a higher degree of confidentiality to the credential.
Global
This credential is available to the object on which the credential is associated and all objects that are children of that object. Typically you would use global-scoped credentials for things that are needed by jobs.
In general, a credential is defined in one place (e.g., the credentials configuration page under "Manage Jenkins") and then used in another place (e.g., when connecting to a new SSH build agent). The scope allows you to say "this credential is only used by these places" by looking at the relationship between the two locations.
Values:SYSTEM, GLOBAL, USER
id : String
An internal unique ID by which these credentials are identified from jobs and other configuration. Normally left blank, in which case an ID will be generated, which is fine for jobs created using visual forms. Useful to specify explicitly when using credentials from scripted configuration.
description : String
An optional description to help tell similar credentials apart.
role : String
mountPath : String (optional)
namespace : String (optional)
The Vault Namespace the mount path is located. If the auth mount path is on the root namespace use "/", if namespace is empty the global namespace or credential namespace will be used if specified.
Note: Namespaces are a feature of Vault Enterprise.
usePolicies : boolean (optional)
If checked and policies are defined in the Vault plugin configuration, a child token will be provisioned after authenticating with Vault with only the configured policies. See the Vault plugin configuration policies for more information.
$class: 'VaultTokenCredential'
$class: 'VaultTokenCredential'
scope
Determines where this credential can be used.
System
This credential is only available to the object on which the credential is associated. Typically you would use system-scoped credentials for things like email auth, agent connection, etc, i.e. where the Jenkins instance itself is using the credential. Unlike the global scope, this significantly restricts where the credential can be used, thereby providing a higher degree of confidentiality to the credential.
Global
This credential is available to the object on which the credential is associated and all objects that are children of that object. Typically you would use global-scoped credentials for things that are needed by jobs.
In general, a credential is defined in one place (e.g., the credentials configuration page under "Manage Jenkins") and then used in another place (e.g., when connecting to a new SSH build agent). The scope allows you to say "this credential is only used by these places" by looking at the relationship between the two locations.
Values:SYSTEM, GLOBAL, USER
id : String
An internal unique ID by which these credentials are identified from jobs and other configuration. Normally left blank, in which case an ID will be generated, which is fine for jobs created using visual forms. Useful to specify explicitly when using credentials from scripted configuration.
description : String
An optional description to help tell similar credentials apart.
token
Type:class hudson.util.Secret
$class: 'VaultTokenFileCredential'
$class: 'VaultTokenFileCredential'
scope
Determines where this credential can be used.
System
This credential is only available to the object on which the credential is associated. Typically you would use system-scoped credentials for things like email auth, agent connection, etc, i.e. where the Jenkins instance itself is using the credential. Unlike the global scope, this significantly restricts where the credential can be used, thereby providing a higher degree of confidentiality to the credential.
Global
This credential is available to the object on which the credential is associated and all objects that are children of that object. Typically you would use global-scoped credentials for things that are needed by jobs.
In general, a credential is defined in one place (e.g., the credentials configuration page under "Manage Jenkins") and then used in another place (e.g., when connecting to a new SSH build agent). The scope allows you to say "this credential is only used by these places" by looking at the relationship between the two locations.
Values:SYSTEM, GLOBAL, USER
id : String
An internal unique ID by which these credentials are identified from jobs and other configuration. Normally left blank, in which case an ID will be generated, which is fine for jobs created using visual forms. Useful to specify explicitly when using credentials from scripted configuration.
description : String
An optional description to help tell similar credentials apart.