Should an AWS Lambda trust-policy be narrowly scoped?

Question

Should trust policies for AWS Lambda be narrowly scoped, and how can this be implemented (e.g. using Terraform)?

Using Terraform I ran into a cyclic dependency problem as follows: an AWS Lambda function resource must specify an IAM role. An IAM role must specify an assume role (trust) policy. I wanted to put a condition in the trust policy that would restrict use of that role to this specific Lambda, like:

data "aws_iam_policy_document" "trust_policy" {
  statement {
    actions = ["sts:AssumeRole"]
    principals {
      type        = "Service"
      identifiers = ["lambda.amazonaws.com"]
    }
    condition {
      test     = "StringEquals"
      variable = "lambda:FunctionArn"
      values   = [aws_lambda_function.myfunction.arn]
} } }

This creates a cyclic reference, and hence a Terraform error. (Frankly, it seems like this error shouldn't be a problem, as one can predict the ARNs for both the Lambda function and the IAM role before they have been created, and even if that weren't true, it ought also be possible to initially create the resources without the cyclic reference and then update the configuration to achieve the desired state.)

I presume it isn't a common practice to include this sort of condition. Is there some reason why one wouldn't want to narrowly scope the trust policy (and prevent another lambda, say one that has been hijacked via some vulnerability, from assuming the role intended for this lambda and thereby escalating privileges)?

Answer 1

The threat model you are trying to mitigate is not particularly clear. A lambda, however compromised, will only ever have the role assigned to it. The hacker would need to attack the AWS infrastructure itself, in which case fiddly IAM permissions are NOT going to help.

This would really only prevent (in an extremely confusing way) someone with permission to assign roles to lambdas in AWS, from assigning this role to other lambdas. Perhaps if you were trying to prevent an extremely hazardous misconfiguration or something it would make sense. Possibly if you were allowing less other users restricted access to the AWS account, although IAM provides much better ways to accomplish this.

Anyways, you are correct that this is not a particularly common thing to do, and is resolutely not worth fighting with terraform over. If you actually NEED to do it, you could just edit the policy after terraform finishes. Or you could give the lambda a static name and put the ARN directly into the policy without a variable.