Im new on this field and i need some help. There is no log when the rules hit by attack. can anyone help me with this? where i can find kind of log of blocking by rules when attack happened? i've been reading the documentation and still got nothing, i'm so glad if you guys can help me
If you are using Cloud Armor with a load balancer on the stackdriver logs [1] you can see if some policy was applied.
On [2] you can find a log example:
jsonPayload: {
#type: "type.googleapis.com/google.cloud.loadbalancing.type.LoadBalancerLogEntry"
enforcedSecurityPolicy: {
configuredAction: "DENY"
name: "my-policy"
outcome: "DENY"
priority: 50
}
statusDetails: "denied_by_security_policy"
}
On the log you can see the configured action ACCEPT or DENY and the policy name.
Related
Getting this error while trying to connect grafana to cloudwatch in opt-in ap-east-1 region. I'm using access & secret key with Assume Role ARN witch work fine in other regions.
Found similar issue https://github.com/grafana/grafana/issues/48267#issuecomment-1119592852
but setting AWS_STS_REGIONAL_ENDPOINTS=regional env var on grafana server does not help.
May be i'm doing something wrong, please any suggestions.
I am struggling to get a task running using ECS Fargate, and launched (ecs.runTask) from an AWS SDK script (JS/Node).
My current struggle is to get logs from the containers so that I can trouble shoot why they are stopping. I can't seem to get the Task Definition right so that they will be generated.
logConfiguration: {
logDriver: 'awslogs',
options: {
"awslogs-region": 'us-west-2',
"awslogs-group": 'myTask',
"awslogs-stream-prefix": "myTask",
"awslogs-create-group": "true"
}
}
I have set the log driver for them to awslogs, but when I try to view the logs in CloudWatch, I get various kinds of nothing:
If I specify the awslogs-create-group as "true" (it requires a string, rather than a Boolean, which is strange; I assume case doesn't matter), I nevertheless find that the group is not created.
If I create the group manually, I find that the log stream is not created.
I suspect that there may be an error in my permissions, though of course there is no error messaging to confirm. The docs (here) indicate that I need to attach certain policies to ecsInstanceRole, which seems to be a placeholder for a role that is used somewhere in the process.
But I have attached such a policy to my ECS executionRole, to the role that executes my API call to runTask, and I have looked for any other role that might be involved (an actual "instanceRole" doesn't seem to exist in the Task Def), and nothing is improving my situation.
I'd be happy to supply more information, but at this point I'm not sure where my blind spot is.
Can anyone see it?
Go to your Task Definition. You should find a section called "Task execution IAM role". The description says -
This role is required by tasks to pull container images and publish container logs to Amazon CloudWatch.
The role you attach here needs a policy like AmazonECSTaskExecutionRolePolicy (AWS managed policy), and the Trusted Entity is ecs-tasks.amazonaws.com.
Also, the awslogs option awslogs-create-group is not needed, I think.
due to huge costs in our environment, I have a task to create a lambda to tag all log groups like corresponding resources (the source of these log groups). However, I am facing a challenge to identify the resource arn of log groups. There are many logs in our environment like logs for lambda, logs for elastic-beanstalk, logs for ec2. But how can I match the log group with the corresponding resource? I would appreciate any help very much!
I would try using describe-log-groups. To use it you'll need to work your way "backwards" by going from resources to the log-groups, but I can't think of any other way at the moment.
aws logs describe-log-groups --query 'logGroups[*].arn' --log-group-name-prefix '/aws/lambda/[name-of-your-lambda]'
Output:
[
"arn:aws:logs:[region]:[account-id]:log-group:/aws/lambda/[name-of-your-lambda]:*"
]
Hope that helps.
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
Context: I use Amazon AWS, SNS service, to manually send SMS as a trial before I do any integration by code.
I want to log the SMS reponses (the JSONs that appear here: http://docs.aws.amazon.com/sns/latest/dg/sms_stats_cloudwatch.html ) at some place.
Investigation done:
It seems I had to create an IAM role. I did it following the steps in the page, in the section "Viewing CloudWatch Logs". The role has been created. The policy for the role contains the following actions:
"Action": [
"logs:CreateLogGroup",
"logs:CreateLogStream",
"logs:PutLogEvents",
"logs:PutMetricFilter",
"logs:PutRetentionPolicy"
],
I have set the "Default percentage of success to sample" to the 100% so it should log all errors and successes...
And now what? I have sent a couple of SMSs, I go to the Cloudwatch / Logs and all is empty.
Questions:
Where are the logs?
Do I have to do anything else with the IAM to get that logged?
Do I have to do anything in the Cloudwatch section?
Where is it supposed I should be able to see the logs?
I've spent 6+ hours with this and I want to think it is some silly point I'm missing. It can't be so complicated.
The overall question is Where are the SNS/SMS logs and how do I activate them?
I don't know if your AIM configuration is good or wrong, I would need to check your configuration in order to tell you that, but if you want to know where the SNS logs are, in my case I can find them doing:
Go to CloudWatch
From the left menu, select Logs
You will see the list of your logs, search for the name of your SNS, in my case is something like sns/us-west-2/<account-id>/app/APNS/<endpoint-name>
After you click on that name, you will find all your logs
Image attached: