Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
AWS: Consolidates Lambda::Permission objects for cloudwatchLog events #5531
What did you implement:
How did you implement it:
How can we verify it:
service: service-for-verification provider: name: aws runtime: nodejs8.10 functions: hello1: handler: handler.hello1 hello2: handler: handler.hello2 ... hello40: handler: handler.hello40 subscriber: handler: handler.subscriber events: - cloudwatchLog: "/aws/lambda/hello1" - cloudwatchLog: "/aws/lambda/hello2" ... - cloudwatchLog: "/aws/lambda/hello40"
Is this ready for review?: YES
If we deploy on top of this PR, Lambda console will show warning message like below:
According to AWS support, this is cosmetic error and negligible.
Hey @exoego, upon reviewing this more closely. I'm not sure I like the combining of log groups with wildcard based on the longest overlap. It introduces unexpected, and more importantly unconfigurable, broader than necessary permissions. Eg, if a user subscribes to a lambda loggroup(
I completely understand that #5357 is a problem. What would you think about using the expanded
events: - cloudwatchLog: logGroup: '/aws/lambda/hello1' permissionPattern: '/aws/lambda/hello*' - cloudwatchLog: logGroup: '/aws/lambda/hello2' permissionPattern: '/aws/lambda/hello*' - cloudwatchLog: logGroup: '/aws/lambda/hello3' permissionPattern: '/aws/lambda/hello*'
it's a bit verbose, but I think it would work for your use case while avoiding introducing unexpected behavior.
Yes, implicit wildcard may give unnecessarily-wide pattern like
Please correct me if I miss something.