
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎03-14-2018 07:43 AM
Hello All,
I am working on implementing the external credential store JAR file. I have it working for windows and linux username and password and private key authorization. I am also trying to implement AWS credentials using the JAR file however I am not sure how this will work. When I retrieve a username there is a variable defined in the java code on the doc site called VAL_USER and that is where I store the username. Pretty simple and straightforward, same with the password or private key, they go in one of the variables provided in the code on the docs site:
AWS credentials however do not use a username and password, they require an access key id and secret access key. What variables can I store the access key id and secret access key in for ServiceNow to be able to use an AWS credential via the external credential store? This also leads to the bigger question of weather or not AWS credentials can be used by an external credential store other than CyberArk.
Thanks,
Colin Christie
Solved! Go to Solution.
- Labels:
-
Discovery
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎03-15-2018 06:32 AM
Hello,
I would check out https://docs.servicenow.com/bundle/jakarta-servicenow-platform/page/product/discovery/concept/external_cred_storage_configuration.html
If you look at the example file you can see that it appears only the following are supported:
#TYPE is one of #ssh_password #ssh_private_key #snmp #snmpv3 #vmware #windows #mssql #cim
I believe the reason for this is that AWS makes API calls directly from the instance to AWS to pull back the information. As such it never actually uses the mid server to pull a credential.
I think the answer to this is simply that it can't be stored and pulled from a third party credential store. Please mark as correct if this turns out to be true.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎03-15-2018 06:32 AM
Hello,
I would check out https://docs.servicenow.com/bundle/jakarta-servicenow-platform/page/product/discovery/concept/external_cred_storage_configuration.html
If you look at the example file you can see that it appears only the following are supported:
#TYPE is one of #ssh_password #ssh_private_key #snmp #snmpv3 #vmware #windows #mssql #cim
I believe the reason for this is that AWS makes API calls directly from the instance to AWS to pull back the information. As such it never actually uses the mid server to pull a credential.
I think the answer to this is simply that it can't be stored and pulled from a third party credential store. Please mark as correct if this turns out to be true.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎03-16-2018 08:02 AM
Rob,
This appears to correct. The answer I am getting from ServiceNow support confirms what you are saying, that the CredentialResolver JAR is not capable of handling AWS credential types.
Thanks

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎01-11-2019 03:10 PM
Old thread but the AWS credential types are often used along with Cloud Management - if that is your use case then in London Patch 2 a mid-server configuration parameter called mid.capi.use_token_override - add this and set the value to true.
Then modify the existing STSTokenOverrideScript script include to return your credentials and Cloud Management CAPI will use your creds for AWS cloud discovery.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎08-29-2019 05:20 AM
Appreciate this is an old thread but for anyone facing the same issue I have managed to resolve this myself through trial and error. Note I am on a London instance with a Windows based MID Server.
ServiceNow does use the MID server for AWS calls, and the CredentialResolver class can handle AWS type credentials even though it isn't explicitly mentioned in the dummycredentials.property file (no check is actually made of the class, just of the name).
It ends up being really simple, just set the AWS Access and Secret keys in the username and password properties respectively, with a type of AWS, e.g.:
AWSServiceAccount.aws.user=ACCESSKEY
AWSServiceAccount.aws.pswd=SECRETKEY
Create a credential in ServiceNow with a Credential ID, and link this to your Cloud Service account.