Using STS to generate dynamic SaaS policy for temporary credentials to be used for invoking Lambda

I'm getting a timeout with {"code":"ERR_INVALID_ARG_TYPE"} when trying to invoke a Lambda function from another function. The background is that as part of a SaaS solution, I need to handoff processing of a payload received from API Gateway but having first determined the minimum scope policy required to perform the payload processing. The target lambda is generic and does the same thing for each invocation but to meet security needs, must be scoped down so that under no circumstances could the code accidentally operate beyond the scope of the specific 'tenant' from which the payload originates and that developers maintaining the target lambda code could not accidentally or otherwise call services or process tables / s3 etc that do not belong to the 'tenant'. Code currently looks like this: `let policy = require('./tenantPolicy.json');

let sts = new AWS.STS(); let stsParams = { RoleArn: process.env.tenantRole, //primary execution role RoleSessionName: tenant-${tenantID}, Policy: JSON.stringify(policy), //generated policy DurationSeconds: 900 } let stsResult = await sts.assumeRole(stsParams).promise(); let tenantCred = stsResult.Credentials; let tenantLambdaParams = { FunctionName: process.env.tenantLambda, /* required */ InvocationType: 'RequestResponse', LogType: 'Tail', Payload: JSON.stringify(tenantPayload) };

let tenantLambda = new AWS.Lambda({ credentials: tenantCred }); let tenantResult = await tenantLambda.invoke(tenantLambdaParams).promise();`

If I create the tenantLambda without specifying the credentials, i.e. just using the existing execution credentials, everything is fine. If I use the code above, or directly specify the credentials like this: let tenantCred = { accessKeyId: stsResult.Credentials.AccessKeyId, secretAccessKey: stsResult.Credentials.SecretAccessKey, sessionToken: stsResult.Credentials.SessionToken }

...then I get the error. I can see that STS is generating the credentials OK and logging the dynamic policy out shows me that I'm getting the policy I expect. Code execution in my calling Lambda operates right up to the await of the invoke and then (eventually) near timeout, gives me the error message.

The execution role configured against the caller Lambda has managed policies: ManagedPolicyArns: - !Sub 'arn:${AWS::Partition}:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole' - arn:aws:iam::aws:policy/AmazonDynamoDBFullAccess - arn:aws:iam::aws:policy/AmazonSNSFullAccess - arn:aws:iam::aws:policy/AmazonS3FullAccess - arn:aws:iam::aws:policy/AmazonSESFullAccess - arn:aws:iam::aws:policy/service-role/AWSLambdaRole

and has sts:AssumeRole against the role that is assigned to both the target Lambda is the same role being passed as the role arn to STS with the dynamic policy. This role has: ManagedPolicyArns: - !Sub 'arn:${AWS::Partition}:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole' - arn:aws:iam::aws:policy/AmazonDynamoDBFullAccess - arn:aws:iam::aws:policy/AmazonSNSFullAccess - arn:aws:iam::aws:policy/AmazonS3FullAccess - arn:aws:iam::aws:policy/AmazonSESFullAccess - arn:aws:iam::aws:policy/service-role/AWSLambdaRole

and has trust: `AssumeRolePolicyDocument: Statement: - Effect: Allow Principal: Service: [lambda.amazonaws.com] AWS: !Sub 'arn:aws:iam::${AWS::AccountId}:role/tenantRole-${AWS::AccountId}' Action: sts:AssumeRole'

so that the role can be used in STS by the calling Lambda My dynamic policy also provides access to Lambda basic cloudwatch actions and lambda:InvokeFunction so I don't think it's due to policy intersection.

I also tried NOT sending the dynamic policy at all, just the main role but same result. Has anyone has any luck with something like this? I'm assuming that it's something about my IAM roles that is preventing successful execution. Could there be an iam:PassRole missing that I need to add somewhere?