Terraform: aws_lambda_permission reaching The final policy size (20718) is bigger than the limit (20480)

Context:

I have a lambda named console that allows me to run all cron-like tasks using PHP Symfony's console command. As my codebase is a big monolith that's why I have only one lambda (having one lambda by command would still require 99.9% of the code and would be a nightmare to deploy)

This lambda is invoked by cloudwatch events , with basically 1 cloudwatch rule => 1 task

As we also have unrelated cloudwatch rules, I want to be sure that only the appropriate rules can invoke this lambda. I.e I don't want to just allow all cloudwatch rules.

With terraform we manage it like that

resource "aws_lambda_function" "console" {
   # not relevant
}

# These 3 resources  are repeated  N times for each "task"
resource "aws_cloudwatch_event_rule" "run_task_foobar" {
  # not relevant
}

resource "aws_cloudwatch_event_target" "run_task_foobar" {
  rule      = aws_cloudwatch_event_rule.run_task_foobar.name
  target_id = "foobar"
  arn       = aws_lambda_function.console.arn
  input     = "\" console run foobar \""
}

resource "aws_lambda_permission" "run_task_foobar" {
  action        = "lambda:InvokeFunction"
  function_name = aws_lambda_function.console.function_name
  principal     = "events.amazonaws.com"
  source_arn    = aws_cloudwatch_event_rule.run_task_foobar.arn

  # not compatible with tags
}

The problem

As we have several dozen of task , 53 to be exact , we now have this error when we try to apply for a 54th task

> PolicyLengthExceededException: The final policy size (20701) is bigger than the limit (20480).

And yes when I check in the AWS Console , I can see the resulting IAM Policy is HUGE

{
  "Version": "2012-10-17",
  "Id": "default",
  "Statement": [
    {
      "Sid": "foo",
      "Effect": "Allow",
      "Principal": {
        "Service": "events.amazonaws.com"
      },
      "Action": "lambda:InvokeFunction",
      "Resource": "arn:aws:lambda:eu-west-1:xxxx:function:console",
      "Condition": {
        "ArnLike": {
          "AWS:SourceArn": "arn:aws:events:eu-west-1:xxxxx:rule/foo"
        }
      }
    },
    {
      "Sid": "bar",
      "Effect": "Allow",
      "Principal": {
        "Service": "events.amazonaws.com"
      },
      "Action": "lambda:InvokeFunction",
      "Resource": "arn:aws:lambda:eu-west-1:xxxx:function:console",
      "Condition": {
        "ArnLike": {
          "AWS:SourceArn": "arn:aws:events:eu-west-1:xxxxx:rule/bar"
        }
      }
    },
    ... # repeated 53 times 

Of course it becomes clearly obvious that the Condition block should be factorized into the pseudo code

{
  "Version": "2012-10-17",
  "Id": "default",
  "Statement": [
    {
      "Sid": "bar",
      "Effect": "Allow",
      "Principal": {
        "Service": "events.amazonaws.com"
      },
      "Action": "lambda:InvokeFunction",
      "Resource": "arn:aws:lambda:eu-west-1:xxxx:function:console",
      "Condition": {
        "InArray": {  # I don't know if inarray exists but it does not matter see below
          "AWS:SourceArn": [
               "arn:aws:events:eu-west-1:xxxxx:rule/bar",
               "arn:aws:events:eu-west-1:xxxxx:rule/foo",
               ... , # 53 times
           ]
        }
      }
    },

However there's no fine grain control on "Condition" , it's autogenerated by both terraform and the AWS console

Question(s) :

1. Is there an actual way to factorize this ?
2. Is there an alternate solution by creating directly an IAM policy ?

My current workaround would be to setup a convention that all the cloudwatch event rule should start with "console-" so that I can use a wildcard , but that seems fragile ?

Given your current context your only option is as you already stated the use wild cards in the policy construction as this AWS article also advocates https://repost.aws/knowledge-center/lambda-resource-based-policy-size-error

Regarding your security concerns around the fragility related to the usage of wildcards, if you have proper security controls in this AWS account, meaning IAM write permissions are only accessible to a restricted set of users/automations you will be fine.