ssm keys doesnt work with variables - Value not found at "ssm" source
See original GitHub issueAre you certain it’s a bug?
- Yes, it looks like a bug
Is the issue caused by a plugin?
- It is not a plugin issue
Are you using the latest version?
- Yes, I’m using the latest version
Is there an existing issue for this?
- I have searched existing issues, it hasn’t been reported yet
Issue description
When trying to use variables its looks like you can’t use any variables
SubnetIds: ${ssm:/SLS/myapp-${opt:stage}/DBSubnets}
will result in
- Cannot resolve variable at "resources.2.Resources.ElasticsearchDomain.Properties.VPCOptions.SubnetIds": Value not found at "ssm" source
and
custom:
stage: ${opt:stage}
...
SubnetIds: ${ssm:/SLS/myapp-${self:custom.stage}/DBSubnets}
result with the same error.
Service configuration (serverless.yml) content
service: myservice
variablesResolutionMode: 20210326
custom:
# Get stage from command line (serverless --stage local|staging|prod)
stage: ${opt:stage}
provider:
name: aws
lambdaHashingVersion: 20201221
runtime: nodejs14.x
memorySize: 256
stage: ${self:custom.stage}
region: us-east-1
resources:
Resources:
ElasticsearchDomain:
Type: AWS::OpenSearchService::Domain
Properties:
DomainName: tasks-${self:custom.stage}
EngineVersion: 'OpenSearch_1.0'
ClusterConfig:
# DedicatedMasterEnabled: true
InstanceCount: '1'
# ZoneAwarenessEnabled: true
InstanceType: 't3.small.search'
# DedicatedMasterType: 't3.small.elasticsearch'
# DedicatedMasterCount: '1'
EBSOptions:
EBSEnabled: true
VolumeSize: '16'
VolumeType: 'gp2'
AdvancedOptions:
rest.action.multi.allow_explicit_index: true
VPCOptions:
#SecurityGroupIds: ${ssm:/SLS/${AWS::StackName}/AppSecurityGroup}
SubnetIds: ${ssm:/SLS/myapp-${self:custom.stage}/DBSubnets}
Command name and used flags
SLS_DEBUG=* npx sls package -s dev
Command output
Environment: darwin, node 15.14.0, framework 3.1.1 (local), plugin 6.0.0, SDK 4.3.1
Credentials: Local, "default" profile
Docs: docs.serverless.com
Support: forum.serverless.com
Bugs: github.com/serverless/serverless/issues
Error:
Cannot resolve serverless.yml: Variables resolution errored with:
- Cannot resolve variable at "resources.Resources.ElasticsearchDomain.Properties.VPCOptions.SubnetIds": Value not found at "ssm" source
Environment information
Serverless: Running "serverless" installed locally (in service node_modules)
Framework Core: 3.1.1 (local)
Plugin: 6.0.0
SDK: 4.3.1
Issue Analytics
- State:
- Created 2 years ago
- Reactions:7
- Comments:7 (4 by maintainers)
Top Results From Across the Web
Accessing SSM variables with Serverless - Stack Overflow
This will tell the framework to decrypt the value. Make sure that you have permissions to use the key used to encrypt the...
Read more >3 Ways to Read SSM Parameters - DEV Community
The CloudFormation template for this example shows how the SSM parameter value is stored in JSON in the clear. "Environment": { "Variables": { ......
Read more >Troubleshooting Parameter Store - AWS Systems Manager
Problem : You just ran a command to create an aws:ec2:image parameter and a version number was reported, but the parameter isn't available....
Read more >Variables - Serverless Framework
Reference Variables using the SSM Parameter Store. You can reference SSM Parameters as the source of your variables with the ssm:/path/to/param syntax. For ......
Read more >Resource: aws_ssm_parameter - hashicorp - Terraform Registry
Valid values: text , aws:ssm:integration and aws:ec2:image for AMI format, ... If not specified, will use the default parameter tier for the region....
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Thanks for sharing @NeilJ247 🙇 So there are two workarounds at this time:
params
and use${sls:stage}
to dynamically define SSM keys based on stagenull
values for the params e.g.While the proposal to not resolve them is definitely reasonable, it would highly complicate the internal logic that resolves variables.
Yes, in your specific case you would have to reengineer the SSM setup so setting to null might be the best choice for you.