I've try to recreate cloudfront stack with lambda.
got an error:
The function execution role must be assumable with edgelambda.amazonaws.com as well as lambda.amazonaws.com principals. Update the IAM role and try again
However the principal is assumed:
Does generated cloudformation output of two set of "assumedRole" actions
is correct?
The code seems working for me, the change that was made is that I deleted local cdk.out.
Cured by deploying the same stack with the another name.
Related
I am receiving the following errors in the EC2 CloudWatch Agent logs, /var/logs/awslogs.log:
I verified the EC2 has a role:
And the role has the correct policies:
I have set the correct region in /etc/awslogs/awscli.conf:
I noticed that running aws configure list in the EC2 gives this:
Is this incorrect? Should it list the profile (EC2_Cloudwatch_Profile) there?
I was using terraform and reprovisioning by doing:
terraform destroy && terraform apply
Looks like due to IAM being a global service it is "eventually consistent" and not "immediately consistent", when the profile instance was destroyed, the terraform apply began too quickly. Despite the "destroy" being complete, the arn for the previous profile instance was still there, and was re-used. However, the ID changed to a new ID.
Replacing the EC2 would bring it up to speed with the correct ID. However, my solution is to just wait longer between terraform destroy and apply.
I'm getting this error while modifying the stack change
API: iam:PutRolePolicy User: arn:aws:sts::769558805:assumed-role/AWS-QuickSetup-StackSet-Local-AdministrationRole/AWSCloudFormation is not authorized to perform: iam:PutRolePolicy on resource: role test-eu-west-1-lambdaRole because no identity-based policy allows the iam:PutRolePolicy action
Previously, I also updated the same using the Designer, however, everything went smoothly without any errors. The error only appeared this time. Does anyone know what may be the cause is?
Questions:
Where should I put this iam:PutRolePolicy policy? In JSON template or attach it to the AWS-QuickSetup-StackSet-Local-AdministrationRole/AWSCloudFormation in IAM > Policy?
Okay, so my stack has these events:
LogGroup
LambdaFunction
EventsRuleSchedule1
LambdaPermissionEventsRuleSchedule1
which require these rules in policy:
EventBridge
IAM
Lambda
S3
S3 Object Lambda
After several steps of creating change sets, receiving errors, and fixing them, I finally made it work. So the solution here was to check the error line by line, type by type, then adjust the policy accordingly.
However, this is still a bit time-consuming as I needed to test and run the stack every time I added a new policy. Not sure if there is a way to know all these "required" policies before executing stacks, if anyone knows any references, please comment below.
I am trying to set up a CDK Codepipeline for updating the cdk project itself, with the project being under one stack, and having multiple nested stacks in the constructor. The pipeline is in a second stack with the service stack passed in to access the name. I am using CloudFormationCreateUpdateStackAction to update the stack after I have run cdk synth and put the output in an artifact using codebuild.
pipeline.addStage({
stageName: 'ServiceUpdate',
actions: [
new CloudFormationCreateUpdateStackAction({
actionName: 'Service_Update',
stackName: props.serviceStack.stackName,
templatePath: cdkPipelineBuildOutput.atPath(
`${props.serviceStack.stackName}.template.json`
),
adminPermissions: true,
}),
],
});
This is able to update the stack if it is empty, or has some resources directly in it, however if there is a nested stack inside the service stack I get
S3: AccessDenied
for each of the nested stacks inside of the stack.
If I run "cdk deploy ExampleServiceStackName" from my terminal with admin credentials the nested stacks are created/updated correctly, leading me to believe that there is something wrong with the IAM roles of codebuild or codepipeline here. But I don't know where to start as I have set adminPermissions to true in the CloudFormationCreateUpdateStackAction.
I also manually set admin permissions by calling addToDeploymentRolePolicy on the CloudFormationCreateUpdateStackAction, and CodePipeline, passing
const policy = new PolicyStatement({
resources: ['*'],
actions: ['*'],
effect: Effect.ALLOW,
});
with no change in the access denied error.
I also make sure to specify "cdk synth --all" in my ci script in an attempt to ensure the nested stacks templates will be synthesized.
Other stack overflow questions I have read:
S3 error: Access Denied when deploying CFN template with Nested Stacks
This Q was related to a typo in the manually written cloud formation template. I have looked in the generated templates, and the nested stack name is correctly generated and referenced by cdk. cdk deploy from local terminal also works, further leading me to believe there is no typo problem. I also pass the service stack as a prop and call the stackName property to avoid a typo in accessing the template.
If you spot a way there could be a problem accessing due to a typo, please let me know as that would still be the best-case scenario.
Codepipeline S3 Bucket access denied in Codebuild
This Q says it was solved by giving permissions to the CMK on the S3 bucket. I have used a code pipeline Artifact for source of the "cdk synth -> cloudformation templates". I'm not aware of any KMS CMK being used in this setup. If there is a way I can specify decryption abilities on the artifact maybe that would help.
If there is a way to get more verbose error messages about the s3: Access Denied status that would also be appreciated. It doesn't even share what s3 bucket is being denied, I'm just having to assume.
Thanks for any suggestions.
I am following these instructions in order to send our EKS cluster logs to CloudWatch:
https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Container-Insights-setup-logs.html
Since it wasn't working I ran the suggested to command to tail the logs for one of the fluentd pods:
kubectl logs fluentd-cloudwatch-fc7vx -n amazon-cloudwatch
I am seeing this error:
error_class=Aws::CloudWatchLogs::Errors::AccessDeniedException
error="User:
arn:aws:sts::913xxxxx71:assumed-role/eksctl-prod-nodegroup-standard-wo-NodeInstanceRole-1ESBFXHSI966X/i-0937e3xxxx07ea6
is not authorized to perform: logs:DescribeLogGroups on resource:
arn:aws:logs:us-west-2:913617820371:log-group::log-stream:"
I have a role that has the right permissions, but how can I give the role to the arn:aws:sts::913xxxxx71:assumed-role/eksctl-prod-nodegroup-standard-wo-NodeInstanceRole-1ESBFXHSI966X/i-0937e3xxxx07ea6 user?
You need to perform step to attach the CloudWatchAgentServerPolicy policy to cluster worker node role documented here: https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Container-Insights-prerequisites.html
To do this, you need to assume the role. This can be done a few different ways:
You can setup an AWS profile and use that to execute commands as a different role.
You can use a tool like awsudo
One caveat is the the role you are assuming must have a trust relationship setup so that is permits others to assume it. There is an example of this trust relationship setup in the link for (1) above.
That being said, you probably shouldn't be doing any of this for your use case.
If your other role is in a state where it needs to be updated to allow assumption, it is going to be much easier and more secure for you to just update the eksctl-prod-nodegroup-standard-wo-NodeInstanceRole-1ESBFXHSI966X role directly with the permissions you need.
Ideally you can associate the role with the same policy that is attached to the other role with the desired permissions.
So, I am creating a pipeline and when I go to add a deploy stage to create a stack with CloudFormation, I get this error when I try to attach a role name:
"The role name is invalid. Check that the specified role exists and can be assumed by AWS CloudFormation."
The role exists, and I have gone into "Trust Relationship" and made CodePipeline a trusted entity. I am using the ARN as the role name. Any help would be much appreciated. Thanks!
In the "Trust Relationship" it is actually CloudFormation that needs to be the trusted entity, not CodePipeline.