CyberArk Credential Provider Plugin

The CloudBees CyberArk Credentials Provider Plugin is only available for CloudBees CI on modern cloud platforms and CloudBees CI on traditional platforms.

The CyberArk Credential Provider enables additional credential stores for Jenkins 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 Jenkins 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.

Global Credentials Configuration

Navigate to the Manage Jenkins > Configure Credentials screen.

Unconfigured CyberArk Credential Provider

empty global configuration

To enable the CyberArk provider you need to configure:

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.

Configured CyberArk Credential Provider

populated global configuration

There are some additional advanced options available:

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)

Advanced CyberArk Credential Provider configuration options

advanced global configuration

Finally you need to configure the credentials stores:

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.

CyberArk Credential Provider store configuration options

store global configuration

Per-folder Credentials Configuration

If the Manage Jenkins > Configure Credentials > CyberArk Credential Provider > Folder credentials > Enabled has been selected then users with the CyberArk Credentials/Configure permission will be able to configure the per-folder CyberArk credentials store.

Per-folder CyberArk Credential Provider store disabled

empty folder configuration

To enable the CyberArk credentials store for a specific folder, navigate to that folder and then select the Configure screen.

The Manage Jenkins > Configure Credentials > CyberArk Credential Provider > Folder credentials > Allow custom Application Ids and the Manage Jenkins > Configure Credentials > CyberArk Credential Provider > Folder credentials > Allow custom folders settings control the available configuration options.

Per-folder CyberArk Credential Provider store enabled (Manage Jenkins > Configure Credentials > CyberArk Credential Provider > Folder credentials > Allow custom Application Ids and Manage Jenkins > Configure Credentials > CyberArk Credential Provider > Folder credentials > Allow custom folders disabled)

populated folder basic configuration

populated folder detailed configuration

If Manage Jenkins > Configure Credentials > CyberArk Credential Provider > Folder credentials > Allow custom Application Ids is enabled then each Jenkins folder will have the option to override the default Application Id.

In all cases you can provide the CyberArk Safe:Folder pairs to consult (in order) when resolving credentials exposed by the global credentials store.

If Manage Jenkins > Configure Credentials > CyberArk Credential Provider > Folder credentials > Allow custom folders is enabled then there is the option to override the default CyberArk Folder from Root to some other folder within the CyberArk Safe.

The CyberArk Folder uses \ as a path separator.

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 (PrivateArk Microsoft Windows Native client screenshot of the Password Object dialog for a password object with Object Id deploy-key).

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

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:. See Privileged Identity Management Web client screenshot of the Account details dialog for a password object with Object Id deploy-key

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

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

The Jenkins root object itself
A folder within Jenkins

Credential scope

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

Using the SYSTEM scope will allow 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 will, in addition to the usage permitted by SYSTEM scope, will make the credential available to all jobs within Jenkins running as an authentication that has the Credentials/UseItem permission.

Understanding the Authorize Project Plugin and Credentials

Jenkins associates an authentication with all internal operations.

When a user makes a request from the web browser or from the Jenkins CLI, that request is tagged with the user’s authentication and permission checks will restrict the scope of that request to the user’s permissions.

The internal operations of Jenkins typically run with the authentication of SYSTEM which is the most powerful authentication and has all permissions.

For simple build jobs, this is typically not an issue. More complex build jobs can involve bi-directional control between Jenkins and the build job. If the build job has the ability to control Jenkins itself, then the authentication that the build job is running as within Jenkins becomes important.

The Authorize Project plugin was developed to allow jobs to run with a lesser authentication.

In a Jenkins instance without the Authorize Project plugin (or an alternative plugin providing a Queue item authenticator) the Manage Jenkins > Configure Global Security screen will not show any Access control for builds options

The Configure Global Security screen without any Queue item authenticator plugins installed

global config no authorize project

Once at least one Queue item authenticator is installed in the Jenkins instance, then the configuration options will be displayed.

The Configure Global Security screen with at least one Queue item authenticator plugins installed

global config authorize project

The Access Control for Builds section is an ordered list of Queue item authenticator. The first one that declares an interest in providing authentication for the build job will determine the authentication that the build job will run as.

The Configure Global Security screen adding the Authorize Project plugin's Queue item authenticator

global config authorize project config

To actually use the Authorize Project plugin you also need to enable it for the specific build job.

Configuring a job to use the Authorize Project plugin

job config authorize project

Once you switch jobs from running as SYSTEM you will encounter a feature of the Credentials API, namely that credentials are only exposed to specific authentications.

There is a permission within the Credentials plugin known as Credentials/UseItem. In order for an authentication to be able to resolve a credentials in either the root scoped store or a folder scoped store, that authentication must have the Credentials/UseItem permission.

By default the Credentials/UseItem permission is hidden and users receive this permission through implication by the Job/Configure permission. A Jenkins administrator can make the permission visible by defining the com.cloudbees.plugins.credentials.UseItemPermission system property with the value of true, e.g. by adding -Dcom.cloudbees.plugins.credentials.UseItemPermission=true to the Jenkins JVM start-up options.

The combination of the two of these features with the CloudBees RBAC plugin and nesting of folders should enable the ability to restrict jobs to only access those credentials that they should have access to.

Using the Web User Interface

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

The Credentials view for the Jenkins root context

add flow credentials view

The Credentials view for a folder context within Jenkins

add flow credentials view folder

Next you need to add a credential into the CyberArk store associated with the context. There are two ways to add the credential.

The quickest way is to use the context menu available by hovering the mouse over the (global) domain for the CyberArk store. See The shortcut for adding credentials to the (global) domain of the Jenkins context’s CyberArk credentials store and The shortcut for adding credentials to the (global) domain of a folder context’s CyberArk credentials store.

The shortcut for adding credentials to the (global) domain of the Jenkins context’s CyberArk credentials store

add flow shortcut

The shortcut for adding credentials to the (global) domain of a folder context’s CyberArk credentials store

add flow shortcut folder

The other way is to navigate the left-hand menu sub-items of the Credentials view. First select the CyberArk sub-item.

A CyberArk credentials store (in this case scoped to the Jenkins root context)

add flow cyberark store

Next select the (global) credential domain.

The CloudBees CyberArk Credential Provider only supports the (global) domain.

The (global) credentials domain in a CyberArk credentials store.

add flow cyberark domain selection

Finally select the Add Credentials action.

Irrespective of which path to the Add Credentials screen you choose, you now need to enter the CyberArk Object Id as the credentials ID.

Adding CyberArk Username Password credentials to a CyberArk credentials store.

add flow create credentials

The CyberArk API used to get the details of the credential is deliberately obtuse in reporting errors.

Form validation showing the credential as not visible to Jenkins

add flow does not exist

The same / similar error messages are returned in all of the following cases:

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

You may optionally provide a description which can be helpful to disambiguate similar credentials in the Credentials drop down selector fields when configuring jobs.

The Object Id populated and the form validation confirming the username of the resolved Object.

add flow populated credentials

Once the credential has been added, it should be visible on the Credentials view for the context object that the credential was added to.

The Object defined in the CyberArk credentials store.

add flow credentials view final

The in-place Add functionality is also available for adding credentials.

The Add menu for a Credentials drop-down field showing the credential stores in scope for the job. The enabled stores will be restricted to those stores that the current user has permission to add credentials to.

add flow in place

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.

add flow cli command

Before we can use this CLI command we 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:

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.

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 we 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)

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

Next we need to 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.
Navigate to the credential and select the Delete left hand menu action.

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 drom a credentials store.

del flow cli command

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