Strongbox: a secret manager for AWS(schibsted.github.io) |
Strongbox: a secret manager for AWS(schibsted.github.io) |
ParameterStore should be part of KMS instead I think.
https://segment.com/blog/the-right-way-to-manage-secrets/
I really think it's just an AWS account with credstash under the hood, that some Amazon engineers work on full time. Seems like a no-brainer to use imo, since it's very polished.
You can use the assume role functionality with Strongbox. The examples don't do this for simplicity.
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/userguide/...
[2] http://www.daemonology.net/blog/2016-10-09-EC2s-most-dangero...
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:<region>:<acct#>: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.
In terms of not using credentials directly, relying on AWS KMS for encryption keys, and the use of IAM policies to control access to secrets, Strongbox and AWS Parameter Store share a similar design.
- 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 accidental data loss, there are plenty of other backends that integrate with AWS STS, Postgres, etc. to provide dynamic, short-lived credentials.
- I'm not sure how Vault doesn't support encrypted backups seeing as the data is already encrypted on disk. Take EBS snapshots or something.
- Versioning of secrets is a popular request and Hashicorp has some "vague plans" which is an improvement from "no plans." https://github.com/hashicorp/vault/issues/1364#issuecomment-...
Plus you get a full REST API, a ton of auth methods, granular access policies, etc.
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.
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.
Most secrets are injected in real time at the startup of of a container. For tools like this or plugins in k8 / docker to access your store you should support this. It's really bad practice to create a hard dependency on your secrets store by using the Java sdk directly in your application. If that's not the intent definitely provide a Golang sdk for proper plugin integration.
Can you explain how secrets are injected now?
The cool thing is obviously the spring integration, which pulls the secrets on app startup and overwrites or augments the values in the application.(properties|yml)
It can also run kind of serverless by embedding it in your app.
Here are some questions:
Are you using Strongbox in production?
The backup is mentioned, but how exactly do you backup?
Thanks
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`
If you are using AWS, EC2 itself is a trusted third party that grants the appropriate permissions for your executing system (container, instance, whatever).
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?
$1 per group of secrets, e.g. a service. In many cases I think this is fine, but it is certainly not a strength.
Envkey let me set up and deploy secrets management across 3 server groups (development/staging/production) for our web app in under 15 minutes. And I can add new developers and devops people to our app in seconds.
I normally don't like hijacking other people threads about their hard work like this, but I just thought this product should be mentioned as it was a real time saver and headache reducer for us. Very happy to see people like the developers of StrongBox trying to solve this issue and make secrets management easier. The more players in this space, the better, IMO.
Tools like this one (Strongbox), Parameter Store, etc. are great when you know AWS well and prefer more of a DIY approach on the integration side. EnvKey is more of a "just works" solution for when you either don't have as much DevOps expertise or want to get a secure setup up and running asap so you can move on to the next thing.
EnvKey also helps on the configuration management side with juggling multiple environments (development, staging, production, etc.), inheritance between environments, and keeping developers in sync with each other.
It can be versioned if you use git, access controlled via the KMS access privileges, and easily plugs into other tools because it uses YAML. Simplicity is the killer feature.
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.
I could definitely envision people deciding against using your key store when comparing to something like Vault based just on the fact that you limit extensibility with no API.
One big problem with AWS and their incremental features / improvements is you never hear about much of it, or its buried in a post from Jeff's blog that you have to watch like a hawk to keep up with.
Since a while, I subscribed to „AWS this week“ on YouTube from a cloud Guru. This is just 5 minutes, and you have a good idea what‘s going on. (I have no affiliation)
If you do nothing you end up stuck with secrets in git history and you essentially have to roll them all.
So, my advice is generally SSM with no security is better than no secrets Management solution.
SSM wins for mine. I think you're right that the file approach wins for yours.
To that end, yes, their servers are probably hand-rolled or provisioned with minimal scripting like Ansible. And so manual secret deployment is to be expected.
If somebody is attempting to autoscale without having this solved already, they are making mistakes.