ParameterStore should be part of KMS instead I think.
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)
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.