CyberArk Credential Provider Plugin

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.0 release has the following software requirements:

  • Jenkins LTS 2.7.4 (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.

cyberark architecture
Figure 1. 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 Jenkins Enterprise.

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 Jenkins Enterprise 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 Jenkins Enterprise and Operations Center is using the standard Jenkins remoting protocol used between CloudBees Core 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 master, 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 master, 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 to 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 Core 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 Core 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 Jenkins Enterprise CloudBees CyberArk Credential Provider stores.

cyberark sequence
Figure 2. 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 Jenkins Enterprise?

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 Jenkins Enterprise?

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

empty global configuration
Figure 3. Unconfigured CyberArk Credential Provider

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.

populated global configuration
Figure 4. Configured CyberArk Credential Provider

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 global configuration
Figure 5. Advanced CyberArk Credential Provider configuration options

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.

store global configuration
Figure 6. CyberArk Credential Provider store configuration options

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.

empty folder configuration
Figure 7. Per-folder CyberArk Credential Provider store disabled

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.

populated folder basic configuration
Figure 8. 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 detailed configuration
Figure 9. 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 enabled)

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 client
Figure 10. 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

pim client
Figure 11. 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:

  1. The Jenkins root object itself

  2. 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

global config no authorize project
Figure 12. The Configure Global Security screen without any Queue item authenticator plugins installed

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

global config authorize project
Figure 13. The Configure Global Security screen with at least one Queue item authenticator plugins installed

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.

global config authorize project config
Figure 14. The Configure Global Security screen adding the Authorize Project plugin's Queue item authenticator

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

job config authorize project
Figure 15. Configuring a job to use the Authorize Project plugin

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.

add flow credentials view
Figure 16. The Credentials view for the Jenkins root context
add flow credentials view folder
Figure 17. The Credentials view for a folder context within Jenkins

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

add flow shortcut
Figure 18. The shortcut for adding credentials to the (global) domain of the Jenkins context’s CyberArk credentials store
add flow shortcut folder
Figure 19. The shortcut for adding credentials to the (global) domain of a folder context’s CyberArk credentials store

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

add flow cyberark store
Figure 20. A CyberArk credentials store (in this case scoped to the Jenkins root context)

Next select the (global) credential domain.

The CloudBees CyberArk Credential Provider only supports the (global) domain.
add flow cyberark domain selection
Figure 21. The (global) credentials domain in a CyberArk credentials store.

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.

add flow create credentials
Figure 22. Adding CyberArk Username Password credentials to a CyberArk credentials store.

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

add flow does not exist
Figure 23. Form validation showing the credential as not visible to Jenkins

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.

add flow populated credentials
Figure 24. The Object Id populated and the form validation confirming the username of the resolved Object.

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

add flow credentials view final
Figure 25. The Object defined in the CyberArk credentials store.

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

add flow in place
Figure 26. 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.

Using the Jenkins Command Line Interface

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

add flow cli command
Figure 27. The Jenkins CLI command for adding credentials to a credentials store.

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:

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

  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

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

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

    del flow long way
    Figure 29. 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.

del flow cli command
Figure 30. The Jenkins CLI command for removing credentials drom a credentials store.
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.
Copyright © 2010-2020 CloudBees, Inc.Online version published by CloudBees, Inc. under the Creative Commons Attribution-ShareAlike 4.0 license.CloudBees and CloudBees DevOptics are registered trademarks and CloudBees Core, CloudBees Flow, CloudBees Flow Deploy, CloudBees Flow DevOps Insight, CloudBees Flow DevOps Foresight, CloudBees Flow Release, CloudBees Accelerator, CloudBees Accelerator ElectricInsight, CloudBees Accelerator Electric Make, CloudBees CodeShip, CloudBees Jenkins Enterprise, CloudBees Jenkins Platform, CloudBees Jenkins Operations Center, and DEV@cloud are trademarks of CloudBees, Inc. Most CloudBees products are commonly referred to by their short names — Accelerator, Automation Platform, Flow, Deploy, Foresight, Release, Insight, and eMake — throughout various types of CloudBees product-specific documentation. Oracle and Java are registered trademarks of Oracle and/or its affiliates. Jenkins is a registered trademark of the non-profit Software in the Public Interest organization. Used with permission. See here for more info about the Jenkins project. The registered trademark Jenkins® is used pursuant to a sublicense from the Jenkins project and Software in the Public Interest, Inc. Read more at www.cloudbees.com/jenkins/about. Apache, Apache Ant, Apache Maven, Ant and Maven are trademarks of The Apache Software Foundation. Used with permission. No endorsement by The Apache Software Foundation is implied by the use of these marks.Other names may be trademarks of their respective owners. Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this content, and CloudBees was aware of a trademark claim, the designations have been printed in caps or initial caps. While every precaution has been taken in the preparation of this content, the publisher and authors assume no responsibility for errors or omissions, or for damages resulting from the use of the information contained herein.