How to keep Vault Storage optimised through effective Tokenization (Transform Secret Engine) practices

Avatar
Akash Gupta
  • Updated

What?

 
The Transform secrets engine securely performs data transformation and tokenization on the provided input.
 
Tokenization replaces a sensitive value with an unrelated token. This process is irreversible, meaning the original value cannot be derived from the token alone. To retrieve the original value, the token must be submitted to Vault, which uses a cryptographic mapping stored internally to decode it. Tokenization is stateful, and the tokenized state can be stored internally (the default/built-in Vault storage used by the cluster) or in an external store (at the time of writing this article, only PostgreSQL, MySQL, and MSSQL are supported for external storage).
 
This KB relies on the fact of how to effectively store that token in the storage (built-in or external) to keep the Vault database ( vault.db file) optimised in terms of size.
 

How?

While performing the encoding, it is best to make use of ttl to enforce the age of the token so that after the TTL is expired, the automaitc tidy of the transform secret engine clears those entries from the storage.

If the ttl during the encode is not passed, the token can pick the TTL from the role as well via the max_ttl parameter on the role. The ttl is capped to the role's max_ttl value if that's set.

 

If the role doesn't enforce the max_ttl (set to 0), and the ttl is also not set, the token is stored for an indefinite time in the backend storage, and will occupy a lot of storage space if created in bulk. To clear those entries, either disable the whole secret engine itself or take help from the support team to clear those entries from the underlying storage.

 

References

Articles in this section

See more