Just revised a set of developer policies today. Most systems/users will only need a couple of permissions to leverage parameter store. And if you take the time to dig into the IAM permissions, it's quite impressive how granular you can get.
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.,
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 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.