Role.fromRoleArn(mutable: false) creates constructs with the wrong ID

[rix0rrr]

This PR:

#6920

Broke the following piece of code:

    const existingRole = scope.node.tryFindChild(id) as iam.IRole;
    if (existingRole) {return existingRole; }
   return iam.Role.fromRoleArn(scope, id, arn, { mutable: false });

One would expect the second execution of this code to return the same immutable role that was created on the first go-around.

But in fact, because we create 2 constructs, the mutable one of which has the ID the user requested, the first go-around will return the immutable role as desired, but the second go-around will return the inner, mutable role object, leading to policies being added to a supposedly immutable role.

---

This is 🐛 Bug Report

[eladb]

Wow, that's pretty hairy! Any suggestions on how to fix?

[eladb]

@rix0rrr do you think this should also work:

const role = stack.node.findChild(uid) as iam.Role ?? new iam.Role(this, uid).withoutPolicyUpdates();

If that's the case, we will need a deeper refactor. If it's only for the fromRoleArn use case, we can probably hack something a bit simpler.

[rix0rrr]

Seems to me that a simple fix would be to reverse the IDs assigned to the Import and the ImmutableRole here: https://github.com/aws/aws-cdk/pull/6920/files#diff-a1dcc3d014e6654b6527e0a2e24d7812R238

[rix0rrr]

Ideally ImmutableRole wouldn't have been made a Construct in #6920 but the consumer side would have been fixed, but I haven't looked into the triggering issue enough to know whether that was even feasible or not.

[github-actions]

⚠️COMMENT VISIBILITY WARNING⚠️

Comments on closed issues are hard for our team to see.
If you need more assistance, please either tag a team member or open a new issue that references this one.
If you wish to keep having a conversation with other community members under this issue feel free to do so.