-
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(scheduler-targets): add support for universal target #32341
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #32341 +/- ##
=======================================
Coverage 81.41% 81.41%
=======================================
Files 223 223
Lines 13721 13721
Branches 2416 2416
=======================================
Hits 11171 11171
Misses 2271 2271
Partials 279 279
Flags with carried forward coverage won't be shown. Click here to find out more.
|
…heduler-universal-target
…heduler-universal-target
@go-to-k |
…ai-ryo/aws-cdk into scheduler-universal-target
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.
LGTM. Thanks for the changes.
* The API action to call. | ||
* | ||
* You cannot use read-only API actions such as common GET operations. | ||
* | ||
* Also, This must be in camelCase. |
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.
nit:
* The API action to call. | |
* | |
* You cannot use read-only API actions such as common GET operations. | |
* | |
* Also, This must be in camelCase. | |
* The API action to call. Must be camelCase. | |
* | |
* You cannot use read-only API actions such as common GET operations. See https://docs.aws.amazon.com/scheduler/latest/UserGuide/managing-targets-universal.html#unsupported-api-actions |
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, fixed.
ead143b
/** | ||
* Properties for a Universal Target | ||
*/ | ||
export interface UniversalProps extends ScheduleTargetBaseProps { |
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.
nit:
export interface UniversalProps extends ScheduleTargetBaseProps { | |
export interface UniversalTargetProps extends ScheduleTargetBaseProps { |
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.
fixed.a2d684b
/** | ||
* The action for the IAM policy statement that will be added to the scheduler role's policy | ||
* to allow the scheduler to make the API call. | ||
* | ||
* Use this in cases where the IAM action name does not match the | ||
* API service/action name, e.g., `lambda:invoke` requires `lambda:InvokeFunction` permission. | ||
* | ||
* @default - service:action | ||
*/ | ||
readonly iamAction?: string; |
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.
Many AWS operations requires more than one action. For example, S3 PutObject
needs more than the s3:PutObject
IAM action in certain bucket configuration: https://docs.aws.amazon.com/AmazonS3/latest/userguide/using-with-s3-policy-actions.html#using-with-s3-policy-actions-related-to-objects
In real world scenario, I think most CDK users will need to add more actions than the default of service:action
. (<-- This is a guess.) So instead of letting them rely on the default policy then find out it is not enough after deployment, I believe we should make the role
prop required for Universal Target in particular. This way CDK will lead the users to consciously determine the required and minimum permissions they need for the Universal Target to work.
Please let me know what 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.
In the ScheduleTargetBase
construct, a secure IAM Role is automatically created on behalf of the user, with conditions
attached to the trust policy.
Making the role
prop required might increase the user's workload and potentially compromise security.
The current props are based on stepfunctions-tasks
, and I think they represent a reasonably reliable implementation.
https://github.com/aws/aws-cdk/blob/v2.175.0/packages/aws-cdk-lib/aws-stepfunctions-tasks/lib/aws-sdk/call-aws-service.ts
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 @sakurai-ryo for the response. I agree with you that having CDK adding the assume-role-policy with secure conditions here is valuable. I am convinced that we should not require CDK users to pass in a role prop.
I spent some time to study the stepfunctions-tasks.CallAwsService
class you linked and its history. It originally did not have the additionalPolicyStatements
prop. And with the iamX
props, it seems to have created confusions because the service:action
is not enough permissions for the application to work [1].
I think the best middle ground here is to have the following props:
export interface UniversalTargetProps extends ScheduleTargetBaseProps {
readonly service: string;
readonly action: string;
/**
* The IAM policy statements needed to invoke the target. These statements are attached to the Scheduler's role.
*
* Note that the default may not be the correct actions as not all AWS services follows the same IAM action pattern, or there may be more actions needed to invoke the target.
*
* @default - Policy with `service:action` action only.
*/
readonly policyStatements?: PolicyStatement[]; /* <--- this will **replace** the default policy */
}
[1] List of issues with regards to confusion on default policy:
- aws-stepfunctions-tasks: CallAwsService for elasticloadbalancingv2 produces invalid IAM role policies #32417
- aws-cdk-lib/aws-stepfunctions-tasks: Issue with incorrectly generated IAM policy. #30862
- aws-cdk-lib/aws-stepfunctions-tasks: sesv2 task does not grant ses:SendEmail permission #30745
- stepfunctions-tasks: mediapackagevod service generates wrong action in role policy #28774
- aws_stepfunctions_tasks : Generates wrong action in role policy #27573
Thank you for discussing this with me to make CDK better. I appreciate it!
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.
@samson-keung
Thank you for your suggestion.
As a result, the API design has become more refined!
I’ve made it so that either the default policy or the policy statements specified in policyStatements
prop are added to the IAM Role, but not both. Does this align with your intention?
Pull request has been modified.
…heduler-universal-target
/** | ||
* The action for the IAM policy statement that will be added to the scheduler role's policy | ||
* to allow the scheduler to make the API call. | ||
* | ||
* Use this in cases where the IAM action name does not match the | ||
* API service/action name, e.g., `lambda:invoke` requires `lambda:InvokeFunction` permission. | ||
* | ||
* @default - service:action | ||
*/ | ||
readonly iamAction?: string; |
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 @sakurai-ryo for the response. I agree with you that having CDK adding the assume-role-policy with secure conditions here is valuable. I am convinced that we should not require CDK users to pass in a role prop.
I spent some time to study the stepfunctions-tasks.CallAwsService
class you linked and its history. It originally did not have the additionalPolicyStatements
prop. And with the iamX
props, it seems to have created confusions because the service:action
is not enough permissions for the application to work [1].
I think the best middle ground here is to have the following props:
export interface UniversalTargetProps extends ScheduleTargetBaseProps {
readonly service: string;
readonly action: string;
/**
* The IAM policy statements needed to invoke the target. These statements are attached to the Scheduler's role.
*
* Note that the default may not be the correct actions as not all AWS services follows the same IAM action pattern, or there may be more actions needed to invoke the target.
*
* @default - Policy with `service:action` action only.
*/
readonly policyStatements?: PolicyStatement[]; /* <--- this will **replace** the default policy */
}
[1] List of issues with regards to confusion on default policy:
- aws-stepfunctions-tasks: CallAwsService for elasticloadbalancingv2 produces invalid IAM role policies #32417
- aws-cdk-lib/aws-stepfunctions-tasks: Issue with incorrectly generated IAM policy. #30862
- aws-cdk-lib/aws-stepfunctions-tasks: sesv2 task does not grant ses:SendEmail permission #30745
- stepfunctions-tasks: mediapackagevod service generates wrong action in role policy #28774
- aws_stepfunctions_tasks : Generates wrong action in role policy #27573
Thank you for discussing this with me to make CDK better. I appreciate it!
…hub.com/sakurai-ryo/aws-cdk into scheduler-universal-target
…heduler-universal-target
Pull request has been modified.
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. This is awesome!
Thank you for contributing! Your pull request will be updated from main and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork). |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
Thank you for contributing! Your pull request will be updated from main and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork). |
Comments on closed issues and PRs are hard for our team to see. |
Issue # (if applicable)
Closes #32328
Reason for this change
EventBridge Scheduler has a mechanism called Universal Target that calls a wide range of AWS APIs.
Supporting this mechanism in L2 Construct will make it easier to configure EventBridge Scheduler.
https://docs.aws.amazon.com/scheduler/latest/UserGuide/managing-targets-universal.html
Description of changes
Added Universal construct targeting AWS APIs.
Users can execute any AWS API by passing service and action to Props.
According to the following documentation, the service must be lowercase, and the action must be camelCase, so that you can validate it.
arn:aws:scheduler:::aws-sdk:service:apiAction
https://docs.aws.amazon.com/scheduler/latest/UserGuide/managing-targets-universal.html#:~:text=schedule%20to%20target.-,Arn,-%E2%80%93%20The%20complete%20service
Description of how you validated changes
Added unit tests and integration tests.
Checklist
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license