- Newest
- Most votes
- Most comments
Being a root user doesn't bypass the need for proper service-to-service permissions in AWS. Even as root, you still need:
- The Lambda function to trust EventBridge (resource-based policy)
- EventBridge to have permission to invoke Lambda
Try this as root:
# Check if the Lambda has a resource-based policy aws lambda get-policy --function-name processor --region eu-north-1 # If found, remove it: aws lambda remove-permission --function-name processor --statement-id <id> --region eu-north-1 # Then grant fresh permission: aws lambda add-permission \ --function-name processor \ --action lambda:InvokeFunction \ --principal events.amazonaws.com \ --statement-id EventBridgeInvoke \ --region eu-north-1
This is because AWS service-to-service permissions work through explicit trust relationships, regardless of the user making the request - even root. It's a security feature, not a bug.
If you're still getting denied after this, there might be a service issue and AWS Support would be the next step.
The situation you're experiencing is unusual and not expected behavior for a root user, who typically has full access to all AWS services and operations. However, there are a few things to consider and potential steps to resolve this issue:
-
Even as a root user, you may encounter issues if there are service-linked roles or resource-based policies involved that are causing conflicts.
-
The error message "Unable to determine service/operation name to be authorized" suggests there might be an issue with the AWS service trying to determine the correct permissions for the operation.
-
Deleting the EventBridge rule from the EventBridge console was a good step. However, the Lambda function is still showing the non-existent trigger because the association wasn't properly removed.
To resolve this issue, try the following steps:
-
Refresh the Lambda console page to see if the trigger disappears on its own after some time.
-
If the trigger still appears, try updating the Lambda function configuration (e.g., change a setting and save it) to force a refresh of the function's metadata.
-
If the issue persists, you may need to use the AWS CLI or AWS SDK to remove the event source mapping. You can list the event source mappings for your function and then delete the specific mapping for the deleted EventBridge rule.
-
As a last resort, you could consider recreating the EventBridge rule, re-associating it with the Lambda function, and then properly removing it through the Lambda console.
If none of these steps work, it would be advisable to contact AWS Support, as this behavior is not normal for a root user and may indicate a deeper issue with your account or the AWS services in your region.
Remember that it's generally recommended to use IAM users with appropriate permissions rather than the root user for day-to-day operations, even for administrative tasks. This allows for better security control and auditing of actions taken on your AWS account.
Sources
See who invoked my Lambda function | AWS re:Post
Disabling or deleting a rule in Amazon EventBridge - Amazon EventBridge
Logging Amazon EventBridge API calls using AWS CloudTrail - Amazon EventBridge
Relevant content
- asked 2 years ago
- asked a year ago
- AWS OFFICIALUpdated a month ago
Thanks, it worked, the trigger is gone. The reason I asked this question is that I have other lambdas where I can add/remove triggers just fine, but I had the problem with this particular lambda. Maybe the reason of the issue is that other lambdas are created by root, and that one was created by the deployer. I don't know.