stiankri

The footnote and the entry was a bit rushed and was not intended to be snarky.

To the best of my knowledge - please correct me if I'm wrong - you cannot say a secret should be valid in a time period in Vault. The TTL will tell the client that they should check back with Vault for the most up to date secret when the TTL expire. If the client credentials are still valid, and the secret has not been revoked or updated in some other fashion, the client will fetch the same value again. Hence the claim that it does not support secret value expiration.

Thank you for your feedback and clarifications.

Vault is a well regarded project that is designed to solve a broader set of problems than Strongbox (i.e. Vault has many different backends, more auth solutions etc.). While there are third party solutions and plans to get more convenience functionality into Vault, we decided to focus on what you would get out of the box today.

"file secrets" was intended to be that you can input a binary file directly either in the CLI or GUI without having to manually base64 encode it first. Please correct me if I'm wrong, but I think that is not currently possible with Vault? Strongbox used to require the user to base64 encode the binary file first as well.

For Strongbox CloudTrail logs are indirect: you need to look at the logs of the backends used by Strongbox, i.e. KMS and DynamoDB. Consistent naming of the resources (managed by Strongbox) should help you filter out the correct entries.

That is certainly one approach we have looked at. The question then is where would you run the REST API? As a side car, as a separate service, e.g. using AWS API Gateway and Lambdas?

If you look at the work required to write a simplified read-only client using the AWS SDK for KMS and DynamoDB, while perhaps a bit more work than integrating with a REST API, it is not that far off, which is why we are considering that approach. That would of course not help if you are using a language that does not have an AWS SDK.

[1] Please follow the link to see a comparison table with Hashicorp Vault and AWS Parameter Store: https://schibsted.github.io/strongbox/ [2] One of the fundamental differences between BlackBox and Strongbox is that BlackBox is based on GPG, while Strongbox is based on AWS KMS for encryption. Also BlackBox stores secrets in VCS repositories, while Strongbox primarily use AWS DynamoDB (while files are also supported).

AWS Parameter Store certainly has merit. As you can see from the comparison table there are certain functionality that is supported by Strongbox which AWS Parameter Store does not currently offer, like larger secrets, more secrets etc.

You can use the assume role functionality with Strongbox. The examples don't do this for simplicity.

Strongbox was designed prior to AWS Parameter Store, and took its inspiration from projects like Fugue CredStash and similar AWS KMS based projects. While there are certainly pros and cons with the different approaches, which you can see in the linked comparison table, I think one of Strongbox' strengths is that it is easy to set up, and you get a lot of convenience functionality related to secrets management. Not having to maintain running services, and natural compartmentalization using both AWS IAM and AWS accounts was two of the drivers.

$1 per group of secrets, e.g. a service. In many cases I think this is fine, but it is certainly not a strength.

The project has been used in production since the summer of 2016. It is being used by a number of teams, and has been contributed to by more than 20 developers (there is a CONTRIBUTORS file).

The backup will take the data stored in DynamoDB (or a file) and serialize to an encrypted file. It will not backup the KMS key, or IAM policies. Hence, it is useful to take snapshots of your state, but not a full disaster recovery.

You can take a backup by a click of a button in the GUI, or using the cli: `strongbox group backup --group team.project --dst-path my-file.backup`

Today people are using the SDK directly or injecting secrets via the CLI. Multi-language support and integration with e.g. Kubernetes is high on the wish list. The approach we are looking at for multi-language support is to drop the dependency on the AWS Encryption SDK. Creating a read-only SDK in other languages is then straight forward.

I'm the creator of Strongbox. Feel free to ask me technical questions about the project.