(scheduler-targets-alpha): Don't add default policy if role is passed to target

[nicklocascio45]

Describe the feature

When I create an IAM role myself for the LambdaInvoke target, a redundant default policy is automatically attached to the role.

For example, I create a role similar to the following:

effect=iam.Effect.ALLOW,
actions=[
    'lambda:InvokeFunction'
],
resources=[
    f'arn:aws:lambda:{self.region}:{self.account}:function:testingfunction*'
]

I then want to use this role for multiple schedules that are each attached to a function with the same prefix (i.e. testingfunction1, testingfunction2, etc.). Currently, a default policy is automatically created and attached to my role along these lines:

"Action": "lambda:InvokeFunction",
"Resource": [
    "arn:aws:lambda:<region>:<account>:function:testingfunction1",
    "arn:aws:lambda:<region>:<account>:function:testingfunction2",
    "arn:aws:lambda:<region>:<account>:function:testingfunction1:*",
    "arn:aws:lambda:<region>:<account>:function:testingfunction2:*"
],
"Effect": "Allow"

Use Case

In order to maintain clean IAM roles without redundancies. If someone is manually creating a role, in my mind that implies that they know what permissions they would like to attach and want to avoid any automated permissions creation. If you just want the construct to take care of role creation for you, then you wouldn't attach a role and everything can continue to function as it is currently.

Proposed Solution

No response

Other Information

No response

Acknowledgements

• I may be able to implement this feature request
• This feature might incur a breaking change

CDK version used

2.147.1

Environment details (OS name and version, etc.)

Windows Subsystem for Linux (Ubuntu 22.04.4)

[khushail]

hey @nicklocascio45 ,thanks for reaching out.

I am not really sure I understand your issue here. You mentioned that you are creating a role and policies get attached itself ?? It would be helpful if you could please share a complete sample repro code

[nicklocascio45]

Hi @khushail here is the step-by-step of what I'm doing with a simplified version of the code that includes all they key details:

1. I create a role to allow scheduler to invoke any function with a prefix of testing:

scheduler_role = iam.Role(self, id='SchedulerRole',
    role_name='TestingSchedulerRole',
    assumed_by=iam.ServicePrincipal('scheduler.amazonaws.com'),
    inline_policies={
        'invoke-lambda-policy': iam.PolicyDocument(
            statements=[
                iam.PolicyStatement(
                    effect=iam.Effect.ALLOW,
                    actions=['lambda:InvokeFunction'],
                    resources=[f'arn:aws:lambda:{self.region}:{self.account}:function:testing*'],
                )
            ]
        )
    }
)

2. I then have a custom construct that creates a lambda function and attaches a schedule to it:

class ScheduledLambda(Construct):
    def __init__(self, scope: Construct, id: str, props: ScheduledLambdaProps, **kwargs):
        super().__init__(scope, id, **kwargs)

        function = _lambda.DockerImageFunction(
            self,
            id = props.func_name,
            function_name=props.func_name,
            code=_lambda.DockerImageCode.from_image_asset(
                directory=props.base_directory
            ),
            role=props.func_role,
        )

        schedule = scheduler.Schedule(
            self,
            id=f'{props.func_name}_schedule',
            schedule_name=f'{props.func_name}_schedule',
            schedule=scheduler.ScheduleExpression.cron(props.cron),
            target=scheduler_targets.LambdaInvoke(
                func=function,
                role=props.scheduler_role
            )
        )

3. I then create an arbitrary number of these ScheduledLambda functions with a prefix of testing like so:

for i in range(3):
  ScheduledLambda(
      self,
      id=f'testing{i},
      props=ScheduledLambdaProps(
          base_directory=base_directory,
          func_name=f'testing{i}',
          func_role=func_role,
          scheduler_role=scheduler_role 
      )
  )

What I'm saying is that my scheduler_role should be sufficient to allow any schedule that it's attached to to invoke any function that I create as long as there is a prefix of testing. However, what is actually occurring is that CDK is creating my role and then automatically attaching an additional policy to that role like I outlined above:

"Action": "lambda:InvokeFunction",
"Resource": [
    "arn:aws:lambda:<region>:<account>:function:testing1",
    "arn:aws:lambda:<region>:<account>:function:testing2",
    "arn:aws:lambda:<region>:<account>:function:testing1:*",
    "arn:aws:lambda:<region>:<account>:function:testing2:*"
],
"Effect": "Allow"

This additional policy is redundant as I am already allowing the InvokeFunction action on any function with a prefix of testing.

When you create a Lambda function, if you don't pass in a role CDK automatically creates a role for you. However, if you do pass in a role, CDK doesn't do any additional policy creation for that role. I'm suggesting that this should behave in the same way.

[khushail]

Thanks for sharing the repro code @nicklocascio45 .

Hereis a mention how CDK automatically grants permissions and how you can opt out of automatic role assignment. Please feel free to let me know if its different that what you are requesting .

[nicklocascio45]

@khushail Ah I apologize I never knew that was an option and totally missed it in the documentation. I believe that is what I'm looking for! Thank you very much, apologies again for the unnecessary issue.

[khushail]

No problem @nicklocascio45!! Happy to know it was helpful. :)
I am closing this request

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

[aws-cdk-automation]

Comments on closed issues and PRs are hard for our team to see. If you need help, please open a new issue that references this one.