-
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
Immutable roles cannot be used as constructs #6885
Comments
Also experiencing this on 1.30.0 |
Seems like a regression. Looking into it. Thanks for reporting |
@markusl what is |
@markusl @alan-cooney can I also ask you guys to completely nuke your I suspect that your IAM library is older than 1.29.0 |
I am unable to reproduce this with a clean 1.30.0 dependency closure. |
Hi eladb - yes I'll try that now. I've been playing around with it and, for me, the issue occurs only when the role property is set. |
Makes sense because this error stems from an attempt to add a child construct to the role, which only happens if the role is defined. Since version 1.29.0, the way we associate constructs to nodes had changed and I suspect this is the reason there is an incompatibility. |
Following this: https://docs.aws.amazon.com/cdk/latest/guide/serverless_example.html I get the same error. If you downgrade |
Can you please try to nuke & recreate your node_modules and make sure package.json has a single version for all CDK deps? |
@martzcodes @markusl can you please paste the output of |
Here is the code that I am trying to use for a repro: import * as cdk from '@aws-cdk/core';
import * as iam from '@aws-cdk/aws-iam';
import * as pipeline from '@aws-cdk/aws-codepipeline';
import * as actions from '@aws-cdk/aws-codepipeline-actions';
import * as cc from '@aws-cdk/aws-codecommit';
export class ReproV187279444Stack extends cdk.Stack {
constructor(scope: cdk.Construct, id: string, props?: cdk.StackProps) {
super(scope, id, props);
const role = iam.Role.fromRoleArn(this, 'myRole', 'arn:aws:iam::account-id:role/role-name-with-path');
// also tried this: const role = new iam.Role(this, 'MyRole', {assumedBy: new iam.AnyPrincipal()});
const buildOutput = new pipeline.Artifact();
new pipeline.Pipeline(this, 'Pipeline', {
stages: [
{
stageName: 'Source',
actions: [
new actions.CodeCommitSourceAction({
actionName: 'CodeCommit',
repository: new cc.Repository(this, 'Repo', {
repositoryName: 'foobar'
}),
output: buildOutput
})
]
},
{
stageName: 'Deploy',
actions: [
new actions.CloudFormationCreateUpdateStackAction({
runOrder: 2,
stackName: 'cluster-stack',
actionName: 'UpdateProdCluster',
templatePath: new pipeline.ArtifactPath(buildOutput, 'cdk.out/cluster.template.json'),
role: role,
adminPermissions: false,
deploymentRole: role,
}),
]
}
]
});
}
} |
@markusl can you take a look and let me know if something stands out as dramatically different from your code? The above code does not throw this error. |
Not sure which of our instances are the problematic ones, if this does not always happen. We also have one different from the previous, using parameters for cross-account deployment of a lambda zip: new codepipeline_actions.CloudFormationCreateUpdateStackAction({
stackName,
account,
region: 'eu-central-1',
actionName: stageName,
templatePath: new codepipeline.ArtifactPath(buildOutput, `cdk/cdk.out/${stackName}.template.json`),
parameterOverrides: {
['BucketNameParam']: buildOutput.s3Location.bucketName,
['ObjectKeyParam']: buildOutput.s3Location.objectKey,
},
adminPermissions: true,
capabilities: [cloudformation.CloudFormationCapabilities.NAMED_IAM],
role: deployerRole,
deploymentRole: deployerRole,
runOrder: 2,
}), |
@markusl can you maybe push your code (with whatever edits you need to do to keep it anonymized, of course) to a GitHub repo, so I can clone it and see the failures? We can't reproduce the error you're getting on our side. Thanks, |
@skinny85 here's a bare bones recreation on my machine: https://github.com/martzcodes/aws-recreate-issue $ node --version
v12.13.1
$ npm --version
6.12.1
$ cdk --version
1.27.0 (build a98c0b3) Also note:
and
|
@skinny85 I was trying to narrow this down to as little code as possible. Unfortunately our infrastructure stacks are quite large which means I'm unable to share a full repro. However, commenting out the following snippet in one of our stacks makes the error disappear: // Stage for a cross-account deployment
const role = iam.Role.fromRoleArn(stack, 'DeployerRole', DevAccountDeployerRoleArn);
pipeline.addStage({
stageName: 'DeployDev',
actions: [
new codepipeline_actions.CloudFormationCreateUpdateStackAction({
stackName: 'project-dev-cluster',
account: DevAccountNumber,
region: 'eu-central-1',
actionName: 'UpdateDevCluster',
templatePath: new codepipeline.ArtifactPath(buildOutput, 'project/cdk.out/project-dev-cluster.template.json'),
role,
adminPermissions: false,
deploymentRole: role,
capabilities: [cloudformation.CloudFormationCapabilities.NAMED_IAM]
}),
]
}); |
@markusl can you check if commenting out this line: role, makes the error disappear? |
Thanks for the repo @martzcodes , but yours is a different error, and a pretty obvious case of mixing multiple versions of the CDK in one app.
|
Yes, that does it! Is there something we should change in our code to make this work with the latest version of CDK? |
@markusl if you can't share your entire code, can you at least share you |
Well at the crux of it @markusl reported the error of |
Running
which is a different error. Your "@aws-cdk/aws-lambda": "^1.30.0",
"@aws-cdk/core": "1.27.0", Can you let me know if the error goes away if you unify the version to |
Added a repro here https://github.com/markusl/temp-aws-issue-repro |
@markusl thanks. I see you're not using a local CDK CLI in your |
The error seems to stay even when I'm using
if that's what you meant. |
I cannot reproduce the error, even using your |
Nope. Here's what I get when running that code:
Can you push the entire example (including |
Hi! I removed some comments for clarity. A minified example of the problem is here: https://github.com/markusl/temp-aws-issue-repro I tried it with two Macbooks and could reproduce it on both. |
@markusl managed to repro with your example. Thanks for taking the time. Investigating... |
Got it. This is indeed a bug! The IAM role you are importing is from a different account. Therefore, The culprit is that aws-cdk/packages/@aws-cdk/aws-codepipeline-actions/lib/cloudformation/pipeline-actions.ts Line 517 in 4501b8b
In 1.29.0, due to some constraints when we extracted constructs into an outside library, we had to change the way nodes are associated with constructs and therefore it is now impossible to downcast objects that implement |
Created aws/constructs#16 |
There is another place in the framework that may be susceptible to this:
|
Due to a change in how `ConstructNode`s are associated with `Construct`s in 1.29.0, `ImmutableRole`'s "impersonation to a construct" -- by reflecting the construct's `node` property -- no longer works. This change simply turns `ImmutableRole` into a real construct by extending the `Construct` base class. This fixes the use case in #6885
Okay, after some investigation. This is the only case in our codebase that performs this "forced downcast" ( Therefore, I am opting to simply fix this case by changing |
@markusl I also have a super hacky workaround for you: const role = iam.Role.fromRoleArn(stack, 'DeployerRole', deployerRoleArn);
// associate the role to a construct node
Object.defineProperty(role, Symbol.for('constructs.Construct.node'), {
value: (role.node as any)._actualNode
}); |
@eladb that seems to do the trick. Huge thanks for looking into this on Saturday! |
Glad to hear it works. |
When `Node.of()` is called with an object that does not really extend `Construct`, we can't find the associated construct node. This change improves the error message to provide some hint for why this could happen. Fixes #16 Related aws/aws-cdk#6885
When `Node.of()` is called with an object that does not really extend `Construct`, we can't find the associated construct node. This change improves the error message to provide some hint for why this could happen. Fixes #16 Related aws/aws-cdk#6885
* fix(dam): immutable role cannot be used as a construct Due to a change in how `ConstructNode`s are associated with `Construct`s in 1.29.0, `ImmutableRole`'s "impersonation to a construct" -- by reflecting the construct's `node` property -- no longer works. This change simply turns `ImmutableRole` into a real construct by extending the `Construct` base class. This fixes the use case in #6885 * memoize immutable role so it can be called any number of times
ImmutableRole should never have been a construct, but because this is now law and because of backwards compatibility, we can't undo this anymore. |
Hi!
After upgrading to CDK 1.29.0 we are seeing the following error:
Reproduction Steps
A full repro here https://github.com/markusl/temp-aws-issue-repro
Environment
This is 🐛 Bug Report
The text was updated successfully, but these errors were encountered: