Deploy failed when existing user pool triggered function is removed

I use existing user pool triggers like this.

  my_func:
    handler: handler.my_func
    events:
      - cognitoUserPool:
          pool: testpool
          trigger: PostAuthentication
          existing: true
 ...

However, when I remove one of them and deploy the process fails.
The error messages are

Failed to delete resource. User: arn:aws:sts::****:assumed-role/prjectname-IamRoleCustomResourcesLambdaEx-*****/prjectname-custom-resource-existing-cup is not authorized to perform: lambda:RemovePermission on resource

The version is 1.50.0

Probably some setting of iam is not enough.
Can this be solved by my definition in serverless.yml?
Please kindly advise.

Thanks.

2 Likes

Very similar, but I got this

Failed to create resource. User: arn:aws:sts::845110609621:assumed-role/propswap-jeanc-IamRoleCustomResourcesLambdaExecuti-1BXRS6XB57ESY/propswap-jeanc-custom-resource-existing-cup is not authorized to perform: iam:PassRole on resource: arn:aws:iam::845110609621:role/propsw3a762d80_sns-role-jeanc See details in CloudWatch Log: 2019/08/23/[$LATEST]5ad3be449c4f4e84a5835cdc4c5a2a53

With the following:

userAfterAuthenticate:
  timeout: 61
  handler: handlers/user/afterAuthenticate.js
  events: 
    - cognitoUserPool:
        pool: ${file(amplify/custom.js):custom.user_pool_name}
        trigger: PostAuthentication
        existing: true

I’m getting a similar problem on 1.50.0.

Serverless Error ---------------------------------------
 
  An error occurred: PreSignUpCustomCognitoUserPool1 - Failed to create resource. User: arn:aws:sts::[num]:assumed-role/ttw3-cognito-triggers-liv-IamRoleCustomResourcesLa-9S662UBZG46B/ttw3-cognito-triggers-live2-custom-resource-existing-cup is not authorized to perform: iam:PassRole on resource: arn:aws:iam::[num]:role/[rol] See details in CloudWatch Log: 2019/08/24/[$LATEST]8062f5ca32e947f6a06a0e36a5284457.

preSignUp:
handler: handler.autoConfirmUser
events:
  - cognitoUserPool:
      pool: ${self:provider.environment.COGNITO_POOL}
      trigger: PreSignUp
      existing: true

@zacharywenner
Thank you for opening the issue!

I first mentioned that it happened when I removed a function, but as you say, another similar problem occurred when I deploy.
The problem occurred when I enabled Multi-Factor Authentication and provided a role to allow Amazon Cognito to send SMS messages.

Failed to create resource. User: arn:aws:sts::***:assumed-role/my-project-IamRoleCustomResourcesLambdaExecut-***/my-project-custom-resource-existing-cup is not authorized to perform: iam:PassRole on resource: arn:aws:iam::***:role/service-role/myUserPool-SMS-Role See details in CloudWatch Log: 2019/08/27/[$LATEST]***
1 Like

Having the same issue after removing a handler from the serverless.yml file that had an event referencing an existing cognito user pool. This occurs after deploying the handler function successfully, then removing the function handler definition (in its entirety) from the serverless.yml file and attempting to re-deploy.

An error occurred: CognitoCustomMessageHandlerCustomCognitoUserPool1 - Failed to delete resource. User: arn:aws:sts::ACCOUNTID:assumed-role/dev-opal-users-IamRoleCustomResourcesLambdaExecuti-18KXQ6A3U9B54/opal-users-dev-custom-resource-existing-cup is not authorized to perform: lambda:RemovePermission on resource: arn:aws:lambda:us-east-1:ACCOUNTID:function:opal-users-dev-cognitoCustomMessageHandler

If I check the offending IamRole, it does indeed have the correct permissions after deploying the functions. But when I remove the entire function from the serverless.yml file, I believe the opal-users-dev-custom-resource-existing-cup resource (created by the Serverless Framework) has it’s permissions removed BEFORE it attempts to do its work on the function handler that I removed (but fails since it no longer has permissions). Seems like an issue with order of operations, but no idea how to resolve.

1 Like

Eventually, now I deal with it by deleting the description below “event:” and manually linking triggers after deployment…