-
Notifications
You must be signed in to change notification settings - Fork 4k
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(apigateway): resource policy configuration for private API #32719
base: main
Are you sure you want to change the base?
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #32719 +/- ##
=======================================
Coverage 81.38% 81.38%
=======================================
Files 222 222
Lines 13698 13698
Branches 2413 2413
=======================================
Hits 11148 11148
Misses 2271 2271
Partials 279 279
Flags with carried forward coverage won't be shown. Click here to find out more.
|
* | ||
* @param statement the policy statement to add | ||
*/ | ||
addToResourcePolicy(statement: iam.PolicyStatement): iam.AddToResourcePolicyResult; |
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.
This adds something non-optional (a method that should be implemented compulsorily) to the interface. However, if a user has already created a custom construct that has implemented this IRestApi, this change will cause the CDK application to stop working. (It may be a Construct made in community, or it may be a Construct made within a company.)
The interface is a foundation of Construct and the medium used for communication between Constructs. So I'm wondering if we should avoid this sort of change, what do you think?
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.
Thank you for your review! A valid point.
As an alternative, how about having the RestApiBase
class implement the IResourceWithPolicy interface?
- export abstract class RestApiBase extends Resource implements IRestApi {
+ export abstract class RestApiBase extends Resource implements IRestApi, IResourceWithPolicy {
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.
That's maybe good!
However, RestApiBase has been exported, so there may be a slight impact. But since you've created a PR, let's just make it up and leave the rest to the maintainer's discretion!
Because I don't think many users will extend RestApiBase instead of the interface :)
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.
I haven't seen most of the code yet, so please give me a shout so I can look at it when you fix it.
(I haven't submitted change request yet, so if another community reviewers see it first, I'll leave it to them! So let's not resolve these comments for now, please.)
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.
Thanks!
I'll update my code and ping you later.
@go-to-k I've modified the RestApiBase class to implement the IResourceWithPolicy interface! |
* | ||
* @param vpcEndpoint the interface VPC endpoint to grant access to | ||
*/ | ||
public grantInvokeToVpcEndpoint(vpcEndpoint: ec2.IVpcEndpoint): void { |
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.
This is a method to invoke from (via) a VPC endpoint, but is the name grantInvokeToVpcEndpoint
as it is supposed to be? Do you mean grant the policy to a VPCEndpoint? (Sounds like VPCEndpoint is the principal...?)
Also, Method
class has a method called grantExecute
, is it correct to not use the word "Execute" instead of "Invoke" for the grantInvokeToVpcEndpoint
?
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.
This is not a suggestion, just a question :)
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.
I've really thought about what to call this function... Therefore, I had asked the maintainer and he suggested grantInvokeToVpcEndpoint
.
This is just another question, but is there a reason you created this method in the Rest API instead of |
this.addToResourcePolicy(new iam.PolicyStatement({ | ||
principals: [new iam.AnyPrincipal()], | ||
actions: ['execute-api:Invoke'], | ||
resources: ['execute-api:/*'], | ||
effect: iam.Effect.ALLOW, | ||
})); |
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.
Related: #32719 (comment)
If you don't want to "grant specific permissions" but rather "deny access from non-VPCEndpoints", do we need this permission policy?
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.
However, I know that in this case it would be a strange method to just delete this policy because it is different from the normal Grant method. Anyway, take this as just another question.
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.
I think if we remove this ALLOW policy, the IAM policy implicitly denies all actions. Therefore, we cannot access to the APIGW via the correct endpoint.
I think it is enough to allow the access from the correct vpc endpoint, I used these policies which is suggested in the official document.
https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-resource-policies-examples.html#apigateway-resource-policies-source-vpc-example
The purpose of associating this function with the |
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.
I see. It is sufficient to have answers to these questions. I wanted it. I'm okay and approve it.
To a maintainer: please see the comment. This is about a behavior for users who customize their own constructs.
Thanks @go-to-k !! |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
Issue # (if applicable)
Closes #31660.
Reason for this change
The same PR is closed during maintainer's review. (#31692)
To create a Private API Gateway, we need to attach a resource policy that allows access only from specific Interface VPC Endpoints, as shown below.
This is a bit troublesome.
Description of changes
IRestApi.addToResourcePolicy()
addToResourcePolicy()
at RestApi, SpecApi, and imported RestApi classRestApiBase.grantInvokeToVpcEndpoint()
In the
grantInvokeToVpcEndpoint
method, it was necessary to set a resource policy, and since a policy already existed in RestApiProps, I implemented it so that both can be used simultaneously.Describe any new or updated permissions being added
Add 2 functions which modify resource policies.
Description of how you validated changes
Add both unit and integ tests.
Checklist
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license