FAQ
Provide an easy and secure way to manage, store and distribute secrets such as passwords, access tokens, private certificates and encryption keys.
The larger problem of Identity and Access Management (IAM), including distribution of the first secret to a node (Strongbox requires AWS IAM to be in place to function).
The goal is to make Strongbox easier to use and maintain than the competitors. The approach to achieve that has been the serverless architecture (to avoid deploying and maintaining a service), GUI for easy management, and by depending on IAM we can reuse their solutions for getting the initial secret to a machine (e.g. instance profiles).
The top two similar solutions is Hashicorp's Vault and Microsoft Azure's Key Vault. Microsoft's Key Vault is a feature rich and mature solution, but works best for Azure and it's closed source. Hashicorp's Vault attempts to solve the more ambitious problem of access management, rather than just being a "dumb secret store", which is Strongbox' goal. Strongbox uses the same basic mechanisms as Fugue's SecretStash and Biscuit, but it has more features, and should be easier to use.
Strongbox is serverless. This means that Strongbox itself is a client side application, utilizing AWS resources (DynamoDB, KMS, IAM). The advantage is that there is no service to manually configure or maintain: Strongbox does the configuration and AWS run the services. This lowers the barrier of entry and maintenance cost, but it does have the drawback that any rogue Strongbox admin has pretty much full access to tamper with the data, since there is no server-side verification of the client-side actions. The only way to detect this would be to secure and study CloudTrail logs, but there is no easy way to do this at the moment.
Because Strongbox is serverless everything will for the time being happen on the client-side. The ways to use Strongbox now is via the Java SDK, the CLI/GUI, and via the Archaius integration (also JVM based). Other languages should for the time being use the CLI, either to bootstrap their process with the secrets, or call the CLI via a subprocess. This is not a particularly satisfying solution. In theory there can exist native clients in other languages, but they would need to be compatible both with the Strongbox Java SDK as well as the underlying AWS services. The amount of work to keep the different implementations in sync might prove too big. Another approach we might explore is having a sidecar (that would expose the Java SDK via e.g. a REST API). Yet another approach could be to move this API server-side, either in a AWS Lambda, or as a regular service. The security implications of this is not clear.
Yes - it still needs to run on AWS - but it can be accessed outside AWS. The problem here is how to manage the initial secret. It is possible to create an AWS user and distribute the credentials outside AWS (just like most developers get access to their dev account). The credentials are going to be long-lived, and need to be managed in a secure way. Doing this is outside the scope of Strongbox.
All the data is encrypted in the same way as the individual secrets in DynamoDB. This includes techniques (signing/encryption context) that ensures the integrity of the data. We expose the Secrets Group name and Region, but we do not consider this information to be secret. However, due to the AWS Encryption SDK, the ARN to the KMS master key, which includes the AWS account ID, is leaked. While the AWS account ID is not secret per se, it can be very useful to an attacker, so please do not put the file in a publicly available place.
Backing up to a File will take the state in DynamoDB and serialize it to a binary format that is padded before encrypting it. Please see "How secure is the file format?" for more information. I.e. neither the IAM policies nor the KMS key is backed up by doing this process.
First off there should be no need to do this. They are auto-generated for your convenience and they are security reviewed. If you make changes you are on your own. If you still think you need to make changes and know what you are doing please keep in mind that we do not backup your changes, so you would manually have to re-apply those changes if needed later.
Not necessarily. Deleting a Secrets Group will immediately delete the underlying DynamoDB table as well as detach any principal (user, group, role) associated with the IAM policies and then delete the IAM policies. These actions cannot be undone, but the resources can potentially be recreated. The KMS key will be scheduled for deletion in 7 days. Unless the KMS key deletion is aborted within the 7 days, the KMS key will be gone forever, and there will be no way to recover the Secrets Group. If you want to be able to recover the Secrets Group, you must have taken a backup of DynamoDB, e.g. by doing a backup to File. You must also have made no changes to the IAM policies, or know how to manually re-apply those changes. If you are in this situation, you can create a Secrets Group with the --allow-key-reuse flag, which will re-enable the KMS key, and create new IAM policies. You can then restore using the File backup. The last step would be to manually attach those principals that should have access.
Some information is stored in plaintext: Secret name, Secret version, State (enabled/disabled/compromised) and notBefore/notAfter. This is to be able to quickly scan/query DynamoDB to allow this part of Strongbox to scale with DynamoDB (decryption scales with KMS). The rest of the information, including the secret itself and the comment is stored encrypted in a way that read-only clients cannot tamper with the information.