I’m looking for guidance and best practices around accessing SSH private keys stored in secure external key vaults (such as HashiCorp Vault) and using them in Pega, specifically for SFTP / SSH authentication use cases.
Context:
SSH private keys are stored securely in HashiCorp Vault (or similar enterprise key vaults).
For security and compliance reasons, we want to avoid storing private keys directly in Pega Keystore rules, rule forms, or file‑based keystores (JKS/PKCS12).
The objective is to retrieve the key dynamically at runtime and use it with Pega’s keystore rule. This same rule is referred from the FTP Server rule type ( inside “Client Key” section).
I have reviewed the Pega documentation on “Creating a data page activity for a keystore”, which describes using a Data Page with a Load Activity to load keystores into memory.
However, the examples in the documentation mainly focus on:
Loading JKS / PKCS12 keystores from the file system using KeyStoreUtils
Loading JWK keystores from a URL
In our case, we are not dealing with a physical keystore file, but instead with SSH private key material retrieved from an external secure vault.
My questions:
Can the Data Page + Load Activity pattern be used to retrieve an SSH private key from HashiCorp Vault and dynamically populate a Pega keystore at runtime?
Is this the recommended and supported approach when keys are externally managed and not available as JKS/PKCS12/JWK files?
Are there any specific Pega APIs or best‑practice patterns for handling SSH keys retrieved from external key vaults?
How are teams typically handling key rotation, caching, and memory scope in this scenario?
Any security or TRA considerations to be mindful of when following this approach?
If anyone has implemented a similar integration or can share reference architectures, best practices, or lessons learned, your inputs would be greatly appreciated.
Pega supports external key management patterns, but the built-in keystore/documented Data Page approach is oriented around keystore objects such as JKS, PKCS12, JWK, or specific Vault-backed keystore integrations and not arbitrary raw SSH private-key strings loaded ad hoc into the FTP rule at runtime.
Pega’s documentation explicitly mentions HashiCorp Vault keystores and Data Page-based keystore loading, but those patterns are framed around keystore types and master-key/KMS usage rather than a general “fetch raw SSH private key text and inject it into SFTP auth” workflow
So the Data Page + Load Activity pattern is the closest supported extension point if you need dynamic keystore loading.
But for your exact scenario, the better-supported path is to use a Pega keystore integration designed for Vault/keystore material, not to treat raw SSH key material as an arbitrary secret blob and manually couple it into SFTP authentication
The key challenge is that Pega’s keystore APIs and rule forms expect a keystore abstraction, not just any secret. i.e.
file-based JKS/PKCS12 loaded via KeyStoreUtils or
JWK from URL or
Vault-backed keystore definitions for managed cryptographic keys
there is no clear article that I’ve found that says retrieve an SSH private key PEM from Vault and directly attach it to the FTP Server rule’s Client Key at runtime.
So I’d recommend to use a Vault-backed keystore configuration if the key material can be represented in a way Pega’s keystore integration supports. Pega has articles for Configuring a HashiCorp Vault keystore using AppRole authentication. (mentioned above)
However, If your external team insists on raw SSH private key retrieval, implement a custom integration layer that retrieves the key securely from Vault at runtime, keeps it only in memory and is isolated then I would treat that as a custom extension requiring TRA/security review but not as a standard keystore-rule usage pattern.
Also, Pega’s keystore data page supports Node-scoped caching with refresh strategy, which is useful for performance, but with externally managed keys you need to balance cache duration against rotation requirements.
no persistence in clipboard logs, rule forms, or files,
strong masking/logging controls
From a security point of view, avoid storing private keys in rule forms, local keystore files, or any long-lived Pega artifacts, if enterprise policy requires Vault control. Pega’s own KMS/custom-source documentation shows the platform expects external key-management integration to be carefully controlled through dedicated APIs/utilities, not casual secret handling in application logic