3 ms·

SSM parameter store only stores one thing at a time, but SM stores things in key/value pairs which you can retrieve all at once.

arkadiyt 8y ago
Make your value a JSON string, problem solved ¯\_(ツ)_/¯
sudosteph 8y ago
You can definitely retrieve multiple values, stored as k/v pairs at once with SSM parameter store. https://docs.aws.amazon.com/cli/latest/reference/ssm/get-parameters-by-path.html https://docs.aws.amazon.com/cli/latest/reference/ssm/get-par... Just use the --recursive option. I'm of the opinion that AWS just doesn't like people using SSM Parameter store w/ KMS encryption as the main solution b/c they realized too late that they missed an opportunity to charge money for it.
- Aeolun 8y ago
  I’d rather they charge for it. They need some incentive to keep developing it, and parameter store is frankly atrocious.
dmlittle 8y ago
If you're using path prefixes you can retrieve all of them easily using the AWS SDK[1,2]. One of the things that we do is to prefix all of our SSM keys with a prefix based on the service name (for example, `example-api/`) and fetch them by path rather than individually. [1] https://docs.aws.amazon.com/sdk-for-go/api/service/ssm/#SSM.GetParametersByPath https://docs.aws.amazon.com/sdk-for-go/api/service/ssm/#SSM.... [2] https://docs.aws.amazon.com/AWSJavaScriptSDK/latest/AWS/SSM.html#getParametersByPath-property https://docs.aws.amazon.com/AWSJavaScriptSDK/latest/AWS/SSM....
- sudosteph 8y ago
  Yeah, the prefixes are killer too because they work well so with IAM. So you if you have multiple teams sharing an AWS account, you can also prefix by team name and limit decryption rights to those users and their resources. The only downside is that the path is limited to 5 items IIRC. Which you can actually get to pretty fast with stuff like: /team/service/environment/keyParent/keyChild "environment" above would be like "prod" or "dev".
  - dmlittle 8y ago
    I didn't know about the limit although you might be able to get it bumped? In my experience we haven't had any issues getting to that limit but we only ever use 1 level of depth (the service) and each environment has it's own AWS account so there is no path for environment. Each service has a IAM Role with an IAM Policy attached that gives it access to all of the keys under the service path. A way to fix the team prefix (what if 2 teams actually need access to that secret?) would be to not have it in the path but use roles that teams can assume to get access to those secrets.
    - sudosteph 8y ago
      Yeah, I personally find using separate AWS accounts for dev/test/stage to be a bit of a PITA overall, prefer to isolate those resources via VPCs & IAM policies in an umbrella non-prod account, but definitely see how that would simplify other aspects of setup. The path limit isn't a huge issue, just something you have to design around up front. As you mentioned in another comment, no reason you can't store a JSON or something in the string if you need deeper nesting. For secrets needing to be shared between teams I'd just create a different prefix in the place of team, like /shared/, and grant access appropriately. Or just use no team prefix at all and make it accessible if it's for everyone. But it's quite nice that the service is flexible enough to be useful for a variety of use cases / infrastructure setups.
      - scarface74 8y ago
        VPCs are not a substitute for accounts. Most AWS resources must have unique names across the account like lambdas, SQS queues, sns topics etc. When you have one account you end up prefixing/suffixing resource names for different environments. It gets to be really ugly.

arkadiyt 8y ago

Make your value a JSON string, problem solved ¯\_(ツ)_/¯

sudosteph 8y ago

You can definitely retrieve multiple values, stored as k/v pairs at once with SSM parameter store. https://docs.aws.amazon.com/cli/latest/reference/ssm/get-parameters-by-path.html https://docs.aws.amazon.com/cli/latest/reference/ssm/get-par... Just use the --recursive option. I'm of the opinion that AWS just doesn't like people using SSM Parameter store w/ KMS encryption as the main solution b/c they realized too late that they missed an opportunity to charge money for it.

Aeolun 8y ago
I’d rather they charge for it. They need some incentive to keep developing it, and parameter store is frankly atrocious.

dmlittle 8y ago

If you're using path prefixes you can retrieve all of them easily using the AWS SDK[1,2]. One of the things that we do is to prefix all of our SSM keys with a prefix based on the service name (for example, `example-api/`) and fetch them by path rather than individually. [1] https://docs.aws.amazon.com/sdk-for-go/api/service/ssm/#SSM.GetParametersByPath https://docs.aws.amazon.com/sdk-for-go/api/service/ssm/#SSM.... [2] https://docs.aws.amazon.com/AWSJavaScriptSDK/latest/AWS/SSM.html#getParametersByPath-property https://docs.aws.amazon.com/AWSJavaScriptSDK/latest/AWS/SSM....

sudosteph 8y ago
Yeah, the prefixes are killer too because they work well so with IAM. So you if you have multiple teams sharing an AWS account, you can also prefix by team name and limit decryption rights to those users and their resources. The only downside is that the path is limited to 5 items IIRC. Which you can actually get to pretty fast with stuff like: /team/service/environment/keyParent/keyChild "environment" above would be like "prod" or "dev".
- dmlittle 8y ago
  I didn't know about the limit although you might be able to get it bumped? In my experience we haven't had any issues getting to that limit but we only ever use 1 level of depth (the service) and each environment has it's own AWS account so there is no path for environment. Each service has a IAM Role with an IAM Policy attached that gives it access to all of the keys under the service path. A way to fix the team prefix (what if 2 teams actually need access to that secret?) would be to not have it in the path but use roles that teams can assume to get access to those secrets.
  - sudosteph 8y ago
    Yeah, I personally find using separate AWS accounts for dev/test/stage to be a bit of a PITA overall, prefer to isolate those resources via VPCs & IAM policies in an umbrella non-prod account, but definitely see how that would simplify other aspects of setup. The path limit isn't a huge issue, just something you have to design around up front. As you mentioned in another comment, no reason you can't store a JSON or something in the string if you need deeper nesting. For secrets needing to be shared between teams I'd just create a different prefix in the place of team, like /shared/, and grant access appropriately. Or just use no team prefix at all and make it accessible if it's for everyone. But it's quite nice that the service is flexible enough to be useful for a variety of use cases / infrastructure setups.
    - scarface74 8y ago
      VPCs are not a substitute for accounts. Most AWS resources must have unique names across the account like lambdas, SQS queues, sns topics etc. When you have one account you end up prefixing/suffixing resource names for different environments. It gets to be really ugly.