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.

For a list of other such plugins, see the Pipeline Steps Reference page.

HashiCorp Vault Plugin

View this plugin on the Plugins site

withVault: Vault Plugin

  • vaultSecrets
      Array / List of Nested Object
    • path : String
      The path of the secret in the vault server as described here.
    • secretValues
        Array / List of Nested Object
      • vaultKey : String
        The vault key whose value will populate the environment variable.
      • 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 (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 (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 (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 (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 (optional)
    • 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 (optional)
    • skipSslVerification : boolean (optional)
    • timeout : int (optional)
    • vaultCredential (optional)
        Nested Choice of Objects
      • $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'
        • 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'
        • 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'
        • 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'
        • 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'
        • 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'
        • 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 (optional)
    • vaultNamespace : String (optional)
    • vaultUrl : String (optional)

wrap([$class: 'VaultBuildWrapper']): Vault Plugin

  • vaultSecrets
      Array / List of Nested Object
    • path : String
      The path of the secret in the vault server as described here.
    • secretValues
        Array / List of Nested Object
      • vaultKey : String
        The vault key whose value will populate the environment variable.
      • 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 (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 (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 (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 (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 (optional)
    • 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 (optional)
    • skipSslVerification : boolean (optional)
    • timeout : int (optional)
    • vaultCredential (optional)
        Nested Choice of Objects
      • $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'
        • 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'
        • 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'
        • 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'
        • 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'
        • 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'
        • 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 (optional)
    • vaultNamespace : String (optional)
    • vaultUrl : String (optional)

Was this page helpful?

Please submit your feedback about this page through this quick form.

Alternatively, if you don't wish to complete the quick form, you can simply indicate if you found this page helpful?

    


See existing feedback here.