CyberArk Credential Provider Plugin

15 minute readSecurity

The CyberArk Credential Provider enables additional credential stores for CloudBees CI where the credentials are stored in a remote CyberArk Application Identity Manager vault and the secrets are only accessed on demand. The result is that CloudBees CI sees the updated passwords from the CyberArk Application Identity Manager vault.

Prerequisites

The CloudBees CyberArk Credential Provider Plugin 1.0.5 release has the following software requirements:

  • CloudBees CI on modern cloud platforms and CloudBees CI on traditional platforms 2.222.1.1 (or newer)

  • Jenkins Credentials Plugin 2.1.12 (or newer)

  • CyberArk Enterprise Password Vault 7.2 (or newer)

  • CyberArk Central Credential Provider Web Service (version appropriate to CyberArk Enterprise Password Vault)

Architecture overview

A basic architectural overview is illustrated below.

Architecture overview

Some notes on the above architecture:

  • The diagram illustrates the service interactions only.

  • For the sake of simplicity, we have shown a minimal deployment of the CyberArk services. Consult the CyberArk documentation for a recommended CyberArk deployment.

    The CyberArk documentation recommends that the Central Credentials Provider be deployed on a different server from the Enterprise Password Vault, which is why we show two servers.
  • We have illustrated a deployment involving both operations center and CloudBees CI.

While it is not strictly necessary to deploy and configure the CloudBees CyberArk Credential Provider on both, for availability and continuity of service it is recommended that the CyberArk Credential Provider be deployed and configured on both, because this will allow the CloudBees CI service to have continued access to CyberArk credentials in the event that its connection to operations center is interrupted.

Communication between the various services is as follows:

  • For details on the communication protocols between the CyberArk Credential Provider server and the CyberArk Enterprise Password Vault server, please consult the CyberArk documentation.

  • The communication between CloudBees CI and operations center is using the standard Jenkins remoting protocol used between CloudBees CI and operations center.

  • The communication between the CloudBees CyberArk Credential Provider and the CyberArk Credential Provider Web Service depends on how the hosting Microsoft IIS service has been configured.

    • The CyberArk recommended configuration is that CyberArk Credential Provider Web Service be deployed on a Microsoft IIS service bound to a TLS secured port only.

      In such cases the recommendation is to use client certificates to authenticate client connections.

      HTTP BASIC authentication can also be used but is considered less secure.

    • An alternative configuration is available where the Jenkins instance is running on the same machine as the CyberArk Credential Provider Web Service.

      This would require that the Jenkins instance be running on Microsoft Windows as it is not possible to run the CyberArk Credential Provider Web Service on a unix server.

      In the event that the Microsoft IIS service is exclusively bound to the localhost interface, a suitably locked down Jenkins installation could be trusted to connect to the CyberArk Credential Provider Web Service without any authentication.

CloudBees does not recommend this deployment option as it requires significant hardening of the Jenkins controller, e.g. ensuring that the ability to run scripts has been removed from all untrusted users, configuration of strict script security, prevention of builds on the controller, etc.

It is helpful to understand the credentials resolution process.

  • Credentials resolution on operations center.

    • When a request is made for a credential on operations center this request will be initiated by a plugin using the Credentials API.

    • The Credentials API will construct a list of all the enabled CredentialProvider extensions in the Jenkins instance.

    • Each enabled provider will be consulted.

    • When the CloudBees CyberArk Credential Provider is consulted it will look at its list of CyberArk Object IDs.

      Due to restrictions in the APIs exposed by CyberArk, it may be necessary for the CloudBees CyberArk Credential Provider to issue a GetPassword request against the credentials that are being returned. Such requests will be tagged as for a cache refresh.

      While the password will have been retrieved, it will not have been stored or parsed in any way.

      When the credential’s password is actually being accessed, the CloudBees CyberArk Credentials Provider will always issue a GetPassword request to retrieve the password.

    • When the Operations Center Client Plugin’s Credentials Provider is consulted, it will request the credentials exposed to CloudBees CI by operations center from Operations Center Server’s Credentials Gateway.

      The Credentials Gateway will relay the request to the operations center Credentials API, which will also route the request to operations center’s CloudBees CyberArk Credential Provider.

      All credentials passed from operations center to CloudBees CI will be snapshotted before being serialized over the remoting channel.

      Snapshotting a credential provided by the CloudBees CyberArk Credential Provider will cause the password to be retrieved at the point in time when the snapshotting occurs as a snapshotted credential should be self-contained and not require access to remote services.

It is recommended that the only CyberArk credentials defined in operations center are those credentials used to connect Shared Agents or agents within Shared Clouds.

Credentials for use in build jobs should be defined in the CloudBees CI CloudBees CyberArk Credential Provider stores.

Credentials retrieval process

Deployment planning

The CloudBees CyberArk Credential Provider has a number of important settings and choices that need to be made:

  • How will the CloudBees CyberArk Credential Provider connect and authenticate to the CyberArk CCP Web Service.

    • Transport: https (recommended) or http

    • Authentication: Client Certificates (recommended), None, or HTTP BASIC

    • Validation of Web Service identity: Explicitly supply certificate, None, or Use JVM Trust Store

  • Which credentials stores will be enabled for the CloudBees CyberArk Credential Provider

    • Global store allows access for all items within Jenkins

    • Per folder store allows access for all jobs within the folder or its sub-folders

  • How many CyberArk Application IDs will be used to access credentials?

    • The Global store will access using the default Application ID

    • Each folder store will access using the default Application ID but it is possible to enabling the ability to override the Application ID on a per-folder basis

  • What Safe:Folder pairs to map to which Jenkins folders?

Before deploying the CloudBees CyberArk Credential Provider it can be helpful to consider the following questions:

Will CyberArk credentials be used to connect dedicated agents to CloudBees CI?

If yes, you will need to enable the Global CyberArk Credentials store.

Are there any CyberArk credentials that should be available to all jobs in CloudBees CI?

If yes, you will need to enable the Global CyberArk Credentials store.

Are any of the CyberArk credentials categorized using CyberArk folders within the CyberArk Safes?

If yes, you will need to enable the ability to specify folders other than Root.

How many CyberArk Application IDs will Jenkins use?

If Jenkins will use a single CyberArk Application ID to access all credentials then you can simplify the configuration of CyberArk credentials by disabling the ability to override the Application ID.

How are credentials distributed among Safes in the CyberArk Vault and how will that map to the Jenkins folder structure?

In the ideal case, each Safe will be mapped to at most one Jenkins context object (i.e. the root of Jenkins or a folder within Jenkins). Additionally it may be the case that multiple Safes map to the same Jenkins context object. Deployment planning is significantly simpler if a Safe is only exposed to a single Jenkins context object.

Some example deployment plans include:

  • Application ID per product - Each product (or team) gets their own Jenkins folder, their own CyberArk Safe and their own Application ID. The CloudBees RBAC plugin is used to restrict access to the team’s Jenkins folder based on the product team membership.

    Has the advantage that if the product is retired all the credentials for that product can be removed by just removing a single CyberArk Safe.

    The use of an Application ID per product allows for the restriction of access to the product’s safe such that other products cannot access the credentials exposed within the product’s Jenkins folder.

  • CyberArk Safe per product - Each product (or team) gets their own Jenkins folder, their own CyberArk Safe. The CloudBees RBAC plugin is used to restrict access to the team’s Jenkins folder based on the product team membership.

    Has the advantage that if the product is retired all the credentials for that product can be removed by just removing a single CyberArk Safe.

    The use of a single Application ID for all of Jenkins reduces the number of Application IDs required to be configured and have access permissions within CyberArk maintained.

  • CyberArk Safe per service - CyberArk Safes are divided up by service. For example, there is a safe for Database passwords, a safe for deployment passwords, etc. Within each safe either the credentials are organized using the CyberArk Folders or the credentials access permissions are controlled at the object level.

    Allows all the credentials for a single service category to be maintained in one safe. May make it harder to know when CyberArk credentials are no longer required.

    Will require either specifying custom Application IDs or overriding the default CyberArk Folder of Root.

Additionally, you may want to consider which of the Jenkins credential stores to retain as enabled. For example, you may want to disable the Jenkins per-user credential store and apply type restrictions on the other Jenkins credential stores such that they cannot be used to store username and password credentials in order to enforce that all password credentials are stored in the CyberArk Vault.

Configuring global credentials

To configure a CyberArk Credentials provider:

  1. On the Dashboard, select Manage Jenkins on the left navigation pane. The Manage Jenkins page displays.

  2. Under Security, select Configure Credential Providers. The Configure Credential Providers page displays.

    Configure Credential Providers page
    Figure 1. Configure Credential Providers page
  3. Navigate to CyberArk Credential Provider and enter the following details:

    Label Definition

    AIM server URL

    Typically this will look something like https://ccp.cyberark.example.com/AIMWebService/V1.1/AIM.asmx (with the hostname modified to the hostname of your CyberArk CCP Web Service).

    AIM server authentication

    It is recommended to use Client certificate but the correct option depends on the authentication methods that have been configured on the Microsoft IIS server that is hosting the CyberArk CCP Web Service.

    AIM server verification

    It is recommended to specify an explicit certificate match.

  4. Select the Advanced button and complete the following advanced options:

    Label Definition

    Connection timeout

    The number of seconds to wait for a connection to the CyberArk Credential Provider Web Service before failing the operation.

    Request timeout

    The number of seconds to wait for a response from the CyberArk Credential Provider Web Service before failing the operation.

    Password request reason

    The reason text to supply to the CyberArk Credential Provider Web Service when requesting the password for a credential.

    The originating Job and Run will be appended to this reason text if the details can be determined. If the request cannot be associated with a Job and Run then the originating thread name will be appended to the reason text.

    Cache refresh TTL (time to live)

    The number of minutes that the caching of the non-secret properties of CyberArk credentials will be considered as current.

    When listing credentials in the Jenkins UI, the cache will be refreshed if the cache entry is older than this TTL.

    When listing credentials in the Jenkins UI, the cache will be used as a fall-back in the event that the CyberArk Credential Provider Web Service is unavailable in order to ensure that job configuration does not get broken.

    Cache refresh reason

    The reason text to supply to the CyberArk Credential Provider Web Service when requesting the object details of a credential for a cache refresh (which, due to the limitations of the CyberArk APIs will necessarily include requesting the password)

  5. Configure the credentials stores by entering the following:

    CyberArk Credential Provider store configuration options
    Figure 2. CyberArk Credential Provider store configuration options
    Label Definition

    Application Id

    The default CyberArk Application Id that will be used to access credentials from CyberArk.

    Global credentials » Enabled

    If selected, this option enables a credentials store available from the root of Jenkins.

    Global credentials » Safes

    The list of CyberArk Safe:Folder pairs to consult (in order) when resolving credentials exposed by the global credentials store.

    Folder credentials » Enabled

    If selected, this option enables per-folder credentials stores scoped to the folders they are enabled on.

    Folder credentials » Allow custom Application Ids

    If selected, the per-folder credentials stores can specify a custom CyberArk Application Id to use when resolving credentials for that folder’s store.

    Folder credentials » Allow custom folders

    If selected, the per-folder credentials stores can specify a CyberArk Folder other than Root for any defined Safe:Folder pairs bound to that Jenkins folder.

  6. Click Save.

Configuring per-folder credentials

If the Folder credentials settings were enabled on the Configure Credential Providers page (refer to CyberArk Credential Provider store configuration options), then users with the CyberArk Credentials/Configure permission can configure the per-folder CyberArk credentials store.

To configure the CyberArk credentials store for a specific folder:

  1. On the Dashboard, select the desired folder. The page for that folder displays.

  2. On the left navigation pane, select the Configure. The folder configuration page displays.

    Per-folder CyberArk Credential Provider store disabled
    Figure 3. Folder configuration page
  3. Enter details about the credential store:

    Label Definition

    Enabled

    Select this option to enable a folder scoped credentials store backed by CyberArk for this specific folder. Credentials in this store will be available to all jobs in this folder and sub-folders.

    Application Id - Use default

    Select this option to allow overriding the default CyberArk Application ID that will be used to access the configured safes. In some CyberArk architectures it may be the case that the credentials that a folder should access are only available when using an Application Id that has been created specifically for each folder.

    Id

    The CyberArk Application ID that will be used to access the configured safes.

    Safes

    The CyberArk safes to search for credentials. The safes are searched in order (you can change the order using drag and drop). The first match wins in the case of duplicate Object Ids.

    Custom folder

    Select this option to specify a custom safe sub-folder. By default only credentials in the Root folder will be exposed. In some CyberArk architectures credentials may be categorized within the CyberArk safes using folders and therefore the folder to search may need to be specified.

    Folder

    The name of the CyberArk folder within the CyberArk safe. For most CyberArk architectures this will be the default value of Root.

    The CyberArk Folder uses \ as a path separator.
  4. Select Save.

Managing CyberArk Credential Stores

This section will cover the following tasks:

  • Exposing CyberArk credentials to jobs

  • Removing CyberArk credentials that no longer exist

Exposing CyberArk credentials

Before you can expose credentials from CyberArk to jobs in Jenkins you need to know the CyberArk Object Id of the credential you want to expose and the context within Jenkins where the credential is to be made available.

In the CyberArk PrivateArk Microsoft Windows native client, this will be the object name (Password object dialog of PrivateArk Microsoft Windows native client).

PrivateArk Microsoft Windows Native client screenshot of the Password Object dialog for a password object with Object Id `deploy-key`
Figure 4. Password object dialog of PrivateArk Microsoft Windows native client

In the CyberArk Privileged Identity Management Web client this can either be inferred from the object path or the name. If the object path in the Safe is Root\deploy-key then the Object Id is deploy-key. Similarly the Account details screen will also show the Name:. Refer to Privileged Identity Management web client.

Privileged Identity Management Web client screenshot of the Account details dialog for a password object with Object Id `deploy-key`
Figure 5. Privileged Identity Management web client

There are two classes of context within Jenkins where the credential can be exposed:

  1. The Jenkins root object itself

  2. A folder within Jenkins

Credential scope

When exposing credentials from the Jenkins root object, you also need to decide what scope to give the exposed credentials.

  • Using the SYSTEM scope allows the credentials to be used for launching Jenkins agents as well as for some secondary system wide processes configured through the Manage Jenkins > Configure Jenkins screen. The credential will not be available to jobs within Jenkins.

  • Using the GLOBAL scope (in addition to the usage permitted by SYSTEM scope) makes the credential available to all jobs within Jenkins running as an authentication that has the Credentials/UseItem permission.

Using the Web User Interface to expose CyberArk credentials

Navigate to the Credentials page for the context within which the CyberArk credentials will be exposed.

The Credentials view for the Jenkins root context
Figure 6. Credentials view from the Jenkins root context
The Credentials view for a folder context within Jenkins
Figure 7. Credentials view for a folder context within Jenkins

Adding a credential

To add a credential into the CyberArk store associated with the context:

  1. Hover your mouse over the (global) domain for the CyberArk store.

    The shortcut for adding credentials to the `(global)` domain of the Jenkins context’s CyberArk credentials store
    Figure 8. Shortcut menu to add credentials to the '(global)' domain
    The CloudBees CyberArk Credential Provider only supports the (global) domain.
  2. Select Add Credentials from the drop-down list. New credentials page displays.

    Adding CyberArk Username Password credentials to a CyberArk credentials store
    Figure 9. New credentials page
  3. Enter details about the credential.

    Label Definition

    Kind

    Displays the type of credential. This field automatically displays the CyberArk ussername and password which is currently the only type of credential supported.

    Scope

    Determines where this credential can be used. Select one of the following.

    • System: This credential is only available to the object on which the credential is associated. This system-scoped credential could be used for email auth or agent connection (where the Jenkins instance itself is using the credential). This option significantly restricts where the credential can be used, 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. Global-scoped credentials can be used for items that are needed for jobs.

    ID

    A unique ID by which credentials are identified from jobs and other configurations.

    If using version 1.0.19.x or later of the CyberArk Credential Provider, you can enter the CyberArk Object Id in either the ID field or the CyberArk Object ID field.

    If there is an issue with the ID entered in this field, you may receive one of the following error messages:

    • CyberArk was recently unavailable, won’t recheck for another 5.5 sec

    • The Object Id does not exist

    • The Folder within the Safe does not exist

    • The Safe within the Vault does not exist

    • The Application Id used by Jenkins does not have permission to access the Object

    • The Application Id used by Jenkins does not have permission to access the Safe

    • The Application Id used by the CyberArk Central Credential Provider Web Service does not have permission to access the Object

    • The Application Id used by the CyberArk Central Credential Provider Web Service does not have permission to access the Safe

    • The Application Id used by the CyberArk Central Credential Provider does not have permission to access the Object

    • The Application Id used by the CyberArk Central Credential Provider does not have permission to access the Safe

    Description

    (Optional) A description of the credential.

    CyberArk ID

    The CyberArk Object ID in one of a specific CyberArk Safes that this credentials store is configured to search in.

  4. Select Create.

    Once the credential is added, it becomes visible on the Credentials page for the context object.

    The Object defined in the CyberArk credentials store
    Figure 10. Object defined in the CyberArk credentials store

Adding a credential within a job

You can also a credential from the configuration page of a specific job. Under the Credentials, select Add to view the list of credential stores in scope for the job. The list of enabled stores is restricted to those stores to which the current user has permission to add credentials.

Add credential
Figure 11. Add credential from job configuration page

When you select a CyberArk credentials provider from the list, the Add Credentials dialog appears.

Folder Credentials Provider: Add Credentials dialog
Figure 12. Folder Credentials Provider: Add Credentials dialog

Using the Jenkins Command Line Interface

The create-credentials-by-xml Jenkins CLI command is the command used to expose CyberArk credentials.

The Jenkins CLI command for adding credentials to a credentials store
Figure 13. Jenkins CLI create-credentials-by-xml

Before using this CLI command, you need to determine the Store Id and Domain.

The domain will always be "_" because the CyberArk credentials store only supports the global domain.

The Store Id consists of three components separated by the ::. The components are provider :: resolver :: context path. In the case of the CloudBees CyberArk Credential Provider there are only two choices, but it is probably helpful to illustrate the general process:

  1. List the credentials providers:

    Listing the credentials providers
    $ java -jar jenkins-cli.jar -s http://local.example.com/ \ list-credentials-providers Name Provider ============================================================================== ============================== CyberArkCredentialsProvider Cyber Ark Credentials Provider FolderCredentialsProvider Folder Credentials Provider SystemCredentialsProvider Jenkins Credentials Provider UserCredentialsProvider User Credentials Provider com.cloudbees.hudson.plugins.folder.properties.FolderCredentialsProvider Folder Credentials Provider com.cloudbees.jenkins.plugins.cyberark.credentials.CyberArkCredentialsProvider Cyber Ark Credentials Provider com.cloudbees.plugins.credentials.SystemCredentialsProvider$ProviderImpl Jenkins Credentials Provider com.cloudbees.plugins.credentials.UserCredentialsProvider User Credentials Provider cyberark Cyber Ark Credentials Provider folder Folder Credentials Provider system Jenkins Credentials Provider user User Credentials Provider

    The CloudBees CyberArk Credential Provider is exposed using three different names (the names are derived by code and simplifications are only exposed if there are no conflicting credentials provider implementations). The most specific provider identifier is com.cloudbees.jenkins.plugins.cyberark.credentials.CyberArkCredentialsProvider but in the above instance we also have available the short form cyberark.

  2. List the context resolvers

    Listing the context resolvers
    $ java -jar jenkins-cli.jar -s http://local.example.com/ \ list-credentials-context-resolvers Name Resolves =============================================================================== ======= ItemContextResolver Items SystemContextResolver Jenkins UserContextResolver Users com.cloudbees.plugins.credentials.CredentialsSelectHelper$ItemContextResolver Items com.cloudbees.plugins.credentials.CredentialsSelectHelper$SystemContextResolver Jenkins com.cloudbees.plugins.credentials.CredentialsSelectHelper$UserContextResolver Users item Items system Jenkins user Users

    The CloudBees CyberArk Credential Provider only provides implementations of the credentials store for the root context and for folders (which are items). The context resolvers that you want are either com.cloudbees.plugins.credentials.CredentialsSelectHelper$SystemContextResolver (which has the short alias of system) or com.cloudbees.plugins.credentials.CredentialsSelectHelper$ItemContextResolver (which has the short alias of item)

  3. Specify the context path

    • For the system context resolver, this is always the fixed value jenkins.

    • For the item context resolver, this is the full name of the item (folder). The full name is normally the names separated by '/' characters. The full name is not the URL of the job as that includes /job/ in the URL. For example a folder with the URL http://local.example.com/jenkins/job/example-folder/job/example-sub-folder/ would have the full name /example-folder/example-sub-folder

      The config.xml of that folder would - by default - be stored in $JENKINS_HOME/jobs/example-folder/jobs/example-sub-folder.

      The breadcrumb bar, if the display name has been customized for these folders might look like Jenkins » Example Folder » Example Sub-Folder)

      So the two possible Store Id variants are:

      • cyberark::system::jenkins for the root credentials store

      • cyberark::item::/full/name/of/folder

  4. Create the XML representation of the credential we want to expose. The following is the template to use for the XML representation.

    XML template of CyberArk Username Password credentials
    <com.cloudbees.jenkins.plugins.cyberark.credentials.CyberArkUsernamePasswordCredential> <id><!-- Insert Object Id here--></id> <description><!-- Insert Description here if you want --></description> </com.cloudbees.jenkins.plugins.cyberark.credentials.CyberArkUsernamePasswordCredential>
    Example of exposing the deploy-key credential in the /example-folder folder.
    $ cat > credential.xml <<EOF <com.cloudbees.jenkins.plugins.cyberark.credentials.CyberArkUsernamePasswordCredential> <id>deploy-key</id> </com.cloudbees.jenkins.plugins.cyberark.credentials.CyberArkUsernamePasswordCredential> EOF $ java -jar jenkins-cli.jar -s http://local.example.com/ \ create-credentials-by-xml cyberark::item::/example-folder _ < credential.xml $ java -jar jenkins-cli.jar -s http://local.example.com/ \ list-credentials cyberark::item::/example-folder ======================== Domain (global) Description # of Credentials 1 ======================== Id Name ================ ======= deploy-key /****** ========================

Using the Jenkins REST Interface

To use the REST interface, you need to make a POST request to the createCredentials sub-URL of the credentials domain. For example, for the folder example-folder in a Jenkins instance hosted at http://local.example.com/ this would be the URL http://local.example.com/job/example-folder/credentials/store/cyber-ark/domain/_/createCredentials.

Example of exposing the deploy-key credential in the /example-folder folder.
$ cat > credential.xml <<EOF <com.cloudbees.jenkins.plugins.cyberark.credentials.CyberArkUsernamePasswordCredential> <id>deploy-key</id> </com.cloudbees.jenkins.plugins.cyberark.credentials.CyberArkUsernamePasswordCredential> EOF $ curl -X POST -H content-type:application/xml -d @credential.xml \ http://local.example.com/job/example-folder/credentials/store/cyber-ark/\ domain/_/createCredentials
If your Jenkins instance has CSRF protection enabled or uses authentication then you will need to provide the required headers to the REST request. Details of the exact headers required depends on the CSRF protection that has been configured and the exact authentication mechanism being used.

Removing CyberArk credentials that no longer exist

If the backing credentials are removed from CyberArk, you will need to remove the corresponding credential definition from the credentials store in Jenkins.

Using the Web User Interface

Navigate to the Credentials view for the context containing the the CyberArk credentials to be removed.

There are two ways to remove the credential:

  • Use the context menu for the credential and select Delete

    Using the context menu for removing a credentials from a credentials store
    Figure 14. Using the context menu for removing a credentials from a credentials store
  • Navigate to the credential and select the Delete left hand menu action.

    Using the credential’s *Delete* action directly
    Figure 15. Using the credential’s Delete action directly

Using the Jenkins Command Line Interface

The delete-credentials Jenkins CLI command is the command used to remove CyberArk credentials.

The Jenkins CLI command for removing credentials from a credentials store
Figure 16. Jenkins CLI command delete-credentials
Example of removing the deploy-key credential from the /example-folder folder.
$ java -jar jenkins-cli.jar -s http://local.example.com/ \ delete-credentials cyberark::item::/example-folder _ deploy-key $ java -jar jenkins-cli.jar -s http://local.example.com/ \ list-credentials cyberark::item::/example-folder ======================== Domain (global) Description # of Credentials 0 ======================== Id Name ================ ======= ========================

Using the Jenkins REST Interface

To use the REST interface, you need to make a DELETE request to the config.xml sub-URL of the credentials. For example, for the deploy-key credential in the folder example-folder in a Jenkins instance hosted at http://local.example.com/ this would be the URL http://local.example.com/job/example-folder/credentials/store/cyber-ark/domain/_/credential/deploy-key/config.xml.

Example of removing the deploy-key credential from the /example-folder folder.
$ curl -X DELETE http://local.example.com/job/example-folder/credentials/\ store/cyber-ark/domain/_/credential/deploy-key/config.xml
If your Jenkins instance has CSRF protection enabled or uses authentication then you will need to provide the required headers to the REST request. Details of the exact headers required depends on the CSRF protection that has been configured and the exact authentication mechanism being used.