HashiCorp Vault
Connect to your HashiCorp Vault to securely access application secrets, API keys, and sensitive data from anywhere in Superblocks. This guide covers:
- How to set up a new secret store connected to HashiCorp Vault
- Using secrets throughout the Superblocks platform
- Configuring and managing caching for your secret store to improve API performance
Prerequisites
To set up HashiCorp Vault as a secret store for Superblocks you'll need:
- An on-premise deployment of HashiCorp OR a HashiCorp account with Vault configured
- Permission to manage HashiCorp Services, access to manage HashiCorp Vault cluster, and ability to create and configure Secrets engines
- Admin permission for your Superblocks organization
Set up
Create Secrets Engine with secrets key-value pair
To set up a key-value secrets engine in HashiCorp Vault:
- Navigate to your Vault Cluster
- Launch the Vault Web UI
- In the Vault Web UI, navigate to Secrets Engine
- Proceed to create a new secrets engine
- Choose KV Version. Opt for either version 1 or 2 of the Key-Value (KV) secrets engine, based on your requirements
- Add your secrets as key-value pairs
- Customize the path and configure access to your secrets as needed
Configure secret store
Finally, configure a new secret store in Superblocks:
Go to the Secrets Management page in Superblocks
Click the HashiCorp Vault tile
Name your secret store
Paste or enter in the info for Address, Namespace, Path, Version, Auth Type, and Token configurations that were set in your Secrets engine
Address The Address is your cluster's public URL. It is located on the Vault Cluster page when you select your Vault. Namespace The Namespace is used for creating service accounts and managing who can access what. The default value is admin
. It is optional and configured on the secrets engine.Path The Path tells Vault which secrets engine it should route requests to. It is configured in the Key Value secrets engine. Version The Version is which version of Key Value secrets engine to use (either v1 or v2 currently). It is configured in the Key Value secrets engine. Auth Type The Auth Type specifies which Auth flavor to use for connecting to HashiCorp Vault. The default configuration is Token. App Role is also available which requires a Role ID
andSecrets ID
.Token The Token is used to authenticate requests for secrets. It is located on the the Vault Cluster page when you select your Vault. Configure caching rules for this store
Optionally, add more configurations for different environments
Click Create
success
Your secret store is now configured. Use it in backend APIs and integration's to reference your secrets.
Using secrets
After configuring your secret store, reference secrets using the {{sb_secrets}}
object. Secrets are accessed from their respective stores using the syntax {{sb_secrets.STORE_NAME.SECRET_NAME}}
.
Secrets are available to reference in Backend APIs and Integrations. Note that for security purposes, secrets cannot be referenced in Frontend JS or Components.
Secrets are fetched at runtime from a particular store based on the API's current Profile.
info
If your secret is stored as a JSON object in key:value form, use the JavaScript JSON.parse()
function to reference the secret value inside integration forms: {{JSON.parse(sb_secrets.STORE_NAME.SECRET_NAME).SECRET_KEY}}
If your secret includes spaces or special characters, use array notation instead of dot notation to access the secret:
{{sb_secrets.STORE_NAME['SECRET_NAME']}}
Caching
If enabled, Superblocks can cache your secrets, reducing calls to your secrets manager and imporoving API performance when using secrets. Caching can be configured for each of your secret store's configurations, letting you set different policies based on the environment.
To configure caches, go to Secrets Management and click into your secrets store. From here you can:
- Update the Cache TTL (seconds) to your desired caching interval
- Clear the cache if you've rotated a secrets and need Superblocks to refetch secret values
info
If you're running the On-Premise Agent, secrets are cached in-memory by your agent. For scaled deployements, you'll need to clear each instances' cache individually when rotating secrets.
To rotate secrets more easily, disable caching first. Then, after updating the secret, re-enable caching.