-
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
fix(stepfunctions): distributed maps under branches do not have necessary permissions #29913
Conversation
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 pull request linter has failed. See the aws-cdk-automation comment below for failure reasons. If you believe this pull request should receive an exemption, please comment and provide a justification.
A comment requesting an exemption should contain the text Exemption Request
. Additionally, if clarification is needed add Clarification Request
to a comment.
ahh re pull request validator failing for no integration test update, i will look at that later this weekend of sometime next week. |
526527e
to
62f08f4
Compare
✅ Updated pull request passes all PRLinter validations. Dismissing previous PRLinter review.
added a couple integration tests and fixed the linting problems |
1a2ed6f
to
38c98b2
Compare
i was wondering about my approach... because branches aren't exposed, i moved the policy stuff into State. however, State cannot depend on DistributedMap because of a cyclic dependency. To deal with this, I just passed isDistributedMap into the method call. This is based on the assumption that branches is hidden for a reason. This works but could be cleaner. I was wondering about thoughts on a few alternative solutions:
from my point of view, anything is fine, i just want to remove the manual perms from my cdk since it's weird that cdk sometimes but not always adds them (depending on how the graph is shaped) heh anyway will update if needed! |
👋 just wanted to touch base on this... I'm happy to make changes if yall don't like the approach! thanks :) |
just saw there is also an issue reported for this - linked it in desc... just following up again though, is someone able to look at this? Thanks :) |
38c98b2
to
a820573
Compare
just following up... again i'm happy to make changes, would appreciate feedback! thanks :) |
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.
branches
is protected because many of the stepfunctions features live on the base class but are defined and exposed in subclasses, as explained here: https://github.com/aws/aws-cdk/blob/main/packages/aws-cdk-lib/aws-stepfunctions/lib/states/state.ts#L163, and since branches
is only usable with Parallel
states, I don't think it makes sense to expose it.
I don't think the processor mode approach is the right one either, for the the reason you outlined.
The design suggests we should include IsDistributedMap
on the base class, as you describe in option 2. This is an odd placement, because the base class should not know anything about its Distributed subclass variant - but we've already broken this assumption by declaring all of these subclass-unique properties on the base class, so we may as well include isDistributedMap
on the base class.
This PR has been in the CHANGES REQUESTED state for 3 weeks, and looks abandoned. To keep this PR from being closed, please continue work on it. If not, it will automatically be closed in a week. |
distributed maps under branch states (i.e., Parallel) do not apply the necessary permissions to run the state. instead of only iterating states in the parent graph, iterate all children as well. if any of them are distributed maps, add the necessary policy.
a820573
to
a1f8263
Compare
sorry finally got back to this... I realized adding isDistributedMap was impractical because of i realized that child graphs are contained within allContainedStates which means we can just recursively call bind on each graph in that collection, which in turn avoids making changes outside of the original StateGraph logic (so less code touched, woohoo). anyway! updated to do that, let me know if this makes sense |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
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 contribution! I can see that a lot of hard work went into this and it looks right. I just have a couple requests inline for improving the testing a bit.
/** | ||
* Stack verification steps: | ||
* | ||
* -- aws stepfunctions describe-state-machine --state-machine-arn <stack-output> has a status of `ACTIVE` |
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.
Could you please add an assertion that does this instead of making it a manual verification step?
timeout: cdk.Duration.seconds(30), | ||
}); | ||
|
||
new cdk.CfnOutput(stack, 'StateMachine1ARN', { |
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.
These outputs are great but we should do something with them. Perhaps add assertions that get the machine state of each of these?
// is that our permissions adding doesn't create infinite recursion as we iterate through all nested graphs. | ||
// a failure in this test case (for the thing it is meant to test) would present as a stack overflow ("maximum call | ||
// stack size exceeded" error.) | ||
template.hasResource('AWS::IAM::Policy', createPolicyProps(stateMachineLogicalId)); |
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.
Can we check for the expected amount of policies based off the amount of child states?
oh i just saw your comments! thanks for looking :D I'll try to address them this weekend - i looked at a couple integ tests and the (manual) way i did it was based on an existing test, i didn't realize there's a framework in other tests for validating via api, that'll be much nicer :) |
This PR has been in the CHANGES REQUESTED state for 3 weeks, and looks abandoned. To keep this PR from being closed, please continue work on it. If not, it will automatically be closed in a week. |
This PR has been deemed to be abandoned, and will be automatically closed. Please create a new PR for these changes if you think this decision has been made in error. |
Comments on closed issues and PRs are hard for our team to see. |
Issue
Closes #29266
Reason for this change
distributed maps under branch states (i.e., Parallel) do not apply the necessary permissions to run the state.
Description of changes
this moves the bind functionality into state and calls it on both state and all child (branch) states. Previously it did not run on branch states and as such did not work for example a distributed map under a parallel state without adding the permissions out of band.
An alternative would be to have a bind method that the user calls out of band on the distributed map (or in my case, in a wrapper class, but it's clunky)
Description of how you validated changes
Unit tests
Checklist
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license