How do I use HashiCorp Vault with Wasabi?
HashiCorp Vault provides access and secrets management for sensitive data for on-prem, cloud, and hybrid environments. The Hashicorp Vault AWS Secrets Engine can be used with Wasabi to generate on-demand, ephemeral secrets for accessing your Wasabi data.
Vault backup snapshots may also be stored in Wasabi.
This document outlines the procedure for setting up Vault for use with Wasabi.
Prerequisites
Active Wasabi Cloud Storage Account.
Access to the Wasabi Console as the account root user.
Hashicorp Vault configured. This solution was tested with Vault version 1.21.1 running on macOS version 26.2.
Access to the Vault GUI console and CLI.
How to Use the Vault AWS Secrets Engine with Wasabi
This portion of the article details how to generate temporary secrets for use with Wasabi. See the How to Store Vault Backup Snapshots in Wasabi section below for details about snapshot storage.
Initial Wasabi Console Configuration
Login to the Wasabi Console as the account root user.
Configure a policy for a “vault” user (that will be created below) using the following policy. See Creating and Deleting a Policy for instructions on how to create a policy. We named the policy “VaultPolicy” in our example. Change YOUR_ACCOUNT_ID to your own account ID which can be found under Settings in the Wasabi Console.
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "iam:AttachUserPolicy", "iam:CreateAccessKey", "iam:CreateUser", "iam:DeleteAccessKey", "iam:DeleteUser", "iam:DeleteUserPolicy", "iam:DetachUserPolicy", "iam:GetUser", "iam:ListAccessKeys", "iam:ListAttachedUserPolicies", "iam:ListGroupsForUser", "iam:ListUserPolicies", "iam:PutUserPolicy", "iam:AddUserToGroup", "iam:RemoveUserFromGroup" ], "Resource": "arn:aws:iam::YOUR_ACCOUNT_ID:user/vault-*" } ] }After the policy is created, copy and save the policy’s ARN by clicking on the copy button and pasting it into a file.

Create a “vault” user and attach the previously created policy to it. See Creating a User for details.
Allow programatic-only access, not console access.
Do not require Multi-Factor Authentication (MFA).
It is not necessary to assign the user to a group.
Save the access and secret keys in a secure location.
Initial Vault Configuration
Login to your Hashicorp Vault console. On a standalone local or developer system, this will be located at http://127.0.0.1:8200 or https://127.0.0.1:8200 depending on whether you are using TLS on your local machine.
Click Secrets Engines, then click + Enable new engine.

Click AWS.

Give the secrets engine a name under Path (“wasabi” in our example). Click Method Options.

Enable and set both the Default Lease TTL and Max Lease TTL per your organization policies. In our example we set them to 12 hours and 1 day, respectively. Click Hide Method Options.

Click Enable engine.

Click Configuration.

Click Configure AWS.

Enter the Access key and Secret key for the previously created “vault” user. Click Root config options to expand it.

Enter the following information, then click Hide Root config options.
Region: us-east-1
IAM endpoint: iam.wasabisys.com
STS endpoint: sts.wasabisys.com
.png)
Click Save.
.png)
Proceed to one of the following sections depending on what you wish to do.
Temporarily Assume a Role
We are going to temporarily assume a role that has a user policy assigned to it.
Login to the Wasabi Console.
In this example the role can list all the buckets in the account and read the contents of the “mt-logging-bucket-ol” bucket. See See Creating and Deleting a Policy for details. Instead of creating your own policy, you may also use one of the preexisting Wasabi policies.
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "s3:ListAllMyBuckets", "Resource": "arn:aws:s3:::*" }, { "Effect": "Allow", "Action": [ "s3:Get*", "s3:List*" ], "Resource": [ "arn:aws:s3:::mt-logging-bucket-ol", "arn:aws:s3:::mt-logging-bucket-ol/*" ] } ] }Click Roles then click Create Role.

Give the role a name and leave the default trust document. Click Save.

Assign the appropriate policy or policies by clicking them from the drop-down list. We are selecting the “LoggingReadOnlyAccessPolicy” created above. You may also use one or more of the preexisting Wasabi policies.

You will see the assigned policies on the right.

Click Roles and copy the ARN for the role you just created. Save this ARN for later.
.png)
Login to your Vault console.
Click Secrets Engines then click the previously created Wasabi engine path.

Click Roles, then Create role +.

Enter a name for the role, select “Assumed Role” for the Credential type, and paste the previously copied Role ARN from the Wasabi console. Click Create role.
.png)
To test the credential creation, click Generate credentials.

Select “Assumed Role” from the Credential type drop-down menu. Click Generate.

Click Copy credentials. Paste these into a secure file.

To test permissions, you may use the AWS CLI. In our example, we edited the ~/.aws/credentials file to include these temporary credentials:
[vault-test] aws_access_key_id = PNIRFKQNXDP44HA7J8WZ aws_secret_access_key = 2znghU9aoloj0qGRAJVglRLOO1QwWAPfJCzq5rCl aws_session_token = uef321-Xz19MFs0PaO85lINrPWAUoh76ZEvrIu_9hIovQl5ncnImmnRh...We then used the following AWS CLI commands to test permissions. Use your bucket name and the appropriate endpoint-url for your bucket.
$ aws s3 ls --profile vault-test --endpoint-url=https://s3.us-east-1.wasabisys.com $ aws s3 ls s3://YOUR_BUCKET_NAME --profile vault-test \ --endpoint-url=https://s3.us-east-1.wasabisys.com $ touch test.txt $ aws s3 cp test.txt s3://YOUR_BUCKET_NAME/test.txt --profile vault-test \ --endpoint-url=https://s3.us-east-1.wasabisys.comThe first two AWS CLI commands worked since we had granted the appropriate permissions. The last command failed with a 403 Access Denied because we did not grant write permissions to the bucket.
Create a Temporary IAM User and Credentials
Repeat steps 1 and 2 in the Temporarily Assume a Role section above. Copy the Policy ARN from step 2.
Login to your Vault console.
Click Secrets Engines then click the previously created Wasabi engine path.

Click Roles, then Create role +.

Enter a name for the role, select “IAM User” for the Credential type and paste the previously copied Policy ARN from the Wasabi console (the policy used in step 2 in the Temporarily Assume a Role section above). This is the policy that will give this IAM user permissions, such as getting a list of buckets, reading data from a bucket, etc. Click Create role.

To test the credential creation, click Generate credentials.

Select “IAM User” from the Credential type drop-down menu. Click Generate.

Click Copy credentials. Paste these into a secure file.

Repeat steps 15 and 16 of the previous section, omitting the aws_session_token from the config file.
How to Store Vault Backup Snapshots in Wasabi
This section will use the Hashicorp Vault CLI for configuration and backing up/restoring snapshots.
Note that integrated storage (Raft) is required for snapshots.
Creating Backup Snapshots
Login to the Wasabi Console and create a Wasabi bucket for storing backup snapshots. See Creating a Bucket for detailed instructions.
For increased security, make your snapshots immutable for a configurable period of time by enabling Versioning and Object Lock on your bucket.
If using Object Lock, set the bucket’s Default Object Retention using Compliance Mode and an appropriate Retention Time for objects in your bucket to be immutable. A good example Retention Time is 90 days. See Setting Object Lock for a Bucket for details.
Note that setting the Object Lock Retention Time does not mean older snapshots are automatically deleted. A bucket Lifecycle Policy must also be created (see next step).
Set up a bucket Lifecycle Policy to delete older snapshots. Here is an example policy configured for a bucket with a 90-day Object Lock Retention Time. The example policy will:
Be applied to all objects in the bucket.
Cause objects to expire at the end of 91 days.
The objects will then be deleted 1 day after that.
If multipart uploads have been used to upload any snapshots, it will also delete incomplete multipart uploads.

Create a test snapshot using the Vault CLI and copy it to your Wasabi bucket using the AWS CLI. Use the proper name for your AWS CLI profile and the appropriate endpoint-url for your bucket. Replace YOUR_BUCKET_NAME with the name of your bucket.
This example discusses the use of Wasabi’s us-east-1 region. Use the region your bucket is located in. See Service URLs for Wasabi's Storage Regions for details.
$ vault operator raft snapshot save snapshot.snap $ aws s3 cp snapshot.snap s3://YOUR_BUCKET_NAME/snapshot.snap \ --profile wasabi --endpoint-url=https://s3.us-east-1.wasabisys.com
In the Wasabi Console click Buckets, then click the name of your bucket. You will see the “snapshot.snap” backup.

Create a script to automate the process. Here is an example. Replace “<your_snapshot_directory>”, “<your_vault_token>” and “<your_bucket>” with your values. Use the appropriate endpoint-url for the region your bucket is located in. Set the PATH variable to the value appropriate for your environment to cover
aws,vault,find, anddatecommands, if required.#!/bin/bash # Set environment variables (if not already set in the cron environment) export VAULT_ADDR="http://127.0.0.1:8200" # Replace with your Vault address export VAULT_TOKEN="<your_vault_token>" # set PATH for aws, vault, find, and date commands if required export PATH="/opt/homebrew/bin:/usr/local/bin/:/usr/bin:/bin" SNAPSHOT_DIR="<your_snapshot_directory>" TIMESTAMP=$(date +"%Y%m%d_%H%M%S") SNAPSHOT_FILE="$SNAPSHOT_DIR/vault_snapshot_$TIMESTAMP.snap" # Ensure the snapshot directory exists mkdir -p "$SNAPSHOT_DIR" # Save the Vault snapshot echo "Saving Vault snapshot to $SNAPSHOT_FILE..." if [ "$(vault operator raft snapshot save "$SNAPSHOT_FILE" > /dev/null 2>&1; echo $?)" -eq 0 ]; then echo "Snapshot saved successfully." else echo "Failed to save snapshot. Check permissions and connectivity." >&2 exit 1 fi # Upload to Wasabi (requires AWS CLI to be configured) aws s3 cp "$SNAPSHOT_FILE" s3://<your_bucket>/backups/vault/ --profile wasabi --endpoint-url=https://s3.us-east-1.wasabisys.com # Optional: Prune old local snapshots (e.g., keep the last 30 days locally) find "$SNAPSHOT_DIR" -name 'vault_snapshot_*.snap' -type f -mtime +30 -delete echo "Old snapshots pruned." exit 0Ensure the vault token used has the least amount of permissions required. An example Vault policy is shown below.
path "sys/storage/raft/snapshot" { capabilities = ["read"] }
Run the script.
$ ./vault_backup.shYou will now see a snapshot backup in your Wasabi bucket under the backups/vault folder.

Schedule the script to run periodically using a cron job.
Restoring a Snapshot from Wasabi
In case you need to restore a snapshot from Wasabi, follow this procedure. Vault needs to be running at the time of the restore.
Issue the following AWS CLI command to copy a snapshot backup from your Wasabi bucket to your local machine.
$ aws s3 cp s3://YOUR_BUCKET/backups/vault/snapshot.snap \ snapshot-to-restore.snap --profile wasabi \ --endpoint-url=https://s3.us-east-1.wasabisys.com
Replace the following values with your unique ones:
“snapshot.snap” with the name of the backup you wish to restore
“YOUR_BUCKET” with the name of your bucket
“wasabi” with the name of your AWS CLI profile for Wasabi
The appropriate endpoint-url for your bucket
As the root Vault user, issue the following CLI command:
$ vault operator raft snapshot restore snapshot-to-restore.snap
Verify your Vault is operating normally and the restore was successful.