f3df55ad58
* Adding check-legacy-links-format workflow * Adding test-link-rewrites workflow * Updating docs-content-check-legacy-links-format hash * Migrating links to new format Co-authored-by: Kendall Strautman <kendallstrautman@gmail.com>
86 lines
3.2 KiB
Plaintext
86 lines
3.2 KiB
Plaintext
---
|
|
layout: docs
|
|
page_title: Configure Vault ServiceNow Credential Resolver
|
|
description: This section documents the configurables for the Vault ServiceNow Credential Resolver.
|
|
---
|
|
|
|
# Configuring the Vault Credential Resolver
|
|
|
|
## MID server properties
|
|
|
|
The following [properties] are supported by the Vault Credential Resolver:
|
|
|
|
- `mid.external_credentials.vault.address` `(string: "")` - Address of Vault Agent as resolveable by the MID server.
|
|
For example, if Vault Agent is on the same server as the MID server it could be `https://127.0.0.1:8200`.
|
|
|
|
- `mid.external_credentials.vault.ca` `(string: "")` - The CA certificate to trust for TLS in PEM format. If unset,
|
|
the system's trusted CAs will be used.
|
|
|
|
- `mid.external_credentials.vault.tls_skip_verify` `(string: "")` - When set to true, skips verification of the Vault server
|
|
TLS certificiate. Setting this to true is not recommended for production.
|
|
|
|
[properties]: https://docs.servicenow.com/bundle/quebec-servicenow-platform/page/product/mid-server/reference/r_MIDServerProperties.html#t_SetMIDServerProperties
|
|
|
|
## Configuring discovery credentials
|
|
|
|
To consume Vault credentials from your MID server, you will need to:
|
|
|
|
* Create a secret in Vault
|
|
* Configure the resolver to use that secret
|
|
|
|
### Creating a secret in Vault
|
|
|
|
The credential resolver supports reading credentials from the following secret engines:
|
|
|
|
* [Active Directory](/vault/docs/secrets/ad)
|
|
* [AWS](/vault/docs/secrets/aws)
|
|
* [K/V v1](/vault/docs/secrets/kv/kv-v1)
|
|
* [K/V v2](/vault/docs/secrets/kv/kv-v2)
|
|
|
|
When creating K/V secrets, you must use the following keys for each component
|
|
to ensure it is correctly mapped to ServiceNow's credential fields:
|
|
|
|
Key | Description | Supported aliases
|
|
------------|----------------------------------------|------------------
|
|
username | The username | access_key
|
|
password | The password | secret_key, current_password
|
|
private_key | The private SSH key |
|
|
passphrase | The passphrase for the private SSH key |
|
|
|
|
Most ServiceNow credential types will expect at least a username and either
|
|
a password or a private key. To help surface errors early, the credential
|
|
resolver validates that a username and password are present for:
|
|
|
|
* aws
|
|
* basic
|
|
* jdbc
|
|
* jms
|
|
* ssh_password
|
|
* vmware
|
|
* windows
|
|
|
|
And the credential resolver expects the following types to specify at least
|
|
a username and a private key:
|
|
|
|
* api_key
|
|
* cfg_chef_credentials
|
|
* infoblox
|
|
* sn_cfg_ansible
|
|
* sn_disco_certmgmt_certificate_ca
|
|
* ssh_private_key
|
|
|
|
### Configuring the resolver to use a secret
|
|
|
|
In the ServiceNow UI:
|
|
|
|
* Navigate to "Discovery - Credentials" -> New
|
|
* Select a type from the list
|
|
* Tick "External credential store"
|
|
* Fill in a meaningful name
|
|
* Set "Credential ID" to the path in Vault where your secret is located, e.g.
|
|
for a KV v2 secret engine mounted at "secret", you might have a secret stored
|
|
under "ssh": `secret/data/ssh`. Check the [API docs](/vault/api-docs/secret/) for
|
|
your secret engine if you are unsure of the path to use
|
|
* **Optional:** Click "Test credential" and select a MID server and a target
|
|
to test against to test everything is working
|