CyberArk CCP

The CyberArk Central Credential Provider (CCP) Store integrates with CyberArk’s enterprise-grade credential management platform. It retrieves credentials such as passwords, usernames, and database connection details directly from the CyberArk Vault through the CCP interface. This enables secure, centralized secret management and automated credential rotation without embedding secrets in configuration files. This page details the CyberArk CCP Store Parameters and a guide on how to configure CCP Certificates.

CyberArk CCP Store-Specific Parameters

Prerequisites

A configured CyberArk CCP instance is required, along with an Application ID (AppID) authorized to access the required secrets. Depending on your organization’s authentication model, the CCP can use TLS-Cert or TLF-PFX.
Ensure that the appropriate authentication certificates or credentials are available to the deployment environment.

Example

The following example is based on the general store and store-specific parameters.

secretsMgmt:
  enabled: true
  plainIDConfig:
    config.yaml:
      secretStore:
        - id: CYBERARK_CCP_STORE
          type: CyberArkCCP
          isDefault: false
          auth:
            method: TLS-Cert
            certFileName: /path/to/cert.pem
            keyFileName: /path/to/key.pem
            caFileName: /path/to/ca.pem
          details:
            url: https://cyberark-ccp.example.com
            defaultPath: /AIMWebService/api/Accounts
            pathPrefix: Accounts
            appId: MyAppID
            timeout: 30s
            maxConcurrentRequests: 10
            maxRetries: 3
            retryDelay: 1s

A typical use case is retrieving credentials from CyberArk—such as database passwords or API tokens—without storing them in configuration files. The CCP handles secret retrieval and renewal, providing seamless rotation and compliance with enterprise security Policies.

Returned Secret Format

CyberArk’s Central Credential Provider (CCP) always returns secrets in JSON format.
To support this flow, when using a secret key in the client, you must specify a JSON path expression in addition to the mandatory client_id and client_secret. The JSONPath guides the client where to extract the actual secret value from the JSON response.

CyberArk CCP responses include credentials in the following JSON structure:

{
  "Content": "<PASSWORD>",
  "UserName": "<USERNAME>",
  "LogonDomain": "<LOGON_DOMAIN>",
  "Address": "<ADDRESS>",
  "Database": "<DATABASE>"
}

Secrets are retrieved using JSON path expressions. For example:

• To extract a password:

  "{{store=CYBERARK_CCP_STORE,key=my-secret,jsonpath=$.Content}}"
  

• To extract a username:

  "{{store=CYBERARK_CCP_STORE,key=my-secret,jsonpath=$.UserName}}"
  

Certificate Configuration for CyberArk CCP Store

This section describes how to securely configure certificates for authenticating with the CyberArk CCP Store. Certificates can be provided either by mounting Kubernetes secrets or embedding certificate content directly into configuration files. The method you choose depends on your organization’s security and deployment model.
For a full reference on CyberArk CCP configuration and certificate-based authentication, see the CyberArk documentation.

Method 1: Mounted Certificates from Secrets

To create and mount certificates:

1. Create a Kubernetes secret containing your certificates:

   kubectl create secret generic cyberark-cert-secret \
     --from-file=ca.pem=/path/to/ca.pem \
     --from-file=certificate.crt=/path/to/certificate.crt \
     --from-file=private.key=/path/to/private.key
   

2. Reference the secret in your deployment’s Helm values file:

   extraVolumes:
     - name: cyberark-cert-secret
       secret:
         defaultMode: 420
         secretName: cyberark-cert-secret
   
   extraVolumeMounts:
     - name: cyberark-cert-secret
       readOnly: true
       mountPath: /app/ca.pem
       subPath: ca.pem
     - name: cyberark-cert-secret
       readOnly: true
       mountPath: /app/certificate.crt
       subPath: certificate.crt
     - name: cyberark-cert-secret
       readOnly: true
       mountPath: /app/private.key
       subPath: private.key
   
   
    ### There are two methods for configuring reference to the file names:
    ### A: Using the manual Store configuration, referencing the mount paths:
   plainIDConfig:
     config.yaml:
       secretStore:
         - id: CYBERARK_CCP_STORE
           type: CyberArkCCP
           isDefault: false
           auth:
             method: TLS-Cert
             caFileName: /app/ca.pem
             certFileName: /app/certificate.crt
             keyFileName: /app/private.key
           details:
             url: ${CYBERARK_CCP_URL}
             appId: ${CYBERARK_CCP_APP_ID}
             
    ### B: Using the extraEnv and declaring environment variable referencing the mount paths:
   extraEnv:
      ENV_VAR_CCP_CERT_FILE_NAME: "/app/config/cert.crt"
      ENV_VAR_CCP_KEY_FILE_NAME: "/app/config/private.key"
      ENV_VAR_CCP_CA_FILE_NAME: "/app/config/ca.pem"
   

Method 2: Embedded Certificate Content

You can embed certificate content directly into your configuration:

plainIDConfig:
  config.yaml:
    secretStore:
      - id: CYBERARK_CCP_STORE
        type: CyberArkCCP
        isDefault: false
        auth:
          method: TLS-Cert
          caFileName: /app/ca.pem
          certFileName: /app/certificate.crt
          keyFileName: /app/private.key
        details:
          url: ${CYBERARK_CCP_URL}
          appId: ${CYBERARK_CCP_APP_ID}
  ca.pem: |
    -----BEGIN CERTIFICATE-----
    ... your CA certificate content ...
    -----END CERTIFICATE-----
  certificate.crt: |
    -----BEGIN CERTIFICATE-----
    ... your certificate content ...
    -----END CERTIFICATE-----
  private.key: |
    -----BEGIN PRIVATE KEY-----
    ... your private key content ...
    -----END PRIVATE KEY-----

Standalone Deployment

In a standalone deployment, certificate related files will be deployed on the machine, as an example under the Secret Manager service app folder and referenced from there.

In this pattern there is no need for environment variables or secrets and instead the store configuration will simply point to the files locations and the certificates will be be read from the file while authenticating to CCP.

Example (Standalone Format):

/app/config/cert.crt
/app/config/private.key
/app/config/ca.pem

Whenever these values are referenced (whether in manual configuration, platform-managed environment variables, or other input fields), you refer to them exactly by path, e.g.:

certFileName: /app/config/cert.crt
keyFileName: /app/config/private.key
caFileName: /app/config/ca.pem

This approach eliminates the need for Kubernetes secrets but should only be used in controlled environments where configuration files are securely managed.