Demo
Demo

Knowledge base

PMTA knowledge base›Mechanism§ 11.4

Secrets in an external vault

Vault support
A reference in the configuration instead of a key

Domain signing keys can be stored in HashiCorp Vault instead of files: domain-key gets a path like {vault}:/v1/…:field, and the <vault> block describes access to the store.

The key does not sit on the node’s disk: the engine fetches it from the store over HTTP or HTTPS, keeps it in memory for a set time and does not write it to disk. A key that was not found is remembered as missing for an hour.

Keys can be changed without editing the configuration — for example, during rotation; only version 2 secrets engines are supported.

The main trap is changing a key and expecting an immediate effect. The engine keeps a fetched key in memory for a set time, and a missing one for an hour: after rotation in the store the node may still sign with the old one. clear secretscache flushes the cache.
What the Hub does. Not used: signing keys sit on the node as files, in a closed directory.
Recommended values

What is where:

What How
where the key is the {vault}:/v1/…:field path in domain-key
how the engine goes to the store the <vault> block, HTTP or HTTPS
flush the cache after rotation clear secretscache
The purpose, the in-memory cache, the hour for a missing key, not writing to disk and the secrets engine version come from the manual (§ 11.4). The trap analysis is ours.
Example configuration
# a domain key from the store instead of a file
domain-key sel, example.com, {vault}:/v1/p25/data/domain-keys/example.com:k1
The manual’s example: k1 is the name of the field the key is stored under in the store.
yellow — — directive names, blue — blocks. They are highlighted the same way in the text of the card.
Compatibility
PowerMTA 6.0
described in the manual of this version · platform: any
The vendor does not state the first version for every directive — there is no note here. The name also appears in the 5.0 edition of the manual.
⇄

Related entries

2 relations

Works together with

Clear the secrets cacheThe command through which the mechanism is observed. inference

Can be replaced by

How the node signs messages and chooses a keyA related mechanism: they work together. § 11.4

How to check on the node
After changing a key in the store, flush the cache and look at the log:
pmta clear secretscache
grep -i vault /var/log/pmta/log | tail -20
After the cache flush the engine requests the key anew; store access errors are looked for in the log.
◇

What else to read

3 articles

◇Who is allowed to submit mail and for whom to accept itOut of the box, the node accepts submission only from the machine itself; two different questions — “who can send through us” and “for whose addresses we accept mail” — are answered by different directives.◇The group that grants management rightsMembership in the pmta group gives an unprivileged user the right to call the node’s commands and use submission.◇How the node selects a source and combines its settingsA connection falls under all source blocks whose addresses cover it, and they act merged — the narrow one overrides the wide one; named blocks are attached only by direct reference.

In the Hub
Cost of a mistake
reversible: harms only while it is set
Scenarios
Key rotation · Node security