I'm using CDK version 1.139.0, and I had a waf earlier added in my previous deployment.
Now I tried to add the logging configuration for that waf. So I added the below code in cdk and generated the template.
new CfnLoggingConfiguration(scope,'WafLoggingConfig',{
resourceArn:webAcl.attrArn, // here I attached the wabacl using wabacl code reference.
logDestinationConfigs:[arn:aws:logs:${region}:${accountId}:log-group:aws-waf-logs-for-app],
})
Note: I have already created the log group for waf named as aws-waf-logs-for-app (which has the expected prefix need for waf)
After synthesizing/generating the template I did cdk deploy to update the Cloud formation.
List of policies I have already attached to the Cloudformation :
'wafv2:AssociateWebACL',
'wafv2:CreateWebACL',
'wafv2:DeleteWebACL',
'wafv2:DescribeManagedRuleGroup',
'wafv2:DisassociateWebACL',
'wafv2:Get*',
'wafv2:List*',
'wafv2:UpdateWebACL',
'wafv2:GetLoggingConfiguration',
'wafv2:ListLoggingConfiguration',
'wafv2:PutLoggingConfiguration',
'wafv2:DeleteLoggingConfiguration',
'cloudwatch:DeleteAlarms',
'cloudwatch:Describe*',
'cloudwatch:DisableAlarmActions',
'cloudwatch:EnableAlarmActions',
'cloudwatch:GetDashboard',
'cloudwatch:ListDashboards',
'cloudwatch:PutDashboard',
'cloudwatch:DeleteDashboards',
'cloudwatch:GetMetricData',
'cloudwatch:GetMetricStatistics',
'cloudwatch:ListMetrics',
'cloudwatch:PutMetricAlarm',
'cloudwatch:PutMetricData',
and other policies for other resources.
But my cloud formation fails to deploy the logging configuration for waf and displays the below error in Cloudformation events page.
Resource handler returned message: "You don't have the permissions that are required to perform this operation. (Service: Wafv2, Status Code: 400, Request ID: {12474621823782738}, Extended Request ID: null)" (RequestToken: {9732489732849732878973}, HandlerErrorCode: GeneralServiceException)
Note: In the above error I have modified the value of the Request ID: and RequestToken.
I believe I have given the needed policies for the cloud formation.
Is it a bug in cdk ? Did cdk failed to create any role needed for this ? can someone help me with this?
You have wafv2:PutLoggingConfiguration action allowed in your policy but this by itself is not sufficient to allow the action. This is because wafv2:PutLoggingConfiguration has iam:CreateServiceLinkedRole as a dependent action.
References
https://docs.aws.amazon.com/service-authorization/latest/reference/list_awswafv2.html Refer the dependent actions column
https://docs.aws.amazon.com/service-authorization/latest/reference/reference_policies_actions-resources-contextkeys.html
The Dependent actions column includes any additional permissions that you must have, in addition to the permission for the action itself, to successfully call the action. This can be required if the action accesses more than one resource.
Related
I'm trying to create ECS Fargate deployment using Cloudformation script, but the script fails during creation of ECS Cluster with error saying that unable to assume service role. I'm not able to figure out what I'm missing in the script, I have tried many ways none of them seem to be working.
Here is the link to cloud formation script as I'm not able to post it here due to character limitation.
ECS Cloudformation script
the error where the resource creation fails.
Resource handler returned message: "Invalid request provided: CreateCluster Invalid Request: Unable to assume the service linked role. Please verify that the ECS service linked role exists. (Service: AmazonECS; Status Code: 400; Error Code: InvalidParameterException; Request ID: e08ab312-4bd8-4c21-852f-ae5d49cc5932; Proxy: null)" (RequestToken: a686f226-e1d3-7b4c-13f1-66fa0a516c51, HandlerErrorCode: InvalidRequest
I'm able to get it working if I create an ECS cluster from aws console, as it creates a service liked role. But I want to work without creating the cluster manually from Console, enerything building up from Cloudformation. I tried looking over aws docs and did dig up Internet but couldn't get it working.Can anyone please help me out.
I am trying to deploy AWS API Gateway Developer Portal using serverless repo
The Cloud formation fails and triggers rollback of the deployment. The error that causes the failure is as follows:
Logical ID: StaticAssetUploader
Status: CREATE_FAILED
Reason: CloudFormation did not receive a response from your Custom Resource. Please check your logs for requestId [ea5b3458-f29c-4950-b068-d0a3f352ad5f]. If you are using the Python cfn-response module, you may need to update your Lambda function code so that CloudFormation can attach the updated version.
Help is appreciated
I've deployed cognito resources including a custom user pool domain resource using Terraform to AWS. I've made some changes to the configuration of the user pool and when I run terraform apply, the plan shows that the custom domain will need to be updated as well; To be honest, I'm not sure why since I did not make changes to the domain name.
When I attempt to apply the changes, it gives me the following error message:
Error: Error creating Cognito User Pool Domain:
InvalidParameterException: One or more of the CNAMEs you provided are
already associated with a different resource. (Service:
AmazonCloudFront; Status Code: 409; Error Code: CNAMEAlreadyExists;
Request ID: xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxx; Proxy: null)
To me this appears to be due to Terraform attempting to register the exact same CNAME as the user pool custom domain.
I have 2 questions:
Why is it doing that when clearly I didn't change the custom domain in Terraform configurations?
How can I rectify this issue without having to destroy all of my cognito resources and deploying them from scratch?
I am exploring CodeStar using a basic project created with the Python 3.7 Lambda template following the Serverless Project Tutorial in the AWS CodeStar documentation:
https://docs.aws.amazon.com/codestar/latest/userguide/sam-tutorial.html
My build and deploy are successful. However a see a warning in my CloudFormation event log:
The IAM user doesn't allow CloudFormation to call lambda:GetAlias, this could result in formulating a appspec file with stale CurrentVersion for CodeDeploy deployment. Please fix it to avoid any possible CodeDeploy deployment failures.
I am just using the AWS resources created automatically by the CodeStar console.
What do I do to fix this warning?
Details
The CodeDeploy step in the CodePipeline deploys the lambda function by updating a CloudFormation stack named: awscodestar-<codestar project name>-lambda.
When I looked in the event log for this stack, I noticed the above warning for the resource named HelloWorldAliaslive
To fix this, add the lambda:GetAlias permission to the inline policy associated with the IAM role named CodeStarWorker-<project>-CloudFormation
Open the AWS Console for CodeStar
Click Project in the left navbar
Find the Project Resources section. One of the AWS IAM resources will have a name CodeStarWorker-<project>-CloudFormation. Click the link in the ARN column of the table to open the role in IAM.
Locate the inline policy named CodeStarWorkerCloudFormationRolePolicy and click the Edit button.
Add the "lambda:GetAlias" action to this policy.
This policy is created automatically by CodeStar. In my account, the policy included several Statements. I chose to add the "lambda:GetAlias" action to the statement which already had "lambda:CreateAlias" action.
After making this change, the warning no longer appeared in my CloudFormation event logs.
I have a function (Node.js 8.10) in us-west-2 and I am unable to attach the layer arn:aws:lambda:us-east-1:553035198032:layer:git:3. I get the following error message upon save:
You are not authorized to perform: lambda:GetLayerVersion.
I have the AWSLambdaFullAccess managed policy attached to my user, and even the persons with AdministratorAccess get the same error. I also checked in the policy simulator and it specifies that this permission IS allowed to be run by myself and the Administrator users.
Any ideas as to what I might be doing wrong?
REGION MISMATCH
I followed the README here, but failed to notice the region difference, nor the Version ARNs section that implies the package author has created the layer in multiple regions.