fix(bootstrap): disallow AssumeRole with ExternalId by default#811
fix(bootstrap): disallow AssumeRole with ExternalId by default#811
Conversation
By default, CDK Bootstrap roles are not designed to be deputized. (Deputized means that you give an external entity access to assume roles on your behalf. They will supply an ExternalId to avoid [Confused Deputy attacks](https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html)) If a deputy system (i.e., a system that assumes IAM Roles on behalf of its tenants) is using CDK and its policies are not configured carefully, it can be tricked into assuming its own CDK roles. Because CDK Roles are not intended to be used in this way, we are adding a default security control that will make this misconfiguration less likely: AssumeRole calls with ExternalIds will be denied by default. What if I do want to use ExternalIds? ------------------------------------- If you are currently passing `ExternalId`s in an `AssumeRole` call to CDK bootstrap roles *inside your own trusted organization* (expecting the ExternalId to be present but ignored), this protection can be disabled by calling: ``` cdk bootstrap --no-deny-external-id ``` If you want to give permissions for other organizations to assume your CDK bootstrap roles in a deputized way, customize the bootstrap template and add a proper `ExternalId` condition.
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #811 +/- ##
==========================================
+ Coverage 80.91% 81.54% +0.62%
==========================================
Files 63 63
Lines 8618 8619 +1
Branches 1035 1040 +5
==========================================
+ Hits 6973 7028 +55
+ Misses 1616 1562 -54
Partials 29 29
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
What do you mean this is a breaking change? W.r.t existing customized templates you mean? |
Signed-off-by: github-actions <[email protected]>
…s-cdk-cli into huijbers/no-deputized-assumeroles
| if (params.denyExternalId !== undefined) { | ||
| if (!templateParameters.includes('DenyExternalId')) { | ||
| throw new ToolkitError('The selected bootstrap template does not accept the DenyExternalId parameter'); | ||
| } | ||
| bootstrapTemplateParameters.DenyExternalId = `${params.denyExternalId}`; | ||
| } |
There was a problem hiding this comment.
Q: Should this just be a warning?
Q: Should we apply this to EVERY paramter?
There was a problem hiding this comment.
A1: Perhaps. But we're making a clear distinction between passing the value and not passing it. If you pass the value, I don't think we'd want to drop it with only a warning.
A2: Perhaps. Hasn't caused a problem so far, so I'm not going to be holier than the pope without any customer pressure.
By default, CDK Bootstrap roles are not designed to be deputized.
(Deputized means that you give an external entity access to assume roles on your behalf. They will supply an ExternalId to avoid Confused Deputy attacks)
If a deputy system (i.e., a system that assumes IAM Roles on behalf of its tenants) is using CDK and its policies are not configured carefully, it can be tricked into assuming its own CDK roles.
Because CDK Roles are not intended to be used in this way, we are adding a default security control that will make this misconfiguration less likely: AssumeRole calls with ExternalIds will be denied by default.
What if I do want to use ExternalIds?
If you are currently passing
ExternalIds in anAssumeRolecall to CDK bootstrap roles inside your own trusted organization (expecting the ExternalId to be present but ignored), this protection can be disabled by calling:If you want to give permissions for other organizations to assume your CDK bootstrap roles in a deputized way, customize the bootstrap template and add a proper
ExternalIdcondition.By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license