-
Notifications
You must be signed in to change notification settings - Fork 3.9k
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
feat(lambda): add grantInvokeLatestVersion to grant invoke only to latest function version #29856
Changes from 11 commits
4d90557
a2ca2f2
287ccc5
1052cf1
aa9d4ca
fc612e3
3aa8b6f
679e6a6
0857f65
34d1506
a502cd0
5e5e6c9
c734032
74130bb
f4b873f
a7b2b36
cd2f33b
2e60174
36ee9a9
6b4a5eb
aa3cd0e
7501abd
734aae6
15e3e8e
e332150
f84e77c
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -17,6 +17,10 @@ fn.grantInvoke(new iam.AnyPrincipal().inOrganization('o-yyyyyyyyyy')); | |
|
||
fn.grantInvoke(new iam.OrganizationPrincipal('o-xxxxxxxxxx')); | ||
|
||
fn.grantInvoke(new iam.AnyPrincipal().inOrganization('o-yyyyyyyyyy2'), { onlyGrantLatestVersion: true }); | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Can we able to assert that There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Hi @godwingrs22 I'm looking into this but could you give me a headup on how to write integ test on this? I think I need to assume to the role I created here. But I didn't find how can I assume role in integration test. I checked There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I had a inspiration on this from my teammate: Setting up integration testI can setup 2 lambda function - fn1, fn2. And a role in the integ-test. running the integration testIn the integration test, we will only invoke fn2 by When
Then When Then What do you think? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yes this should work. However let me get a second review within my team and get back to you on this integ test handling. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @roger-zhangg , Seems the current integ test framework is designed for handling success cases. Hence we can write a success case and perform assertion if the right permission is set. This should be good enough to cover the integ test. |
||
|
||
fn.grantInvoke(new iam.OrganizationPrincipal('o-xxxxxxxxxx2'), { onlyGrantLatestVersion: true }); | ||
|
||
const fnUrl = fn.addFunctionUrl(); | ||
const role = new iam.Role(stack, 'MyRole', { | ||
assumedBy: new iam.ServicePrincipal('lambda.amazonaws.com'), | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -116,8 +116,8 @@ export class EdgeFunction extends Resource implements lambda.IVersion { | |
public addToRolePolicy(statement: iam.PolicyStatement): void { | ||
return this.lambda.addToRolePolicy(statement); | ||
} | ||
public grantInvoke(identity: iam.IGrantable): iam.Grant { | ||
return this.lambda.grantInvoke(identity); | ||
public grantInvoke(identity: iam.IGrantable, props?: lambda.GrantInvokeProps): iam.Grant { | ||
return this.lambda.grantInvoke(identity, props); | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. nit: do we need to update the |
||
} | ||
public grantInvokeUrl(identity: iam.IGrantable): iam.Grant { | ||
return this.lambda.grantInvokeUrl(identity); | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The integration feels a bit lackluster here, we're only testing that the policy is synthetically correct, not that the grants work as expected
Adding integration assertions to check that the functions are invokable with the provided examples would be ideal, either with
AwsApiCall
s, or by adding an API Gateway to integrate the Lambdas and runningHttpApiCall
sThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I do agree only testing synthetically is kind of wired, but doing
AwsApiCalls
seems to be testing against Lambda/IAM rather than testing CDK. So I just followed the previous test behavior