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.

Sign up for GitHub

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

Jump to bottom

(lambda): CDK-generated permissions will not work on Lambda invoked with Qualifier= #19273

Closed
rix0rrr opened this issue Mar 7, 2022 · 2 comments
Closed

(lambda): CDK-generated permissions will not work on Lambda invoked with Qualifier= #19273

rix0rrr opened this issue Mar 7, 2022 · 2 comments
Assignees
@kaizencc @madeline-k
Labels
bug This issue is a bug. effort/medium Medium work item – several days of effort p1

Comments

@rix0rrr
Copy link
Contributor

rix0rrr commented Mar 7, 2022

What is the problem?

Lambda is changing their authorization strategy.

When you call InvokeFunction(FunctionName='xyz', Qualifier=86):

  • It used to be the case that you would need IAM permissions granted to the unqualified function name:xyz.
  • It is now the case that you need IAM permissions granted to the qualified function name: xyz:86

It always was and still will be the case that when you do InvokeFunction(FunctionName='xyz:86'), you need IAM permissions to invoke xyz:86.

Since we don't always control what the InvokeFunction call looks like, it might just be safest/simplest to grant permissions on ['xyz', 'xyz:*'].

Reproduction Steps

See above

What did you expect to happen?

See above

What actually happened?

Call is rejected

CDK CLI Version

x

Framework Version

No response

Node.js Version

x

OS

x

Language

Typescript, Python, .NET, Java, Go

Language Version

No response

Other information

No response
@rix0rrr rix0rrr added bug This issue is a bug. needs-triage This issue or PR still needs to be triaged. effort/medium Medium work item – several days of effort p1 and removed needs-triage This issue or PR still needs to be triaged. labels Mar 7, 2022
@madeline-k madeline-k mentioned this issue Mar 9, 2022
Merged
@kaizencc kaizencc mentioned this issue Mar 18, 2022
Merged
mergify bot pushed a commit that referenced this issue Mar 24, 2022
@madeline-k
fix(lambda): support Lambda's new Invoke with Qualifier authoriza…
d06b27f 
…tion strategy (#19318)

‼️ Lambda is changing their authorization strategy, which means that some behavior that was previously valid now results in `access-denied` errors.

Under the new behavior, customer lambda invocations will fail if the CDK generates a policy with an unqualified ARN as the resource, and the customer invokes lambda with the unqualified ARN and the `Qualifier` request parameter. 

Example of an affected setup:

```
Statement: 
{
  Effect: "Allow",
  Action: "lambda:InvokeFunction",
  Resource: "arn:aws:lambda:...:function:MyFunction",
}

API Call:
lambda.Invoke({
  FunctionName: "MyFunction",
  Qualifier: "1234",
})
```

This `Invoke` call *used* to succeed, but under the new authorization strategy it will fail. The required statement to make the call succeed would be (note the qualified ARN):

```
{
  Effect: "Allow",
  Action: "lambda:InvokeFunction",
  Resource: "arn:aws:lambda:...:function:MyFunction:1234",
}
```

This PR aims to align the CDK with the new authorization strategy. The PR introduces changes to the `grantInvoke()` api on a lambda function. Now, when calling `grantInvoke()` on a lambda function, `[ARN, ARN:*]` is used in the identity policy, so that identities that are granted permission to invoke the Function may also invoke all of its Versions and Aliases. 

When calling `grantInvoke()` on a lambda function Version or Alias, the generated identity policy will remain the same, and only include `ARN:<version/alias>` in the policy.

This is part of #19273


----

*By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
mergify bot pushed a commit that referenced this issue Mar 31, 2022
@kaizencc
feat(lambda): warn if you use function.grantInvoke while also using…
fd1fff9 
… `currentVersion` (#19464)

‼️ Lambda is changing their authorization strategy, which means that some behavior that was previously valid now results in `access-denied` errors.

Under the new behavior, customer lambda invocations will fail if the CDK generates a policy with an unqualified ARN as the resource, and the customer invokes lambda with the unqualified ARN and the `Qualifier` request parameter. 

Example of an affected setup:

```
Statement: 
{
  Effect: "Allow",
  Action: "lambda:InvokeFunction",
  Resource: "arn:aws:lambda:...:function:MyFunction",
}

API Call:
lambda.Invoke({
  FunctionName: "MyFunction",
  Qualifier: "1234",
})
```

This `Invoke` call *used* to succeed, but under the new authorization strategy it will fail. The required statement to make the call succeed would be (note the qualified ARN):

```
{
  Effect: "Allow",
  Action: "lambda:InvokeFunction",
  Resource: "arn:aws:lambda:...:function:MyFunction:1234",
}
```

This PR aims to warn users who could be using an affected setup. Users will receive the a warning message under the following circumstances:

- they grant `lambda:InvokeFunction` to an unqualified function arn
- they call `lambda.currentVersion` somewhere in their code

This is part of #19273. Related is #19318.

----

*By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
@kaizencc
Copy link
Contributor

This issue is closed by the combination of #19318 and #19464

@github-actions
Copy link

⚠️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.

StevePotter pushed a commit to StevePotter/aws-cdk that referenced this issue Apr 27, 2022
@madeline-k
fix(lambda): support Lambda's new Invoke with Qualifier authoriza…
3902e35 
…tion strategy (aws#19318)

‼️ Lambda is changing their authorization strategy, which means that some behavior that was previously valid now results in `access-denied` errors.

Under the new behavior, customer lambda invocations will fail if the CDK generates a policy with an unqualified ARN as the resource, and the customer invokes lambda with the unqualified ARN and the `Qualifier` request parameter. 

Example of an affected setup:

```
Statement: 
{
  Effect: "Allow",
  Action: "lambda:InvokeFunction",
  Resource: "arn:aws:lambda:...:function:MyFunction",
}

API Call:
lambda.Invoke({
  FunctionName: "MyFunction",
  Qualifier: "1234",
})
```

This `Invoke` call *used* to succeed, but under the new authorization strategy it will fail. The required statement to make the call succeed would be (note the qualified ARN):

```
{
  Effect: "Allow",
  Action: "lambda:InvokeFunction",
  Resource: "arn:aws:lambda:...:function:MyFunction:1234",
}
```

This PR aims to align the CDK with the new authorization strategy. The PR introduces changes to the `grantInvoke()` api on a lambda function. Now, when calling `grantInvoke()` on a lambda function, `[ARN, ARN:*]` is used in the identity policy, so that identities that are granted permission to invoke the Function may also invoke all of its Versions and Aliases. 

When calling `grantInvoke()` on a lambda function Version or Alias, the generated identity policy will remain the same, and only include `ARN:<version/alias>` in the policy.

This is part of aws#19273


----

*By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
StevePotter pushed a commit to StevePotter/aws-cdk that referenced this issue Apr 27, 2022
@kaizencc
feat(lambda): warn if you use function.grantInvoke while also using…
65648de 
… `currentVersion` (aws#19464)

‼️ Lambda is changing their authorization strategy, which means that some behavior that was previously valid now results in `access-denied` errors.

Under the new behavior, customer lambda invocations will fail if the CDK generates a policy with an unqualified ARN as the resource, and the customer invokes lambda with the unqualified ARN and the `Qualifier` request parameter. 

Example of an affected setup:

```
Statement: 
{
  Effect: "Allow",
  Action: "lambda:InvokeFunction",
  Resource: "arn:aws:lambda:...:function:MyFunction",
}

API Call:
lambda.Invoke({
  FunctionName: "MyFunction",
  Qualifier: "1234",
})
```

This `Invoke` call *used* to succeed, but under the new authorization strategy it will fail. The required statement to make the call succeed would be (note the qualified ARN):

```
{
  Effect: "Allow",
  Action: "lambda:InvokeFunction",
  Resource: "arn:aws:lambda:...:function:MyFunction:1234",
}
```

This PR aims to warn users who could be using an affected setup. Users will receive the a warning message under the following circumstances:

- they grant `lambda:InvokeFunction` to an unqualified function arn
- they call `lambda.currentVersion` somewhere in their code

This is part of aws#19273. Related is aws#19318.

----

*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
Assignees

@kaizencc kaizencc

@madeline-k madeline-k

Labels
bug This issue is a bug. effort/medium Medium work item – several days of effort p1
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@rix0rrr @kaizencc @madeline-k