Why is refactoring into Connectors field creating multiple policies in the form of MainFunctionToWritePolicyDestination0, MainFunctionToWritePolicyDestination1 etc?

[kitsunde]

Hello,

We've using the AWS::Connector and when merging it into Connectors we got blocked by the PoliciesPerRole, looking at the CF output instead of creating 1 policy for all destinations it's creating individual destinations which is quite surprising since our other stacks don't behave like that.

I.e. we moved AWS::Connector resources to be under the AWS::Serverless::Function resource directly:

  MainFunction:
    # [..]
    Connectors:
      ToWrite:
        Properties:
          Destination:
            - Id: OneBucket
            - Id: OneQueue
            - Id: AnotherQueue
          Permissions:
            - Write

During deployment it then attempts to create MainFunctionToWritePolicyDestination0 etc. Any idea why? We also have a managed policy and 2 inline policies on the same function, but a lot of our stacks have inline policies to talk to RedShift.

[aaythapa]

Hi @kitsunde thanks for reporting this.

This is expected behaviour for multi-destination connectors. For each destination connected to the source SAM will create a policy with the logical id <source-logical-id><connector-name>PolicyDestination<destination-number>. So in your case there would be 3 different policies for the 3 different destinations.

Let us know if that answers your question, thanks.

[kitsunde]

Ah I could've sworn I had checked this, but you're of course correct this has always been the case. I don't suppose there's any plans on merging those in the futures since the default and upper limit is quite small 10 / 20?

[aaythapa]

Merging what exactly? The policies? Don't think we can since the generated policies are for that one destination (the destination resource's logical id is part of the policy) so we can't have one policy for multiple destinations (if thats what you mean).

[kitsunde]

Thanks for replying and sorry for the delay,

Yeah that's what I mean. Since on a 1:n, source:destination like above policy it just becomes:

• <source><connectorname>Destination<n>-<randompostfix?>

i.e.

Function:
  # [..]
  Connectors:
    ToWrite:
      Properties:
        Destination:
          - Id: OneBucket
          - Id: OneQueue
        Permissions:
          - Write

becomes:

some-function-FunctionFunctionToWritePolicyDestination0-11NBNHG2P7F97
some-function-FunctionFunctionToWritePolicyDestination1-31NBNHG2P7FAA

Where each <n> contains a single statement policy:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": [
                "lambda:InvokeAsync",
                "lambda:InvokeFunction"
            ],
            "Resource": [
                "arn:aws:lambda:ap-southeast-1:<account id>:function:<actual name>"
            ],
            "Effect": "Allow"
        }
    ]
}

So then wouldn't it possible for SAM to combine destinations under a single policy:

• <source><connectorname>Destination-<randompostfix?>

Like:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": [
                "lambda:InvokeAsync",
                "lambda:InvokeFunction"
            ],
            "Resource": [
                "arn:aws:lambda:ap-southeast-1:<account id>:function:<actual name>"
            ],
            "Effect": "Allow"
        },
        {
            "Action": [
                "s3:AbortMultipartUpload",
                "s3:DeleteObject",
                "s3:DeleteObjectVersion",
                "s3:PutObject",
                "s3:PutObjectLegalHold",
                "s3:PutObjectRetention",
                "s3:RestoreObject"
            ],
            "Resource": [
                "arn:aws:s3:::<actual name>",
                "arn:aws:s3:::<actual name>/*"
            ],
            "Effect": "Allow"
        }
    ]
}

This is basically how we deal with this now, if we hit the policy count limit, we move something into an ever growing inline policy, but at that point we're back to human erroring policies again.