Vault Transit Secret Engine with HA Cluster with Integrated Storage

I had a question about the Vault transit secret engine and scaling a Vault cluster’s ability to service encrypt/decrypt requests. Reading some HA docs (High Availability | Vault by HashiCorp) it mentions that standby nodes just forward requests to the active node (or redirect requests). Is this every request? E.g. for encrypting/decrypting via the transit engine, do all requests go through the active node?

Is there a way to scale out the transit secret engine request handling such that multiple nodes handle the workload? I’m not able to find any documentation pertaining to this question. I read about performance standby vault nodes that can service reads, but the transit secret encrypt/decrypt functions are write request, leading me to think that the active node still deals with these requests.

Any guidance would be very much appreciated!

HA mode in OSS will forward any request to the active node. You cannot scale horizontally in this scenario.

HA in Enterprise will service what it can - usually reads but edge cases like PKI generations, etc. You can scale out x-nodes that will service transit requests to allow horizontal scaling.

That functionality is called performance standby (or read replica in some docs).

Wow thanks for the speedy and great reply! One follow up question, does the transit secret engine encrypt/decrypt cause a storage write? I would assume it does based on the fact that the encrypt/decrypt api has write in it but I’m not all that experienced with Vault so I might as well ask :slight_smile: (e.g. vault write transit/encrypt/my-key plaintext=$(base64 <<< “my secret data”)

It does not cause a write. It is an exception to the rule that a write will go back to the active. Transit and transform can do what they need without forwarding to the active in a read replica/enterprise cluster.

Great news! Thanks a bunch for the great and speedy feedback.

1 Like