Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[lambda] Starting in 1.68.0 lambda Function.addPermission() incorrectly tries to add permission resource to remote functions #11278

Closed
peterb154 opened this issue Nov 4, 2020 · 3 comments
Assignees
Labels
@aws-cdk/aws-lambda Related to AWS Lambda bug This issue is a bug. needs-triage This issue or PR still needs to be triaged.

Comments

@peterb154
Copy link
Contributor

peterb154 commented Nov 4, 2020

Starting in 1.68.0 lambda functions imported from remote accounts can incorrectly addPermission()

The Question

This change #10622 created a situation where cdk tries to addPermission to a lambda imported from a remote account.

User: arn:aws:sts::XXXXX:assumed-role/1111/22222-session is not authorized to perform: lambda:AddPermission on resource: 
arn:aws:lambda:us-east-1:YYYYY:function:ZZZZZ (Service: AWSLambda; Status Code: 403; Error Code: 
AccessDeniedException; Request ID: 3d57926c-986b-404f-88be-448dd359ca72; Proxy: null)

Environment

cdk version 1.68.0+

Example app.py

import aws_cdk.core as core
import aws_cdk.aws_lambda as aws_lambda
import aws_cdk.aws_config as config

REMOTE_ACCOUNT = '123456789012'
REMOTE_FUNCTION = 'MyFunction'

class ExampleStack(core.Stack):
    def __init__(self, scope: core.Construct, id: str):
        super().__init__(scope, id)
        lambda_function = aws_lambda.Function.from_function_arn(
           self, "MyFunction",
           function_arn=f"arn:aws:lambda:{core.Aws.REGION}:{REMOTE_ACCOUNT}:function:{REMOTE_FUNCTION}"
        )

        # Create the custom rule construct
        config.CustomRule(
            self, "MyRule",
            config_rule_name="MyRule",
            lambda_function=lambda_function,
            configuration_changes=True
        )

app = core.App()
ExampleStack(app, "ExampleStack", )
app.synth()

Example requirements.txt

aws-cdk.core==1.67.0
aws-cdk.aws-config==1.67.0
aws-cdk.aws-lambda==1.67.0

Demonstration of the problem

v1.67.0 and prior returns the expected number (0) of AWS::Lambda::Permissions resources

$ sed -i txt s/68/67/ requirements.txt && pip install -qr requirements.txt && cdk synth --app "python app.py"  | grep -c Permission

0

But upgrade to 1.68.0 (or higher)

$ sed -i txt s/67/68/ requirements.txt && pip install -qr requirements.txt && cdk synth --app "python app.py"  | grep -c Permission

4

Returns 4 AWS::Lambda::Permissions resources. (should have none)

Source

configRule runs addPermission() on the ILambda here
https://github.com/aws/aws-cdk/blob/master/packages/%40aws-cdk/aws-config/lib/rule.ts#L356-L358

and Function.addPermission changed with this change https://github.com/aws/aws-cdk/pull/10622/files which was included in 1.68.0.

I believe this change is what caused the problem.
image

@peterb154
Copy link
Contributor Author

peterb154 commented Nov 4, 2020

Thinking more about this. The assumption made by the recent change is that if either the this.stack.account or this.function are unresolved it is assumed that the function is "local" to the stack. Previously, this logic was reversed. I think this might be too assumptive.

@SomayaB SomayaB added bug This issue is a bug. needs-triage This issue or PR still needs to be triaged. labels Nov 5, 2020
@SomayaB SomayaB changed the title Starting in 1.68.0 lambda Function.addPermission() incorrectly tries to add permission resource to remote functions [lambda] Starting in 1.68.0 lambda Function.addPermission() incorrectly tries to add permission resource to remote functions Nov 5, 2020
@github-actions github-actions bot added the @aws-cdk/aws-lambda Related to AWS Lambda label Nov 5, 2020
@nija-at
Copy link
Contributor

nija-at commented Nov 9, 2020

Hey @peterb154 - this is indeed a problem and your assessment is correct.

This is a duplicate of #11141

@nija-at nija-at closed this as completed Nov 9, 2020
@github-actions
Copy link

github-actions bot commented Nov 9, 2020

⚠️COMMENT VISIBILITY WARNING⚠️

Comments on closed issues are hard for our team to see.
If you need more assistance, please either tag a team member or open a new issue that references this one.
If you wish to keep having a conversation with other community members under this issue feel free to do so.

nija-at pushed a commit that referenced this issue Nov 9, 2020
…her account

Originally, when a function was imported into an account agnostic stack,
it was assumed that the function was from a different account and hence
its permission cannot be modified.

A subsequent change - 99111f7 - changed
this behaviour to its opposite. When an account agnostic stack was
encountered in the context of an imported function, it was assumed that
the function was part of the same account.
This has caused customers to report regressions - #11278, #11141.

This change reverts this behaviour back to its original assumption, with
the additional ability to configure this explicitly by the user if
needed for an advanced use case.

fixes #11141
nija-at pushed a commit that referenced this issue Nov 9, 2020
…her account

Originally, when a function was imported into an account agnostic stack,
it was assumed that the function was from a different account and hence
its permission cannot be modified.

A subsequent change - 99111f7 - changed
this behaviour to its opposite. When an account agnostic stack was
encountered in the context of an imported function, it was assumed that
the function was part of the same account.
This has caused customers to report regressions - #11278, #11141.

This change reverts this behaviour back to its original assumption, with
the additional ability to configure this explicitly by the user if
needed for an advanced use case.

fixes #11141
mergify bot pushed a commit that referenced this issue Nov 16, 2020
…her account (#11369)

Originally, when a function was imported into an account agnostic stack,
it was assumed that the function was from a different account and hence
its permission cannot be modified.

A subsequent change - 99111f7 - changed
this behaviour to its opposite. When an account agnostic stack was
encountered in the context of an imported function, it was assumed that
the function was part of the same account.
This has caused customers to report regressions - #11278, #11141.

This change reverts this behaviour back to its original assumption, with
the additional ability to configure this explicitly by the user if
needed for an advanced use case.

fixes #11141


----

*By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
@aws-cdk/aws-lambda Related to AWS Lambda bug This issue is a bug. needs-triage This issue or PR still needs to be triaged.
Projects
None yet
Development

No branches or pull requests

3 participants