iam: role arn parsed incorrectly

[phch]

Describe the bug

I am using the following code to grant index read/write from an imported role to an imported domain.
The role that I am using follows the structure: arn:aws:iam::<account>:role/<project-name>/<role-name>
When I use the following piece of CDK code, it fails saying it cannot find the role called <project-name>.

It seems like it's incorrectly parsing out the role for this policy.

Example of the Typescript CDK code:

const domain = Domain.fromDomainAttributes(node, 'imported-opensearch-domain', this.domainAttributes);
const lambdaFunctionRole = Role.fromRoleArn(node, 'imported-role', node.attrArn);
domain.grantIndexReadWrite('my-index', lambdaFunctionRole);

Example of the synthesized CloudFormation:

  "MySamplePolicy": {
   "Type": "AWS::IAM::Policy",
   "Properties": {
    "PolicyDocument": {
     "Statement": [
      {
       "Action": [
        "es:ESHttpDelete",
        "es:ESHttpGet",
        "es:ESHttpHead",
        "es:ESHttpPatch",
        "es:ESHttpPost",
        "es:ESHttpPut"
       ],
       "Effect": "Allow",
       "Resource": [
        "arn:aws:es:us-east-1:<account>:domain/<domain>/<index>",
        "arn:aws:es:us-east-1:<account>:domain/<domain>/<index>/*"
       ]
      }
     ],
     "Version": "2012-10-17"
    },
    "PolicyName": "MySamplePolicy",
    "Roles": [
     {
      "Fn::Select": [
       1,
       {
        "Fn::Split": [
         "/",
         {
          "Fn::Select": [
           5,
           {
            "Fn::Split": [
             ":",
             {
              "Fn::GetAtt": [
               "CustomResourcesRole",
               "Arn"
              ]
             }
            ]
           }
          ]
         }
        ]
       }
      ]
     }
    ]
   }
  },

Expected Behavior

It should grant access correctly for the role to access this domain and be granting access to the full role ARN.

Current Behavior

However, due to some behind-the-scenes logic it splits the ARN incorrectly.

Original - arn:aws:iam::<account>:role/<project-name>/<role-name>
Split on ':', Select 5th element - role/<project-name>/<role-name>
Split on '/', Select 1st element - <project-name>

Reproduction Steps

const domain = Domain.fromDomainAttributes(node, 'imported-opensearch-domain', this.domainAttributes);
const lambdaFunctionRole = Role.fromRoleArn(node, 'imported-role', node.attrArn);
domain.grantIndexReadWrite('my-index', lambdaFunctionRole);

Possible Solution

No response

Additional Information/Context

No response

CDK CLI Version

2.83.1 (build 006b542)

Framework Version

No response

Node.js Version

v18.0.0

OS

MacOS 13.4 Ventura

Language

Typescript

Language Version

No response

Other information

No response

[peterwoodworth]

This is what the code is doing, which doesn't look like it accounts for roles with the type of name that you have

aws-cdk/packages/aws-cdk-lib/aws-iam/lib/role.ts

Lines 255 to 263 in dcf5352

	public static fromRoleArn(scope: Construct, id: string, roleArn: string, options: FromRoleArnOptions = {}): IRole {
	const scopeStack = Stack.of(scope);
	const parsedArn = scopeStack.splitArn(roleArn, ArnFormat.SLASH_RESOURCE_NAME);
	const resourceName = parsedArn.resourceName!;
	const roleAccount = parsedArn.account;
	// service roles have an ARN like 'arn:aws:iam::<account>:role/service-role/<roleName>'
	// or 'arn:aws:iam::<account>:role/service-role/servicename.amazonaws.com/service-role/<roleName>'
	// we want to support these as well, so we just use the element after the last slash as role name
	const roleName = resourceName.split('/').pop()!;

Thanks for reporting

[peterwoodworth]

This is actually documented, and we don't think there's a way to fix it so we'll be closing this out. https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_iam.Role.html#static-fromwbrrolewbrarnscope-id-rolearn-options

[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.