Demo
Demo

Knowledge base

PMTA knowledge base›Configuration block§ 3.3.23

<vault>

An external secrets vault
Secrets not in the node’s files but in a separate vault

Two lines — the address and the token — and from that moment the node can read secrets from an external vault instead of its own files.

What can be moved there. Signing keys (domain-key), the certificate for accepting mail and the password to its private key (smtp-server-tls-certificate), as well as submission password checking via LDAP (authentication-method with the value {vault}:ldap).

The reference is written right in the directive — instead of a path you write {vault}:path/key. The configuration stays readable: it shows where a secret comes from, but not the secret itself.

There is one block per node. There cannot be two vaults.

The token is created by hand on the Vault side and sits in the configuration in plain text — that is, one secret does remain on the node, but one instead of many, and it is revoked in one place.

Example configuration
# the address and the token — all that is needed to connect
<vault>
    server-url https://myvault:4500
    access-token akhdfasdhf786282684734kjsdhf
</vault>

# further secrets are taken by reference instead of a path
smtp-server-tls-certificate {vault}:/v1/kv/data/tlsCerts:smtp-cert
The manual’s example. Only the token stays in the configuration; keys, certificates and their passwords live in the vault and do not end up in the node’s backups.
yellow — — directive names, blue — blocks. They are highlighted the same way in the text of the card.
Block directives: 3
Access 3
access-tokenThe token the node uses to identify itself to the secrets vaultcache-ttlHow long a key from the vault is kept in the node’s memoryserver-urlThe address of the secrets vault
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

0 relations

Referenced from

Lock down permissions on configuration filesA way to remove keys from the file entirely — keep a reference in the configuration instead of the key itself. § 1.6.3smtp-server-tls-certificateGlobalBoth the certificate and its password can be kept not as a file but in a secrets store. § 3.3.1.10domain-keyGlobalThe key may be stored not on disk but in a secrets vault. Then a reference is written instead of a path, including one with selector and domain substitution. § 3.3.1.55.1authentication-method<smtp-user>Checking a password via LDAP goes through the secrets vault — without a declared block it is unavailable. § 3.3.8.2

◇

What else to read

2 articles

◇How the node signs messages and chooses a keyThe key is chosen by the sending domain from the headers, going through the declarations from top to bottom.◇Secrets in an external vaultSigning keys can be kept in HashiCorp Vault: the configuration keeps a path, and the engine fetches the key over HTTP and keeps it in memory without writing it to disk.

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