Advanced Configuration

Table of contents

1. Aliases
2. Cache config
   1. Credential cache
   2. Performance cache
3. Reply delay
4. Formatter

Aliases

Aliases are used to create custom resolvers based on an existing resolvers. It is the finest level of configuration. To assign aliases to a given resolver, supported types can be overriden.

It can be configured with the property below

This example configures aliases to support two AD domains configured into Vault.

vault.secret.ad.types=firstADDomain,secondADDomain
vault.secret.firstADDomain.basepath=firstADDomain/creds
vault.secret.secondADDomain.basepath=secondADDomain/creds

The credential ID configured into ServiceNow will be :

• firstADDomain/myCredOnFirstDomain
• secondADDomain/myCredOnSecondDomain

Cache config

A cache can be defined for a given resolver. Vault Connect provides two caches:

• Credential cache
• Performance cache

Credential cache

The credential cache can only be used when Vault provides a lease with the credential. By example, a dynamic credential (created at each Vault call) provides a lease.

The cache keeps the credential and its lease into the memory and checks the lease at each call on the credential. It avoids to create a lot of unseful dynamics credentials for a Discovery by example. The TTL of the cache is configured directly into Vault.

The Database Resolver activates by default the cache. It can be activate with the given property

This cache follows all the security guidelines from Vault and can be used safely.

Performance cache

A performance cache is available when the credential cache cannot be used (no lease). A TTL can also be configured.

When configuring this cache, the credentials in cache will not be validated into Vault. If the credential is invalidated into Vault, it will be still provided by cache. This cache should only be used with a short TTL and to offset performance issues.

It can be configured with the properties below

This example activates the cache on AD Resolver with a TTL of 10 minutes

vault.secret.ad.cache=true
vault.secret.ad.cacheTTL=PT10M

Reply delay

When using dynamic credentials (created on demand), a delay of propagation of the credential exists between different datacenters, specially if they are far from each other.

For example we experience this delay with the AWS credential configuration. To offset this behavior, we can add a static reply delay after reading the credential from Vault. It is compatible with the cache. This means if you activate the cache, the delay will applied only when reading the credential from Vault (to ensure the replication delay) and if the credential has not changed since the previous call. Revalidation on each call can be forced with the property revalidate.

It can be configured with the property below

This example configures a reply delay for AWS credential type with a delay of 90 seconds

vault.secret.aws.replyDelay=PT90S
vault.secret.aws.revalidate=true

Formatter

A formatter can be defined on a field’s value. It can be used to :

• Configure static values (eg. for the authprotocol and privprotocol)
• Decorates existing values

By example, the AD secret engine into Vault returns only the username of the credential (without the @domain) even if the service account name configured contains this @domain. If you need the @domain to authenticate, you can create a configuration for each domain to decorate the returned value

It can be configured with the property below for each field

This example configures a formatter for the username value on the AD Resolver

vault.secret.ad.format.username=%s@internal.myDomain.com

This example configures a default value for the authprotocol field on the SNMPv3 credentials.

vault.secret.snmpv3.format.authprotocol=RSA