Beside sharing the implementation of this Hashicorp® Vault integration, this article is also intended to provide you a step by step cookbook to build your own "Credential Resolver".
The source code of this project is available here and the README file contains the instructions to build and use it.
But maybe before going further, it might be useful to discuss the value of a Credential Store for an organisation and also to explain the ServiceNow external credential storage concept by explaining what a “Credential Resolver”.
External Credential Storage
External Credential Storage is a good mechanism for storing credentials that employees share to access web service. The audit log mechanism of such solution lets you also know what credential an employee accessed and when an employee leaves, it is easier to roll keys and understand which keys have and haven't been rolled. Such solutions are a nice way to store sensitive environment variables, database credentials, API keys, etc.
Also, some of them, like the Vault, implements "dynamic secrets" feature which can can generate secrets on-demand for some systems. For example, when an application needs to access certain resource, the store will generate a credential with valid permissions on demand. After creating these dynamic secrets, the store will also automatically revoke them after the lease is up.
HashiCorp Vault is a Credential Store that handles the security and compliance layer at large scale for several joint customer. Standardisation and consistency are the key benefits that customer’s gets from using Vault in general and together with ServiceNow ITOM Applications.
This project has been initiated through a discussion with local customer and a local partner.
A ServiceNow instance can store credentials used by Discovery, Orchestration, and Service Mapping in such external credential repository rather than directly in a ServiceNow credentials record.
This is, my experience, our customer’s preferred method to use credentials with the above mentioned ITOM applications.
The instance maintains a unique identifier for each credential, the credential type (such as SSH, SNMP, or Windows), and any credential affinities. The MID Server obtains the credential identifier from the instance, and then uses a “Credential Resolver” to resolve the identifier from the repository into a usable credential.
Currently, the ServiceNow® platform supports the use of the CyberArk vault for external credential storage. You may also find couple of other “Credential Resolver” on the ServiceNow Store.
Credential Resolver are written in Java and packaged in a JAR file. A JAR (Java ARchive) is a package file format typically used to aggregate many Java class files and associated metadata and resources (text, images, etc.) into one file for distribution
On the ServiceNow documentation side, a Credential Resolver sample code is provided.
This sample demonstrate a "Credential Resolver" that retrieves credentials from a property file located on the MID server file system.
In order to develop, test and use your own “Credential Resolver” or if you want to use my Hashicorp Vault “Credential Resolver”, please apply the following steps:
- Request the installation of the “External Credential Storage” plugin (com.snc.discovery.external_credentials) using the ServiceNow HI Portal or via ServiceNow developer portal on your instance.
- Following steps are there to describe how to build the JAR. If you want to use pre-compiled version, please download them from the Github project’s release section and jump to 7.
- On your development machine, download & install the Java Development Kit. The JDK version should be as close as possible to the MID Java Runtime. At the time of this article, I used JDK 1.8 to compile my “Credential Resolver”.
- Download & install Eclipse.
- Import the published project from Git: HashiCorpVaultCredentialResolver or Create a Java project if you want to create your own Credential Resolver. If you create your own Credential Resolver, replicate the code published on the ServiceNow Documentation in your own project.
- Export compiled resources into a JAR file on the local file system (
-
- If you use my Eclipse project, double click the VaultCredentialResolverJarDesc.jardesc link (As shown below)
-
- Leave all options as defined and specify the path where you want the JAR file to be generated and click “Finnish”.
7. Import the JAR file in your instance
a. Navigate to MID Server – JAR Files
b. Create a New Record by clicking New
c. Name it “vault-java-driver”, version 5.1 and attach this file to the record.
d. Click Submit
e. Create a Second Record by clicking New
f. Name it “VaultCredentialResolver”, version 0.5 and attach this file or the one you have previously compiled to the record
g. Click Submit
h. See below how this should look like in your instance.
8. This Credential Resolver implementation assume that:
- The following MID properties have been defined on the MID server record:
i. mid.external_credentials.vault.address
Ex: http://<vault IP or fqdn>:<port> (default:8200)
ii. mid.external_credentials.vault.token
This is the token used to connect to the vault. (See Vault documentation for details)
-
- Credential in the ServiceNow instance have been created with “External credential store» checkbox activated.
- CredentialID in the ServiceNow Credential Record has been defined to match the credential path in the Hashicorp Vault (See example below and check the Vault documentation on how to create a secret)
ServiceNow CredendialID = secret/hello
Hashicorp Vault Secret = secret<hello
The Credential Resolver performs a lookup in in the Hashicorp Vault and expects the secret to contain following key/value pair:
- For "windows", "ssh ", "vmware", "jdbc", "jms” and "basic" ServiceNow credential type:
-
- username, current_password
- For "ssh_private_key", "sn_cfg_ansible” , "sn_disco_certmgmt_certificate_ca", "cfg_chef_credentials", "infoblox", "api_key":
-
- username, current_password, ssh_passphrase, ssh_private_key
- Other credentials types are for the moment not supported.
- Please reach out if you need them to be implemented.
You reached a point where you should be able to use this deployment. You could for example use the ServiceNow quick discovery function to validate that your setup is up&running.
To troubleshoot, check the MID wrapper.log or the agent.log for error messages.
Helpful? Please let me know by marking it using the below (bottom left) "Helpful" button! Thanks!
19 Comments
