Seal wrap is a mechanism that adds an extra encryption layer on top of the normal storage cryptographic barrier. In Stronghold documentation, it can be treated as double encryption (seal wrapping): data is protected by Stronghold’s built-in barrier and then additionally wrapped through the configured seal mechanism.

This approach is especially useful in environments with elevated key protection requirements and in infrastructures that rely on external KMS or HSM systems.

What seal wrap provides

The additional encryption layer can help with:

  • Stronger protection of critical security parameters
  • Compliance-driven environments and stricter internal security policies
  • Deployments where the most sensitive values must be additionally protected by an external seal mechanism
  • Integrating Stronghold into infrastructures that use KMS or HSM systems

How it works

With seal wrap, Stronghold stores selected data not only encrypted by the built-in storage barrier, but also wrapped again through a supporting seal.

In practice, this means:

  • The root key and other critical parameters gain an extra protection layer.
  • Some values in auth methods and secrets engines can be stored in seal-wrapped form.
  • The storage and replication model remains transparent to users, but reads and writes of such values can take longer.

What is usually seal-wrapped

Double encryption primarily applies to critical security parameters in the Stronghold core, including:

  • The root key
  • The keyring
  • The recovery key and related unseal material
  • Other internal critical Stronghold parameters

In addition, supporting backends and plugins use seal wrap for selected sensitive values, for example:

  • LDAP and SAML auth methods for their configuration
  • PKI for issuer keys and certificate bundles
  • SSH for CA keys
  • Transit for keys and key policy data

Enabling and disabling

For supporting seal mechanisms, Stronghold enables seal wrap by default. To disable the extra wrapping for values other than the root key, set the following parameter:

disable_sealwrap = true

This parameter is described in the Standalone configuration.

Important details:

  • Disabling seal wrap does not disable root key protection by the seal.
  • Changing disable_sealwrap takes effect gradually as values are read or rewritten.
  • Enabling it again is also a lazy process rather than an immediate full rewrap of storage.

Sealwrap rewrap

When the seal configuration changes, Stronghold must wrap all seal-wrapped values again so they match the current encryption configuration. This process is called seal rewrap.

Rewrap is especially useful:

  • After migrating to a new seal
  • After changing seal configuration parameters
  • After rotating key material in an external KMS or HSM

Stronghold exposes the following API endpoints for rewrap management:

MethodPath
GET/sys/sealwrap/rewrap
POST/sys/sealwrap/rewrap

The /sys/sealwrap/rewrap endpoint supports two methods:

  • GET /sys/sealwrap/rewrap returns the current process status and counters for processed entries.
  • POST /sys/sealwrap/rewrap starts a rewrap process if one is not already running.

Example request:

curl --header "X-Vault-Token: ${VAULT_TOKEN}" --request POST "${VAULT_ADDR}/v1/sys/sealwrap/rewrap"

During rewrap:

  • The process runs in the background.
  • Progress is shown by GET /sys/sealwrap/rewrap and in the server logs.
  • Do not change the seal configuration until the process finishes.

Rewrap duration depends on the number of seal-wrapped values and the performance characteristics of the external seal backend.

Operational considerations

Take the following into account when you use seal wrap:

  • seal wrap works only with seal mechanisms that support it.
  • If you use an external HSM or remote KMS, seal-wrapped reads and writes can be noticeably slower than normal operations.
  • This matters most for write-heavy workloads and environments with unstable connectivity to the HSM or KMS.
  • If the external seal becomes unavailable during runtime, part of Stronghold functionality may be affected.

Seal wrap and replication

Seal wrap exists below replication logic. This means:

  • Replication carries the data and the requirement that a value should be seal-wrapped.
  • The actual additional encryption is performed by the local seal on each cluster.
  • Different clusters can use different local HSM or KMS keys while keeping the same protection model.

Practical recommendations

Follow these guidelines when you plan to use seal wrap:

  • Use seal wrap when you need stronger protection for key material and other critical values.
  • Evaluate the performance impact before enabling it broadly in production.
  • For HSM integrations, verify that connectivity to the device is stable.
  • Change disable_sealwrap in a controlled way: rewrapping happens gradually.

Additional resources

←
KMS and HSM / Yandex Cloud KMS
Replication / Overview
→