ServiceNow CyberArk External Credential Provider for GCP Discovery - invalid key format

[vlahod]

Hello,

I am using the CyberArk vault as my external credential storage within ServiceNow. I am able to successfully retrieve domain and local accounts to run on infrastructure; however, I cannot leverage a GCP service account to perform GCP discovery. The service account functions when I import the JSON into credentials and bypass CyberArk; however, when I leverage CyberArk I receive an invalid key format error. I have followed the steps to create a custom JAR for GCP:
https://www.servicenow.com/community/itom-blog/servicenow-gcp-credential-resolver-using-cyberark/ba-...
I can confirm the JAR file produces a usable JSON payload and have validated that it works using the gcloud CLI. I've created a Hashmap with the email and secret_key values provided. When I test the service account for GCP discovery it always produces an invalid key format. The secret is properly retrieved from CyberArk. The custom JAR and CyberArk seem to be functioning as expected. Is there any additional logging I can enable to see what ServiceNow is sending to GCP to test the credentials? 

[AJ-TechTrek]

Hi @vlahod ,

As per my understanding , below will help you,

Why the issue happens:
* GCP service accounts need the credential exactly in the original JSON format.
* When you store the JSON key in CyberArk (or build a HashMap in your custom resolver), you must ensure:
* The structure is 100% identical (correct escaping, proper braces, no added characters).
* The field names and formatting exactly match what GCP expects.
* Even subtle formatting differences (extra quotes, line breaks, or whitespace) can cause:
invalid key format
* ServiceNow’s Discovery engine expects to receive the credential payload as a single JSON string, not as separate fields.

What you can do:

1) Verify custom JAR output matches original JSON
* Confirm that the output of your JAR (HashMap) when retrieved in ServiceNow is byte-for-byte identical to the JSON file that works when imported manually.
* Even if it looks the same visually, try:
diff original_key.json cyberark_resolved_key.json
 * Make sure there are no escaped quotes (\") or hidden newlines.

2) Enable detailed debugging/logs in ServiceNow
While ServiceNow doesn’t have out-of-the-box deep logs for credential payloads (for security reasons), you can:
* Enable MID Server debug logging:
* Go to MID Server → Servers → Select your MID → Log → Debug mode.
* Add log categories like:
com.snc.discovery
* com.snc.discovery.GCPDiscovery
* com.snc.discovery.cred
* Check the MID Server logs (ecc_queue and agent logs) for how the credential is being passed.

3) Confirm the custom credential resolver is actually being invoked
* Go to:
Connection & Credential Aliases → Credential Resolver → Test Resolver
* Test directly and confirm that the resolver outputs the correct JSON string.
* Make sure the credential alias in the Discovery schedule points to the custom resolver.

4) Correct structure for GCP credentials in ServiceNow
* The GCP credential type in ServiceNow expects a single secret field: the entire JSON string.
* In your HashMap, the key must be exactly secret_key, and its value should be:
{
"type": "service_account",
"project_id": "...",

"private_key_id": "...",
"private_key": "...",
 "client_email": "...",
 "client_id": "...",
 }

* Avoid adding an email field separately — keep the JSON as a single field.

5) Test outside ServiceNow
* Use the output of your CyberArk resolver (the JSON) with the gcloud CLI to verify that the JSON itself is valid.

As per my Understanding Summary:
* Double-check that the final JSON produced by the custom resolver is exactly what GCP expects.
* Enable debug logging on the MID Server for com.snc.discovery & related classes.
* Use Test Resolver in ServiceNow to preview what’s coming from CyberArk.
* Make sure the credential alias uses your custom resolver correctly.
* Confirm the credential type in ServiceNow is Google Cloud Platform, and secret_key holds the full JSON.

Please appreciate the efforts of community contributors by marking appropriate response as Mark my Answer Helpful or Accept Solution this may help other community users to follow correct solution in future.

Thank You
AJ - TechTrek with AJ - ITOM Trainer
LinkedIn:- https://www.linkedin.com/in/ajay-kumar-66a91385/
YouTube:- https://www.youtube.com/@learnitomwithaj
Topmate:- https://topmate.io/aj_techtrekwithaj (Connect for 1-1 Session)
ServiceNow Community MVP 2025

[vinnietay]

Hi AJ,

On a separate topic but a similar vein: have you seen authentication to Azure or AWS using a federated identity flow rather than static credentials (e..g, client secret)? For example, the OAuth flow would first call the IDP to retrieve temp credentials rather than requiring static creds be stored on the Platform.

This context would be tremendous in helping get past a possible non-starter.

Thanks,
Vinny

[AJ-TechTrek]

Hi @vinnietay ,

I never tried and worked on this type of use case but as per my understanding in ServiceNow, there are supported ways to do this

a) Azure (Microsoft Identity platform)
* Use OAuth 2.0 Client Credentials or On-behalf-of flow.
* Configure an OAuth Entity in ServiceNow:
* System OAuth → Application Registry → New → Azure AD provider.
 ServiceNow can:
* Use the federated IDP as the authorization server.
* Fetch access tokens dynamically.

For ServiceNow IntegrationHub connectors, you configure:
* Connection & Credential Alias → OAuth 2.0 Profile → references the OAuth Entity.
* This means tokens are retrieved dynamically via federated flow.

b) AWS (IAM Identity Center / STS)
* ServiceNow Cloud Provisioning and Governance (CPG) module supports:
* Federated access to AWS: ServiceNow assumes a role in AWS by calling AWS STS (Security Token Service).
 Uses:
* IAM role with trust policy for ServiceNow
* Short-lived credentials issued dynamically → no static keys stored.

How this works:
* ServiceNow stores minimal identity (like external ID or role ARN).
* At runtime: calls AWS STS → gets temporary credentials → uses them to make API calls.

1.Register ServiceNow as app in Azure AD or AWS IAM Identity Center.

2.Create OAuth Entity in ServiceNow referencing that IDP.

3.Create Connection & Credential alias → OAuth 2.0 profile.

4.Use IntegrationHub, CPG, or custom REST → refer to that alias.

5.At runtime, ServiceNow dynamically retrieves token → uses it.

Please appreciate the efforts of community contributors by marking appropriate response as Mark my Answer Helpful or Accept Solution this may help other community users to follow correct solution in future.
 

Thank You
AJ - TechTrek with AJ - ITOM Trainer
LinkedIn:- https://www.linkedin.com/in/ajay-kumar-66a91385/
YouTube:- https://www.youtube.com/@learnitomwithaj
Topmate:- https://topmate.io/aj_techtrekwithaj (Connect for 1-1 Session)
ServiceNow Community MVP 2025