When I open the customer managed keys in region eu-central-1, I can see one key, but I get the following error message:
DescribeKey request failed AccessDeniedException - User:
arn:aws:iam::<MY_ACCOUNT>:user/admin is not authorized to perform:
kms:DescribeKey on resource:
arn:aws:kms:eu-central-1:<MY_ACCOUNT>:key/<MY_KEY_ID>
because no resource-based policy allows the kms:DescribeKey action
This happens, even though I try as root or admin user who does have the permission DescribeKey.
Even using AWS CLI, I cannot do anything about this key.
This leads to the strange situation that I can see the key, but I cannot do anything about it, not even deleting it or getting any details about it. And I also cannot see how I can modify the resource-based policy of that key.
Any help is appreciated!
Okay, I actually found a solution. I tried to log in the name of all of my users and one of the users was actually the one having all permissions according to the resource based policy and could delete it.
Still, a bit surprising to me that root user wasn't able to do so, but I am happy to have solved it.
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.
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.
I am getting following error, when I try to access IAM dashboard on aws.
User: arn:aws:iam::9490xxxxxxxx:user/xyz is not authorized to perform: iam:ListUsers on resource: arn:aws:iam::9490xsxxxxxxx:user/
The fact is that, I have IAMFullPermission policy attached to my account, as shown below :-
I don't know, still what permissions I need to provide.
Thanks in advance.
As Rajesh commented, logging into the console and opening the policy simulator will allow you to select your user, and the iam:ListUsers permission and simulate the evaluation to find the exact reason for the failure.
https://policysim.aws.amazon.com/home/index.jsp?#users
That screenshot of attached policies will give that user/role access to iam:ListUsers from multiple built in AWS polcies, and that error message suggests that the user does not have permission (i.e. a missing allow policy rather than an explicit deny).
When determining the cause of IAM errors I try the following:
Does the response appear cached? (Making changes to allow an action and then immediately attempting again does not always work. You can test this with the CLI by calling an API that will be not allowed. The first call will be slightly slower than subsequent calls. IAM changes can also take time to propagate).
What does the policy simulator say? (especially useful when considering more complicated policies with conditions like MFA required or MFA age)
The Policy Simulator will narrow down scenarios like:
User does not actually have that policy attached
User is part of a group that has an explicit deny policy (doesn't look to be the case here)
Other conditions are not satisfied that are not immediately apparent. E.g. MFA required or resource restrictions to only allow access to manage own user details.
Hi I've followed this instruction try to resize image with Cloudfront and lambda#edge. When I tried to test the resized image, I keep getting the error message below:
The Lambda function associated with the CloudFront distribution is
invalid or doesn't have the required permissions.
So I checked the lambda functions created by cloud formation provided by the article I mentioned in the beginning, and I found there's no trigger in it.
I've tried to set it manually but getting the error message below:
CloudFront events cannot be associated with $LATEST or Alias. Choose
Actions to publish a new version of your function, and then retry
association.
I followed the instruction in the error message; publish, and add Cloudfront as trigger but it seems there's no way to apply it. It's still running the one without Cloudfront as the trigger.
Is there any way to set Cloudfront as trigger and make this work properly?
For people Googling "The Lambda function associated with the CloudFront distribution is invalid or doesn't have the required permissions":
I got that error and struggled to debug it. It turned out there were some programmatic errors inside my Lambda that I had to resolve. But, how do you debug it if, when hitting Cloudfront you keep getting "The Lambda function associated with the CloudFront distribution is invalid or doesn't have the required permissions". That, and there's nothing inside the Cloudwatch logs.
My Lambda was defined in Cloudformation inside a AWS::Lambda::Function's ZipFile attribute. I ended up going to the Lambda service inside AWS and creating a Lambda test payload corresponding to my Cloudfront event as documented here: Lambda#Edge Event Structure. Then, I could debug the Lambda inside the Lambda console without having to hit Cloudfront or having to navigate to Cloudwatch logs.
I see a couple of you guys stating that the root cause of the issue was not a permissions issue and an issue with your code. Which is likely the correct root cause. Cloud front tends to use a 403 error for everything even a basic 404 will show up as a 403 in most cases.
I have also seen some of the comments above stating that you could not find any logs associated with the error in lambda. I think this is most likely because you guys are looking for the logs on us-east-1 and dont live on the east coast of the USA. The logs will be in your local region where they are executed. So choose the region in closest proximity to where you are sitting and you will likely find the log group there.
For other ppl suffering from the poor quality of dev articles from aws blog; I found it's due to the wrong S3 bucket policy. The article says:
ImageBucketPolicy:
Type: AWS::S3::BucketPolicy
Properties:
Bucket: !Ref ImageBucket
PolicyDocument:
Statement:
- Action:
- s3:GetObject
Effect: Allow
Principal: "*"
Resource: !Sub arn:aws:s3:::${ImageBucket}/*
- Action:
- s3:PutObject
Effect: Allow
Principal:
AWS: !GetAtt EdgeLambdaRole.Arn
Resource: !Sub arn:aws:s3:::${ImageBucket}/*
- Action:
- s3:GetObject
Effect: Allow
Principal:
AWS: !GetAtt EdgeLambdaRole.Arn
Resource: !Sub arn:aws:s3:::${ImageBucket}/*
It turns out you have to grant the permissions to allow other actions besides of GetObject and PutObject, because it needs to create folders in the bucket.
Simply the problem is resolved by changing it to s3:*
For me, the missing cloud front trigger on the lambda screen was because I was not in us-east-1 region
I ran into the same error message with no log in CloudWatch. I finally noticed that my Python runtime handler was index.handler while my index.py defined lambda_handler. After changing my Python runtime handler to index.lambda_handler, the error went away. HTH.
If you found this answer googling "The Lambda function associated with the CloudFront distribution is invalid or doesn't have the required permissions", this can be caused if your function is not wired correctly from cloudformation. For example given yaml:
Code: ./src/ # or CodeUri ./src/
Handler: foo.bar
Double check that ./src/foo.js has exports.bar = function...
When I changed "Include body" in Lambda Function Trigger from "Yes" to "No" it started working.
I had to delete and create CloudFront trigger again to change that setting.
just reading an article from here.
If you create a lambda in one region and use it with cloudfront (and later be requested by user in other edge-region), the issue is due to lambda does not have enough cloudwatch log permission.
Check this, all credits go to author.
https://dev.to/aws-builders/authorizing-requests-with-lambdaedge-mjm