-
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(bootstrap): same-account modern bootstrapping still requires policy ARNs #9867
Changes from all commits
ff9500e
6343e7c
dec74d5
12cd1e5
f2c4861
27d3314
680730c
cf5bd7f
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -370,7 +370,12 @@ Resources: | |
Fn::If: | ||
- HasCloudFormationExecutionPolicies | ||
- Ref: CloudFormationExecutionPolicies | ||
- Ref: AWS::NoValue | ||
- Fn::If: | ||
- HasTrustedAccounts | ||
# The CLI will prevent this case from occurring | ||
- Ref: AWS::NoValue | ||
# The CLI will advertise that we picked this implicitly | ||
- - Fn::Sub: "arn:${AWS::Partition}:iam::aws:policy/AdministratorAccess" | ||
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 hope you've verified this is the correct way to have a one-element array in YAML... this format is still a mystery to me. 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 know. It is correct though:
|
||
RoleName: | ||
Fn::Sub: cdk-${Qualifier}-cfn-exec-role-${AWS::AccountId}-${AWS::Region} | ||
# The SSM parameter is used in pipeline-deployed templates to verify the version | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -89,6 +89,34 @@ describe('Bootstrapping v2', () => { | |
.toThrow(/--cloudformation-execution-policies/); | ||
}); | ||
|
||
test('passing trusted accounts without CFN managed policies on the existing stack results in an error', async () => { | ||
mockTheToolkitInfo = { | ||
parameters: { | ||
CloudFormationExecutionPolicies: '', | ||
}, | ||
}; | ||
|
||
await expect(bootstrapper.bootstrapEnvironment(env, sdk, { | ||
parameters: { | ||
trustedAccounts: ['123456789012'], | ||
}, | ||
})) | ||
.rejects | ||
.toThrow(/--cloudformation-execution-policies/); | ||
}); | ||
|
||
test('passing no CFN managed policies without trusted accounts is okay', async () => { | ||
await bootstrapper.bootstrapEnvironment(env, sdk, { | ||
parameters: {}, | ||
}); | ||
|
||
expect(mockDeployStack).toHaveBeenCalledWith(expect.objectContaining({ | ||
parameters: expect.objectContaining({ | ||
CloudFormationExecutionPolicies: '', | ||
}), | ||
})); | ||
}); | ||
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 feel like we're missing a test for the positive case (no |
||
|
||
test('allow adding trusted account if there was already a policy on the stack', async () => { | ||
// GIVEN | ||
mockTheToolkitInfo = { | ||
|
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.
Sorry, I don't understand this comment...
cdk bootstrap --trust 1234
should fail, right? Because we require passing--cloudformation-execution-policies
when you pass--trust
?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 the missing piece of context here might be that:
Should be valid, while:
Should not.
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.
Hmmm... I'm starting to get a little uneasy about how complicated this is becoming.
For example, the following sequence:
Is it actually obvious to the user that with the second command they've just changed the trust to account 1234 from a limited policy to admin access?