iam: assumed_by=lambda_function returns Action 'undefined' is invalid RuntimeError

[alexpulver]

Describe the bug

I have the following role definition in Python:

<snip>
iam_policy_document = iam.PolicyDocument(
    statements=[
        iam.PolicyStatement(
            effect=iam.Effect.ALLOW,
            actions=["sts:AssumeRole"],
            resources=[f"arn:aws:iam::{self.account}:role/*"],
        )
    ]
)
iam.Role(
    self,
    "ServicePrincipal",
    role_name="TokenVendingMachineAPI",
    assumed_by=lambda_function,
    inline_policies={"AssumeRolesSameAccount": iam_policy_document},
)

Synthesizing this code leads to the following error:

RuntimeError: Action 'undefined' is invalid. An action string consists of a service namespace, a colon, and the name of an action. Action names can include wildcards.

If I change the colon to any other character, e.g. dash, AWS CDK prints the value and not undefined (even though it is a valid error this time):

RuntimeError: Action 'sts-AssumeRole' is invalid. An action string consists of a service namespace, a colon, and the name of an action. Action names can include wildcards.

Expected Behavior

AWS CDK should synthesize correctly.

Current Behavior

AWS CDK produces the following stack trace with error:

jsii.errors.JavaScriptError: 
  Error: Action 'undefined' is invalid. An action string consists of a service namespace, a colon, and the name of an action. Action names can include wildcards.
      at PolicyStatement.validatePolicyActions (/private/var/folders/z2/db8bn7_s0534kt3hj2ds_82c0000gr/T/jsii-kernel-a7e3Lz/node_modules/aws-cdk-lib/aws-iam/lib/policy-statement.js:2:2518)
      at PolicyStatement.addActions (/private/var/folders/z2/db8bn7_s0534kt3hj2ds_82c0000gr/T/jsii-kernel-a7e3Lz/node_modules/aws-cdk-lib/aws-iam/lib/policy-statement.js:2:402)
      at new PolicyStatement (/private/var/folders/z2/db8bn7_s0534kt3hj2ds_82c0000gr/T/jsii-kernel-a7e3Lz/node_modules/aws-cdk-lib/aws-iam/lib/policy-statement.js:1:1494)
      at Object.defaultAddPrincipalToAssumeRole (/private/var/folders/z2/db8bn7_s0534kt3hj2ds_82c0000gr/T/jsii-kernel-a7e3Lz/node_modules/aws-cdk-lib/aws-iam/lib/private/assume-role-policy.js:1:316)
      at createAssumeRolePolicy (/private/var/folders/z2/db8bn7_s0534kt3hj2ds_82c0000gr/T/jsii-kernel-a7e3Lz/node_modules/aws-cdk-lib/aws-iam/lib/role.js:1:12038)
      at new Role (/private/var/folders/z2/db8bn7_s0534kt3hj2ds_82c0000gr/T/jsii-kernel-a7e3Lz/node_modules/aws-cdk-lib/aws-iam/lib/role.js:1:1617)
      at Kernel._create (/private/var/folders/z2/db8bn7_s0534kt3hj2ds_82c0000gr/T/tmphhc0xnci/lib/program.js:9959:29)
      at Kernel.create (/private/var/folders/z2/db8bn7_s0534kt3hj2ds_82c0000gr/T/tmphhc0xnci/lib/program.js:9688:29)
      at KernelHost.processRequest (/private/var/folders/z2/db8bn7_s0534kt3hj2ds_82c0000gr/T/tmphhc0xnci/lib/program.js:11539:36)
      at KernelHost.run (/private/var/folders/z2/db8bn7_s0534kt3hj2ds_82c0000gr/T/tmphhc0xnci/lib/program.js:11499:22)

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/Users/apulver/Code/api/app.py", line 26, in <module>
    API(
  File "/Users/apulver/.pyenv/versions/3.9.11/envs/api-3.9.11/lib/python3.9/site-packages/jsii/_runtime.py", line 112, in __call__
    inst = super().__call__(*args, **kwargs)
  File "/Users/apulver/Code/api/component.py", line 37, in __init__
    self._create_service_principal_role(lambda_function)
  File "/Users/apulver/Code/api/component.py", line 99, in _create_service_principal_role
    iam.Role(
  File "/Users/apulver/.pyenv/versions/3.9.11/envs/api-3.9.11/lib/python3.9/site-packages/jsii/_runtime.py", line 112, in __call__
    inst = super().__call__(*args, **kwargs)
  File "/Users/apulver/.pyenv/versions/3.9.11/envs/api-3.9.11/lib/python3.9/site-packages/aws_cdk/aws_iam/__init__.py", line 11916, in __init__
    jsii.create(self.__class__, self, [scope, id, props])
  File "/Users/apulver/.pyenv/versions/3.9.11/envs/api-3.9.11/lib/python3.9/site-packages/jsii/_kernel/__init__.py", line 334, in create
    response = self.provider.create(
  File "/Users/apulver/.pyenv/versions/3.9.11/envs/api-3.9.11/lib/python3.9/site-packages/jsii/_kernel/providers/process.py", line 362, in create
    return self._process.send(request, CreateResponse)
  File "/Users/apulver/.pyenv/versions/3.9.11/envs/api-3.9.11/lib/python3.9/site-packages/jsii/_kernel/providers/process.py", line 339, in send
    raise RuntimeError(resp.error) from JavaScriptError(resp.stack)
RuntimeError: Action 'undefined' is invalid. An action string consists of a service namespace, a colon, and the name of an action. Action names can include wildcards.

Subprocess exited with error 1

Reproduction Steps

Try to define a role per below.

<snip>
iam_policy_document = iam.PolicyDocument(
    statements=[
        iam.PolicyStatement(
            effect=iam.Effect.ALLOW,
            actions=["sts:AssumeRole"],
            resources=[f"arn:aws:iam::{self.account}:role/*"],
        )
    ]
)
iam.Role(
    self,
    "ServicePrincipal",
    role_name="TokenVendingMachineAPI",
    assumed_by=lambda_function,
    inline_policies={"AssumeRolesSameAccount": iam_policy_document},
)

Possible Solution

No response

Additional Information/Context

No response

CDK CLI Version

2.69.0 (build 60a5b2a)

Framework Version

2.69.0

Node.js Version

v16.16.0

OS

macOS

Language

Python

Language Version

Python (3.9.11)

Other information

No response

[alexpulver]

I found the root cause. I should've used lambda_function.role instead of lambda_function for assumed_by=. Missed the fact that the Lambda function doesn't implement IPrincipal. Is it possible to improve the error message to explain this?

[pahud]

I actually tested it with TypeScript and I have to use func.grantPrincipal rather than the func

I am not sure if we can improve the experience here with Python as it is not strongly typed.

[alexpulver]

@pahud learned about func.grantPrincipal, thank you 😃. If func.role is a Role, it implements IPrincipal, so should work as well. If func.role is an IRole, I am not sure 😃. If func.role is an object obtained using Role.fromRoleArn() or Role.fromRoleName(), relying on func.role might throw an error (didn't test).

Does that mean that the safe way to reference Role principal is to always use Role.grantPrincipal? Role example uses Role object as the grantee, and not Role.grantPrincipal.