51–58 of 58 posts
Current parameter store user - one feature not mentioned in the comparison is the fact that accessing / updating a secret in parameter store will show up in Cloudtrail. Is there a similar audit trail in strongbox?
The comparison with Vault is somewhat misleading. - There are several free UIs available for Vault like https://github.com/djenriquez/vault-ui , they just aren't provided by Hashicorp - I'm not sure what "file secrets" might refer to other than storing the contents of a file, for which Vault's CLI provides shortcuts. - While Vault's generic k/v backend doesn't support purging expired values in order to avoid accident…
Earlier quoted context omitted.
You're assuming readers are managing snowflake servers, and I'm assuming they are in an containerized/autoscaling/more modern environment. SSM wins for mine. I think you're right that the file approach wins for yours.
I'm assuming readers are just starting out, where auto-scaling and bloggable container architectures make very little sense. Configuration management is a prerequisite for those. That said, having a CM in place also makes the please-invest-in-us container ecosystem much less attractive, given that you can easily fall back to singleton-container-on-an-instance patterns (which is a great one for deployment regardless o…
Charging $1 per secret is interesting. I wonder if that will affect how people design their application. We've had a pretty splendid experience with Vault so far, so I'm not exactly in the market for another solution, but this looks interesting. I assume you started development on this because Vault et al didn't exist yet at the time? Or was there another driver?
why not just use parameter store? https://aws.amazon.com/ec2/systems-manager/parameter-store/ . Plus: don't use credentials directly, use the assume role feature.
Is it possible to use Parameter Store without configuring System Manager for the instances where it's used? I recently looked into SSM but was put off because the docs[1] suggested that you add the managed AmazonEC2RoleforSSM policy to instances, which among other things give them full read/write access to all S3 buckets. Edit: also discovered by others[2]. [1] http://docs.aws.amazon.com/systems-manager/latest/usergu…
The policy I built today, for example, granted SSM:GetParameter* for parameters in the '/dev' or '/staging' path hierarchy. You won't find this fully documented at the moment, but you can separately manage encryption/decryption of secrets using conditions and kms:EncryptionContext, e.g.,
"Condition": { "StringLike: { "kms:EncryptionContext:PARAMETER_ARN": "arn:aws:ssm:::parameter/dev*" } }
One point I will note in relation to other secret management schemes is that Parameter Store seems to use CMKs directly to encrypt parameters rather than relying on data keys and envelope encryption.
The comparison with Vault is somewhat misleading. - There are several free UIs available for Vault like https://github.com/djenriquez/vault-ui , they just aren't provided by Hashicorp - I'm not sure what "file secrets" might refer to other than storing the contents of a file, for which Vault's CLI provides shortcuts. - While Vault's generic k/v backend doesn't support purging expired values in order to avoid accident…
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.
The comparison with Vault is somewhat misleading. - There are several free UIs available for Vault like https://github.com/djenriquez/vault-ui , they just aren't provided by Hashicorp - I'm not sure what "file secrets" might refer to other than storing the contents of a file, for which Vault's CLI provides shortcuts. - While Vault's generic k/v backend doesn't support purging expired values in order to avoid accident…
It also has that snarky little footnote saying that a "TTL" isn't the same thing as an expiration time next to the entry claiming vault doesn't support secret expiration.
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.