Deploy Failed Due to error Value of property Variables must be an object with String (or simple type) properties - node.js

I am getting a serverless error as follow:
An error occurred: CandidateSubmissionLambdaFunction - Value of property Variables must be an object with String (or simple type) properties.
I have tried changing the value to string from a yml file then also I am getting the same error.
My Yml file code is as below:
frameworkVersion: ">=1.1.0 <2.0.0"
provider:
name: aws
runtime: nodejs8.10
stage: dev
region: us-east-1
environment:
CANDIDATE_TABLE: ${self:service}-${opt:stage, self:provider.stage}
CANDIDATE_EMAIL_TABLE: "candidate-email-${opt:stage, self:provider.stage}"
iamRoleStatements:
- Effect: Allow
Action:
- dynamodb:Query
- dynamodb:Scan
- dynamodb:GetItem
- dynamodb:PutItem
Resource: "*"
resources:
Resources:
CandidatesDynamoDbTable:
Type: 'AWS::DynamoDB::Table'
DeletionPolicy: Retain
Properties:
AttributeDefinitions:
-
AttributeName: "id"
AttributeType: "S"
KeySchema:
-
AttributeName: "id"
KeyType: "HASH"
ProvisionedThroughput:
ReadCapacityUnits: 1
WriteCapacityUnits: 1
StreamSpecification:
StreamViewType: "NEW_AND_OLD_IMAGES"
TableName: ${self:provider.environment.CANDIDATE_TABLE}
functions:
candidateSubmission:
handler: api/candidate.submit
memorySize: 128
description: Submit candidate information and starts interview process.
events:
- http:
path: candidates
method: post
Environment Information
OS: linux
Node Version: 8.10.0
Serverless Version: 1.27.3
I want to deploy this on aws and want to perform curd operation.

One of the variables used for value in your YAML configuration might be the wrong type.
${self:service} isn't defined in the YAML but is being referenced in
provider:
environment:
CANDIDATE_TABLE: ${self:service}-${opt:stage, self:provider.stage}

Related

how to reference iam role (created in parent stack) in nested stack

how to reference the iam role (created in the parent stack) in a nested stack
Here are my yml files for the parent and child stack
I used the !Ref and !GetAtt, none of them are working.
Parent Stack:
AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31
Description:
SAM Template for Nested application resources
Resources:
Layer:
Type: AWS::Lambda::LayerVersion
Properties:
CompatibleRuntimes:
- nodejs16.x
Content:
S3Bucket: bucketName
S3Key: Key
Description: My layer
LayerName: lambdaLayer
LicenseInfo: MIT
SourceIAMRole:
Type: AWS::IAM::Role
Properties:
RoleName: source-lambda-iam-omni-agent-role
AssumeRolePolicyDocument:
Version: '2012-10-17'
Statement:
- Sid: ''
Effect: Allow
Principal:
Service: lambda.amazonaws.com
Action: sts:AssumeRole
Policies:
- PolicyName: translate-policy
PolicyDocument:
Version: '2012-10-17'
Statement:
- Effect: Allow
Action:
- comprehend:DetectDominantLanguage
- translate:TranslateText
Resource: '*'
- PolicyName: invokeLambda-sns-sqs-sm-policy
PolicyDocument:
Version: '2012-10-17'
Statement:
- Effect: Allow
Action:
- lambda:InvokeAsync
- lambda:InvokeFunction
- sns:Publish
- iam:ListRoles
- iam:GetRole
- secretsmanager:GetSecretValue
- secretsmanager:ListSecrets
- secretsmanager:UpdateSecret
- sqs:*
Resource: '*'
- PolicyName: sts-policy
PolicyDocument:
Version: '2012-10-17'
Statement:
- Effect: Allow
Action:
- sts:AssumeRole
Resource: '*'
- PolicyName: write-cloudwatch-logs-policy
PolicyDocument:
Version: '2012-10-17'
Statement:
- Effect: Allow
Action:
- logs:CreateLogStream
- logs:CreateLogGroup
- logs:PutLogEvents
Resource: '*'
ManagedPolicyArns:
- arn:aws:iam::aws:policy/service-role/AWSLambdaKinesisExecutionRole
- arn:aws:iam::aws:policy/service-role/AWSLambdaVPCAccessExecutionRole
- arn:aws:iam::aws:policy/AmazonS3FullAccess
- arn:aws:iam::aws:policy/AmazonAPIGatewayInvokeFullAccess
- arn:aws:iam::aws:policy/AmazonDynamoDBFullAccess
- arn:aws:iam::aws:policy/AmazonConnect_FullAccess
config:
Type: AWS::Serverless::Application
Properties:
Location: customerconfig.yml
Parameters:
LayerARN: !Ref Layer
IAMRole: !Ref SourceIAMRole
DependsOn:
- Layer
- SourceIAMRole
I did pass the IAM role to the nested stack in the parameter as you can see above in the parent stack. Now I need to pass the ARN created in the parent stack to child (nested) stack
Child stack (Nested)
AWSTemplateFormatVersion: 2010-09-09
Description:
Start from scratch starter project
Transform: AWS::Serverless-2016-10-31
Globals:
Function:
Runtime: nodejs16.x
Timeout: 15
CodeUri: ./
VpcConfig:
SecurityGroupIds:
- sg-005941cb59bd3c74e
SubnetIds:
- subnet-083b8c9bc31cefb69
- subnet-0f77f5b03c7fc1bc7
Layers:
- !Ref LayerARN
MemorySize: 128
Parameters:
LayerARN:
Type: String
IAMRole:
Type: String
Resources:
helloFromLambdaFunction:
Type: AWS::Serverless::Function
Properties:
Role: !GetAtt IAMRole.Arn
Handler: api/getapplicationconfig.handler
Description: A Lambda function that returns a static string.
I did manage to make it work,
While passing the parameters to nested stack, for the IAM role we will use
!GetAtt SourceIAMRole.Arn.
config:
Type: AWS::Serverless::Application
Properties:
Location: customerconfig.yml
Parameters:
LayerARN: !Ref Layer
IAMRole: !GetAtt SourceIAMRole.Arn

Serverless invoke error: "is not authorized to perform: dynamodb:BatchWriteItem on resource: arn:aws:..."

I have this iamRoleStatements on my serverless.yml, which should allow those actions to my lambda functions:
- Effect: Allow
Action:
- dynamodb:Query
- dynamodb:Scan
- dynamodb:GetItem
- dynamodb:PutItem
- dynamodb:UpdateItem
- dynamodb:DeleteItem
- dynamodb:BatchWriteItem
- dynamodb:BatchReadItem
Resource: "arn:aws:dynamodb:${self:provider.region}:*:table/${self:custom.tableName}"
And this my lambda yml:
functions:
scraping:
handler: handler.scraping
memorySize: 1536
layers:
- !Sub 'arn:aws:lambda:${AWS::Region}:764866452798:layer:chrome-aws-lambda:22'
timeout: 15
events:
- schedule:
rate: ${self:custom.scheduleRate}
name: schedule-scraping-${self:provider.stage}
description: scraping each 5 minute
enabled: ${self:custom.enabled}
In my handle function, I try to insert an item, but I'm getting this error:
AccessDeniedException: User: arn:aws:sts::006977245882:assumed-role/BestSellers-qa-us-east-1-lambdaRole/BestSellers-qa-scraping is not authorized to perform: dynamodb:BatchWriteItem on resource: arn:aws:dynamodb:us-east-1:006977245882:table/TABLE_NAME
at Request.extractError (/var/runtime/node_modules/aws-sdk/lib/protocol/json.js:52:27)
at Request.callListeners (/var/runtime/node_modules/aws-sdk/lib/sequential_executor.js:106:20) ...
Unless you've edited/redacted TABLE_NAME in the error message, my guess is that you're inadvertently attempting to write to a table which probably doesn't exist (TABLE_NAME).
You haven't posted your handler code, but I'd check your code and verify that your actual table name is being set/interpolated correctly before your handler code attempts to insert an item with the DynamoDB API.

serverless step function state machine not created on sls deploy

I am trying to setup a step function in my serverless application but when I deploy the application to aws the state machine is not created for the step functions. Here is my lambda file. I have no idea what I am doing wrong on this but there must be something in my setup that is causing the state machine creation to fail.
service: help-please
provider:
name: aws
versionFunctions: false
runtime: nodejs12.x
vpc:
securityGroupIds:
- sg
subnetIds:
- subnet
- subnet
stage: dev
region: us-west-2
iamRoleStatements:
- Effect: 'Allow'
Action:
- 'xray:PutTraceSegments'
- 'xray:PutTelemetryRecords'
- 'sns:*'
- 'states:*'
Resource: '*'
functions:
upsertNewCustomerRecord:
handler: .build/handler.upsertNewCustomerRecord
iamRoleStatements:
- Effect: 'Allow'
Action:
- logs:CreateLogGroup
- logs:CreateLogStream
- logs:PutLogEvents
- logs:DescribeLogGroups
- ec2:CreateNetworkInterface
- ec2:DescribeNetworkInterfaces
- ec2:DeleteNetworkInterface
- cognito-idp:AdminInitiateAuth
- ccognito-idp:DescribeUserPool
- cognito-idp:DescribeUserPoolClient
- cognito-idp:ListUserPoolClients
- cognito-idp:ListUserPools
- 'xray:PutTraceSegments'
- 'xray:PutTelemetryRecords'
Resource: '*'
sendNewCustomerEmail:
handler: .build/handler.sendNewCustomerEmail
iamRoleStatements:
- Effect: 'Allow'
Action:
- logs:DescribeLogGroups
- logs:CreateLogGroup
- logs:CreateLogStream
- logs:PutLogEvents
- ec2:CreateNetworkInterface
- ec2:DescribeNetworkInterfaces
- ec2:DeleteNetworkInterface
- cognito-idp:AdminInitiateAuth
- ccognito-idp:DescribeUserPool
- cognito-idp:DescribeUserPoolClient
- cognito-idp:ListUserPoolClients
- cognito-idp:ListUserPools
- 'xray:PutTraceSegments'
- 'xray:PutTelemetryRecords'
Resource: '*'
upsertCognitoUser:
handler: .build/handler.upsertCognitoUser
iamRoleStatements:
- Effect: 'Allow'
Action:
- logs:CreateLogGroup
- logs:CreateLogStream
- logs:PutLogEvents
- logs:DescribeLogGroups
- ec2:CreateNetworkInterface
- ec2:DescribeNetworkInterfaces
- ec2:DeleteNetworkInterface
- cognito-idp:AdminInitiateAuth
- ccognito-idp:DescribeUserPool
- cognito-idp:DescribeUserPoolClient
- cognito-idp:ListUserPoolClients
- cognito-idp:ListUserPools
- 'xray:PutTraceSegments'
- 'xray:PutTelemetryRecords'
Resource: '*'
stepFunctions:
stateMachines:
signupstepfunc:
definition:
Comment: 'Sign up step function'
StartAt: UpsertNewCustomerRecord
States:
UpsertNewCustomerRecord:
Type: Task
Resource: 'arn'
Next: SendNewCustomerEmail
SendNewCustomerEmail:
Type: Task
Resource: 'arn'
Next: UpsertCognitoUser
UpsertCognitoUser:
Type: Task
Resource: 'arn'
End: true
plugins:
- serverless-plugin-typescript
- serverless-offline
- serverless-iam-roles-per-function
- serverless-plugin-tracing
- serverless-step-functions
- serverless-pseudo-parameters
- serverless-prune-plugin
Going by the yaml file provided, I think the issue might be the indentation on your function definition:
functions:
upsertNewCustomerRecord:
handler: .build/handler.upsertNewCustomerRecord
iamRoleStatements:
Must be replaced by this:
functions:
upsertNewCustomerRecord:
handler: .build/handler.upsertNewCustomerRecord
iamRoleStatements:
Can you make this change and try once?
Well unfortunately I figured out that I fat fingered a back slash in my buildspec file and that's what caused this to occur be wary of doing this because when deploying using serverless your build won't fail you'll have to dig into every file just to figure out what's going on. Just something to keep in mind.
In my case, i simply forgot to put End: true at the last stage of the step functions. Maybe this will help.

Lambda#edge not triggered by an origin-request event

I'm trying to configure Lambda#edge functions using CloudFormation. After deploying the template everything looks find in the console, however the lambda functions listening to origin-request events are not being triggered.
Strange enough, a viewer-request event does manage to trigger a function.
What am I doing wrong? How can I make the origin-request event to work?
Here's my template:
AWSTemplateFormatVersion: "2010-09-09"
Transform: AWS::Serverless-2016-10-31
Description: Deployment of Lambda#edge functions
Parameters:
Stage:
Type: String
AllowedValues:
- staging
- production
Default: staging
Description: Stage that can be added to resource names
CodeBucket:
Type: String
Description: The S3 Bucket name for latest code upload
CodeKey:
Type: String
Description: The S3 Key for latest code upload
# Mappings:
# AliasMap:
# staging:
# Alias: "staging-app.achrafsouk.com"
# production:
# Alias: "app.achrafsouk.com"
Resources:
CFDistribution:
Type: AWS::CloudFront::Distribution
Properties:
DistributionConfig:
Enabled: true
Logging:
Bucket: XXX.s3.amazonaws.com
IncludeCookies: false
Prefix: !Sub ${Stage}
PriceClass: PriceClass_100
Comment:
!Sub "Lambda#Edge - ${Stage}"
# Aliases:
# - !FindInMap [AliasMap,
# Ref: Stage, Alias]
Origins:
- CustomOriginConfig:
OriginProtocolPolicy: https-only
DomainName: !Sub "${Stage}.defaultOrigin.example.com"
Id: defaultOrigin
OriginCustomHeaders:
- HeaderName: X-Node-Env
HeaderValue: !Sub "${Stage}"
- CustomOriginConfig:
OriginProtocolPolicy: https-only
DomainName: !Sub "${Stage}.another.example.com"
Id: rateLimitsOrigin
OriginCustomHeaders:
- HeaderName: X-Node-Env
HeaderValue: !Sub "${Stage}"
DefaultCacheBehavior:
ForwardedValues:
Headers:
- CloudFront-Viewer-Country
- X-Request-Host
- User-Agent
QueryString: true
ViewerProtocolPolicy: https-only
TargetOriginId: defaultOrigin
DefaultTTL: 0
MaxTTL: 0
LambdaFunctionAssociations:
# - EventType: viewer-request
# LambdaFunctionARN:
# Ref: ViewerRequestLambdaFunction.Version
- EventType: origin-request
LambdaFunctionARN:
Ref: OriginRequestLambdaFunction.Version
CacheBehaviors:
- ForwardedValues:
Headers:
- CloudFront-Viewer-Country
- X-Request-Host
- User-Agent
QueryString: true
ViewerProtocolPolicy: https-only
DefaultTTL: 60
MaxTTL: 60
TargetOriginId: rateLimitsOrigin
PathPattern: "/rate-limit*"
LambdaFunctionAssociations:
- EventType: origin-request
LambdaFunctionARN:
Ref: GetRateLimitLambdaFunction.Version
# ViewerRequestLambdaFunction:
# Type: AWS::Serverless::Function
# Properties:
# CodeUri:
# Bucket: !Sub ${CodeBucket}
# Key: !Sub ${CodeKey}
# Role: !GetAtt LambdaEdgeFunctionRole.Arn
# Runtime: nodejs10.x
# Handler: src/functions/viewerRequest.handler
# Timeout: 5
# AutoPublishAlias: live
OriginRequestLambdaFunction:
Type: AWS::Serverless::Function
Properties:
CodeUri:
Bucket: !Sub ${CodeBucket}
Key: !Sub ${CodeKey}
Role: !GetAtt LambdaEdgeFunctionRole.Arn
Runtime: nodejs10.x
Handler: src/functions/originRequest.handler
Timeout: 5
AutoPublishAlias: live
GetRateLimitLambdaFunction:
Type: AWS::Serverless::Function
Properties:
CodeUri:
Bucket: !Sub ${CodeBucket}
Key: !Sub ${CodeKey}
Role: !GetAtt LambdaEdgeFunctionRole.Arn
Runtime: nodejs10.x
Handler: src/functions/getRateLimit.handler
Timeout: 5
AutoPublishAlias: live
LambdaEdgeFunctionRole:
Type: "AWS::IAM::Role"
Properties:
Path: "/"
ManagedPolicyArns:
- "arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole"
AssumeRolePolicyDocument:
Version: "2012-10-17"
Statement:
- Sid: "AllowLambdaServiceToAssumeRole"
Effect: "Allow"
Action:
- "sts:AssumeRole"
Principal:
Service:
- "lambda.amazonaws.com"
- "edgelambda.amazonaws.com"
Outputs:
# ViewerRequestLambdaFunctionVersion:
# Value: !Ref ViewerRequestLambdaFunction.Version
OriginRequestLambdaFunctionVersion:
Value: !Ref OriginRequestLambdaFunction.Version
GetRateLimitLambdaFunctionVersion:
Value: !Ref GetRateLimitLambdaFunction.Version
CFDistribution:
Description: Cloudfront Distribution Domain Name
Value: !GetAtt CFDistribution.DomainName
So, after painful hours of trial and error the solution was staring me in the face:
CloudFront distribution was emitting and error saying it could not connect to the origin, and it was right - because I've specified dummy domains in the origins definition of the CloudFront distribution.
My logic was that if my lambda#edge functions intercept the requests before reaching the origin, then it shouldn't matter if the origin's domains is real or not.
As it turns out, it's partially true. Because it seams that:
viewer-request event is triggered before trying to connect to the origin, and there for it can by fake.
origin-request event is triggered only after trying to connect to the origin, so you'd need to specify something real.
Hope my wasited hours will contribute to someone else exploring the same path of reasoning.
In case it helps someone in future with this problem - I noticed that origin-response (which I accidentally selected instead of origin-request) events were (mostly) working for me, but there were still a large number of OriginConnectError in the logs, and the "Percentage of Viewer Requests by Result Type" report was showing a high error rate.
It turns out it was only working at all because I had my origin connection set to https-only, but my origin (an empty s3 bucket) only accepted http connections - and for some reason the events were still being triggered.
Changing the origin connection to the correct http-only completely stopped things working for origin-response, until I also corrected the event type to origin-request
So, in general, check the OriginProtocolPolicy is http-only if you're using an s3 bucket origin. If it's wrong, things might still appear to work sometimes, but not always, and you'll end up with high error rates.

Environment Variables with Serverless and AWS Lambda

I am learning serverless framework and I'm making a simple login system.
Here is my serverless.yml file
service: lms-auth
provider:
name: aws
runtime: nodejs8.10
stage: dev
region: ap-south-1
environment:
MONGODB_URI: $(file(../env.yml):MONOGDB_URI)
JWT_SECRET: $(file(../env.yml):JWT_SECRET)
functions:
register:
handler: handler.register
events:
- http:
path: auth/register/
method: post
cors: true
login:
handler: handler.login
events:
- http:
path: auth/login/
method: post
cors: true
plugins:
- serverless-offline
As you can see, I have two environment variables and both of them are referencing to a different file in the same root folder.
Here is that env.yml file
MONOGDB_URI: <MY_MONGO_DB_URI>
JWT_SECRET: LmS_JWt_secREt_auth_PasSWoRds
When I do sls deploy, I see that both the variables are logging as null. The environment variables aren't sent to lambda.
How can I fix this?
Also, currently I'm using this method and adding the env.yml to .gitignore and saving the values. Is there any other efficient way of hiding sensitive data?
I would do something like this to help you out with the syntax
service: lms-auth
custom: ${file(env.yml)}
provider:
name: aws
runtime: nodejs8.10
stage: dev
region: ap-south-1
environment:
MONGODB_URI: ${self:custom.mongodb_uri}
JWT_SECRET: ${self:custom.jwt_secret}
functions:
register:
handler: handler.register
events:
- http:
path: auth/register/
method: post
cors: true
login:
handler: handler.login
events:
- http:
path: auth/login/
method: post
cors: true
plugins:
- serverless-offline
Then in your env.yml you can do
mongodb_uri: MY_MONGO_DB_URI
jwt_secret: LmS_JWt_secREt_auth_PasSWoRds
Enviroment variables
1. Add useDotenv:true to your .yml file 2.Add your variables like this -> ${env:VARIABLE_NAME}3.Create a file called .env.dev and write the variables (You can add .env.prod but you have to change the stage inside your .yml file ) Example :
service: lms-auth
useDotenv: true
provider:
name: aws
runtime: nodejs12.x
stage: dev
region: us-east-1
environment:
MONGODB_URI: ${env:MONOGDB_URI}
JWT_SECRET: ${env:JWT_SECRET}
functions:
register:
handler: handler.register
events:
- http:
path: auth/register/
method: post
cors: true
login:
handler: handler.login
events:
- http:
path: auth/login/
method: post
cors: true
plugins:
- serverless-offline
.env.dev
MONOGDB_URI = The URI Value
JWT_SECRET = The JWT Scret Value
I ended up solving it. I had set up my Dynamo DB in AWS us-west region. reinitialized in US-East-2, and reset the region under 'provider' within the .yml file.

Resources