I'm trying to implement aws secrets rotation with with the serverless framework (https://alexharv074.github.io/2020/11/23/adding-hosted-rotation-lambda-to-a-database-stack.html)
AppGraphqDbAppsSecretRotationSchedule:
Type: AWS::SecretsManager::RotationSchedule
Properties:
SecretId: !Ref AppGraphqlDbAppsSecretsManagerSecret
HostedRotationLambda:
RotationType: PostgreSQLSingleUser
RotationRules:
AutomaticallyAfterDays: 30
I get the error
To use the HostedRotationLambda property, you must use the AWS::SecretsManager transform.
How can I add "transform"? Below a working Aws cloudformation template
AWSTemplateFormatVersion: 2010-09-09
Description: Rotation Lambda example stack
Transform: AWS::SecretsManager-2020-07-23
Parameters: {}
Resources:
I am trying to authenticate Queries playground in AWS AppSync console. I have created User Pool and linked it to the AppSync API, I have also created an App Client in Cognito User Pool (deployed using CloudFormation). It appears under Select the authorization provider to use for running queries on this page: in the console.
When I run test query I get:
{
"errors": [
{
"errorType": "UnauthorizedException",
"message": "Unable to parse JWT token."
}
]
}
This is what I would expect. There is an option to Login with User Pools. The issue is I can't select any Client ID and when I choose to insert Client ID manually, anything I enter I get Invalid UserPoolId format. I am trying to copy Pool ID from User Pool General settings (format eu-west-2_xxxxxxxxx) but no joy. Btw, I am not using Amplify and I have not configured any Identity Pools.
EDIT:
Here is the CloudFormation GraphQLApi definition:
MyApi:
Type: AWS::AppSync::GraphQLApi
Properties:
Name: !Sub "${AWS::StackName}-api"
AuthenticationType: AMAZON_COGNITO_USER_POOLS
UserPoolConfig:
UserPoolId: !Ref UserPoolClient
AwsRegion: !Sub ${AWS::Region}
DefaultAction: ALLOW
To set up the stack using CloudFormation I have followed these 2 examples:
https://adrianhall.github.io/cloud/2018/04/17/deploy-an-aws-appsync-graphql-api-with-cloudformation/
https://gist.github.com/adrianhall/f330a10451f05a529680f32978dddb64
Turns out they both (same author) have an issue in them in the section where ApiGraphQL is defined. This:
MyApi:
Type: AWS::AppSync::GraphQLApi
Properties:
Name: !Sub "${AWS::StackName}-api"
AuthenticationType: AMAZON_COGNITO_USER_POOLS
UserPoolConfig:
UserPoolId: !Ref UserPoolClient
AwsRegion: !Sub ${AWS::Region}
DefaultAction: ALLOW
Should be:
MyApi:
Type: AWS::AppSync::GraphQLApi
Properties:
Name: !Sub "${AWS::StackName}-api"
AuthenticationType: AMAZON_COGNITO_USER_POOLS
UserPoolConfig:
UserPoolId: !Ref UserPool
AwsRegion: !Sub ${AWS::Region}
DefaultAction: ALLOW
Thank you #Myz for pointing me back to review the whole CF yaml file
I want to have a CloudFront distribution with access to a private S3 bucket. For that, I have to create an origin access identity. Manually, I can do that using the AWS console, but I wanted to create it via a CloudFormation script or with Serverless (using serverless.yml). While doing this, I am able to add a physical Id of the origin access identity to my CloudFront distribution (using one script).
Relevant documentation: https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/quickref-cloudfront.html
I tried this:
myDistribution:
Type: AWS::CloudFront::Distribution
Properties:
DistributionConfig:
Origins:
- DomainName:bucket.s3.amazonaws.com
Id: myS3Origin
S3OriginConfig: {
OriginAccessIdentity:origin-access-identity/cloudfront/ !Ref cloudfrontoriginaccessidentity
}
Enabled: 'true'
Comment: Some comment
DefaultCacheBehavior:
ForwardedValues:
QueryString: 'false'
Cookies:
Forward: none
AllowedMethods:
- GET
- HEAD
- OPTIONS
TargetOriginId: myS3Origin
ViewerProtocolPolicy: redirect-to-https
PriceClass: PriceClass_200
ViewerCertificate:
CloudFrontDefaultCertificate: 'true'
cloudfrontoriginaccessidentity:
Type: AWS::CloudFront::CloudFrontOriginAccessIdentity
Properties:
CloudFrontOriginAccessIdentityConfig:
Comment: "some comment"
I have to create an origin access identity and a CloudFront distribution having this identity. Can we do both of these things in one CloudFormation script or with Serverless (using serverless.yml)?
You definitely can create an origin access identity and the CloudFront distribution in the same serverless.yml.
I've modified your scenario and changed the OriginAccessIdentity to use Fn::Join.
myDistribution:
Type: AWS::CloudFront::Distribution
Properties:
DistributionConfig:
Origins:
- DomainName:bucket.s3.amazonaws.com
Id: myS3Origin
S3OriginConfig:
OriginAccessIdentity:
Fn::Join:
- ''
-
- 'origin-access-identity/cloudfront/'
- Ref: cloudfrontoriginaccessidentity
Enabled: 'true'
Comment: Some comment
DefaultCacheBehavior:
ForwardedValues:
QueryString: 'false'
Cookies:
Forward: none
AllowedMethods:
- GET
- HEAD
- OPTIONS
TargetOriginId: myS3Origin
ViewerProtocolPolicy: redirect-to-https
PriceClass: PriceClass_200
ViewerCertificate:
CloudFrontDefaultCertificate: 'true'
cloudfrontoriginaccessidentity:
Type: AWS::CloudFront::CloudFrontOriginAccessIdentity
Properties:
CloudFrontOriginAccessIdentityConfig:
Comment: "some comment"
The serverless examples repo has a great example of this too: https://github.com/serverless/examples/blob/master/aws-node-single-page-app-via-cloudfront/serverless.yml
Yes, you can create both in the same CloudFormation template. The cloudfrontoriginaccessidentity is a separate resource so needs to be moved out from underneath myDistribution.
myDistribution:
Type: AWS::CloudFront::Distribution
Properties:
DistributionConfig:
Origins:
- DomainName:bucket.s3.amazonaws.com
Id: myS3Origin
S3OriginConfig: {
OriginAccessIdentity:origin-access-identity/cloudfront/ !Ref cloudfrontoriginaccessidentity
}
Enabled: 'true'
Comment: Some comment
DefaultCacheBehavior:
ForwardedValues:
QueryString: 'false'
Cookies:
Forward: none
AllowedMethods:
- GET
- HEAD
- OPTIONS
TargetOriginId: myS3Origin
ViewerProtocolPolicy: redirect-to-https
PriceClass: PriceClass_200
ViewerCertificate:
CloudFrontDefaultCertificate: 'true'
cloudfrontoriginaccessidentity:
Type: AWS::CloudFront::CloudFrontOriginAccessIdentity
Properties:
CloudFrontOriginAccessIdentityConfig:
Comment: "toyoguard-acces-identity"
Dont forget to add the s3 policy and bucket to your dependsOn list
I have two lambda functions defined in serverless.yml: graphql and convertTextToSpeech. The former (in one of the GraphQL endpoints) should write to SNS topic to execute the latter one. Here is my serverless.yml file:
service: hello-world
provider:
name: aws
runtime: nodejs6.10
plugins:
- serverless-offline
functions:
graphql:
handler: dist/app.handler
events:
- http:
path: graphql
method: post
cors: true
convertTextToSpeach:
handler: dist/tasks/convertTextToSpeach.handler
events:
- sns:
topicName: convertTextToSpeach
displayName: Convert text to speach
And GraphQL endpoint writing to SNS:
// ...
const sns = new AWS.SNS()
const params = {
Message: 'Test',
Subject: 'Test SNS from lambda',
TopicArn: 'arn:aws:sns:us-east-1:101972216059:convertTextToSpeach'
}
await sns.publish(params).promise()
// ...
There are two issues here:
Topic ARN (which is required to write to a topic) is hardcoded it. How I can get this in my code "dynamically"? Is it provided somehow by serverless framework?
Even when topic arn is hardcoded lambda functions does not have permissions to wrote to that topic. How I can define such permissions in serverless.yml file?
1) You can resolve the topic dynamically.
This can be done through CloudFormation Intrinsic Functions, which are available within the serverless template (see the added environment section).
functions:
graphql:
handler: handler.hello
environment:
topicARN:
Ref: SNSTopicConvertTextToSpeach
events:
- http:
path: graphql
method: post
cors: true
convertTextToSpeach:
handler: handler.hello
events:
- sns:
topicName: convertTextToSpeach
displayName: Convert text to speach
In this case, the actual topic reference name (generated by the serverless framework) is SNSTopicConvertTextToSpeach. The generation of those names is explained in the serverless docs.
2) Now that the ARN of the topic is mapped into an environment variable, you can access it within the GraphQL lambda through the process variable (process.env.topicARN).
// ...
const sns = new AWS.SNS()
const params = {
Message: 'Test',
Subject: 'Test SNS from lambda',
TopicArn: process.env.topicARN
}
await sns.publish(params).promise()
// ...
I am calling adminInitiateAuth and getting back a strange AccessDeniedException for my own lambdas.
Here is the code I'm calling:
var params = {
AuthFlow: "ADMIN_NO_SRP_AUTH",
ClientId: "#cognito_client_id#",
UserPoolId: "#cognito_pool_id#",
AuthParameters: {
USERNAME : username,
PASSWORD : tempPassword
},
};
cognitoIdentityServiceProvider.adminInitiateAuth(params, function(error, data) {
if (error) {
console.log("ERROR! Login failed: " + JSON.stringify(error), error.stack);
} else {
console.log("Login sent back: " + JSON.stringify(data));
}
});
The error message I'm getting is:
ERROR! Login failed: {"message":"arn:aws:lambda:us-east-1:201473124518:function:main-devryan-users_onCognitoLogin failed with error AccessDeniedException.","code":"UnexpectedLambdaException","time":"2017-02-25T18:54:15.109Z","requestId":"ce42833f-fb8b-11e6-929b-2f78b63faa12","statusCode":400,"retryable":false,"retryDelay":1.0853444458916783} UnexpectedLambdaException: arn:aws:lambda:us-east-1:201473124518:function:main-devryan-users_onCognitoLogin failed with error AccessDeniedException.
Does anybody know why I might be getting this error?
This was happening because I recreated my API Gateway & Lambdas (using serverless) and it turns out that the Cognito console sneakily adds permissions to contact a given Lambda function when added as a trigger through the console.
To fix this in your CloudFormation / serverless.yml file:
resources:
Resources:
OnCognitoSignupPermission:
Type: 'AWS::Lambda::Permission'
Properties:
Action: "lambda:InvokeFunction"
FunctionName:
Fn::GetAtt: [ "UsersUnderscoreonCognitoSignupLambdaFunction", "Arn"]
Principal: "cognito-idp.amazonaws.com"
SourceArn:
Fn::Join: [ "", [ "arn:aws:cognito-idp", ":", Ref: "AWS::Region", ":", Ref: "AWS::AccountId", ":", "userpool/", "#cognito_pool_id#" ] ]
To fix this in the AWS console:
Go to the Cognito Console
Choose your user pool
Go to "Triggers"
Remove your custom trigger (set it to None) and click "Save"
Now reset it back and click "Save" again
Here's an interesting Amazon forum post that led me down the right track.
I had a problem similar to yours except I was trying to configure the Lambda with my Cognito User Pool through CloudFormation.
In the link that Ryan had posted there was a code sample someone posted. Namely Cognito needed the proper permissions to invoke the lambda function.
MyLambdaInvocationPermission:
Type: AWS::Lambda::Permission
Properties:
Action: lambda:InvokeFunction
FunctionName: !GetAtt MyLambdaFunctionName.Arn
Principal: cognito-idp.amazonaws.com
SourceArn: !GetAtt MyCognitoUserPoolName.Arn
For someone ending up here, trying to add cognito triggers via terraform, all you need to do is to add an aws_lambda_permission resource:
resource "aws_lambda_permission" "allow_execution_from_user_pool" {
statement_id = "AllowExecutionFromUserPool"
action = "lambda:InvokeFunction"
function_name = aws_lambda_function.<lambda>.function_name
principal = "cognito-idp.amazonaws.com"
source_arn = aws_cognito_user_pool.<pool>.arn
}
Found in this great post: https://www.integralist.co.uk/posts/cognito/
you can add the permission from the lambda Role (create a policy for cognito and add to to the lamda role ) . this solve my problem when i stuck into it
while creation of cloudformation stack - I got error like
User:arn:aws::12345678:user/xyz is not authorized to perform:
cognito-idp:CreateUserPool on resource:*(Service:AWSCognitoIdentityProviderService;
Status Code: 400; Error Code: AccessDeniedException;Request ID: xxxxx)
workaround :
went on to the Stack which is in Rollback state -> checked events and could see , (creation-failed) some Roles I don't have access ,
So , I checked IAM policy assigned to me - I was not having the access.
I created a new policy and assigned to myself as an Inline Policy by Importing it from AWS.
aws-cognito-idp
"Version": "2012-10-17",
"Statement": [
{
"Sid": "Cognito-IDP",
"Effect": "Allow",
"Action": [
"lambda:InvokeFunction",
"cognito-idp:*"
],
"Resource": "*"
}
]
}
note: you can restrict the access on resource and cognito-idp user.
with this - I am successfully able to create and deploy cloudformation Stack for the module.