Preventing an IAM user from overriding launch template parameters on RunInstance

I'm trying to set up an IAM policy that allows a user to run an instance (ec2:RunInstances), but only from a specific launch template - and without making any changes to that launch template's parameters.

The relevant section of my policy looks like this:

{
  "Effect": "Allow",
  "Action": "ec2:RunInstances",
  "Resource": "*",
  "Condition": {
    "ArnLike": {
      "ec2:LaunchTemplate": "arn:aws:ec2:ap-southeast-2:xxxxxxx:launch-template/lt-xxxxxxx"
    },
  }
}

This works great. Running the following using the user's credentials works:

aws ec2 run-instances --launch-template LaunchTemplateName=test

...and specifying a different launch template fails. So far so good.

However, the user can override values in the launch template, and pretty much do whatever they like:

aws ec2 run-instances --launch-template LaunchTemplateName=test --instance-type t2.micro

This is despite me setting the instance type in the launch template as t2.nano.

The documentation has a solution for this: require the ec2:IsLaunchTemplateResource condition to be "true", which apparently only is so if the user has not overridden the launch template.

Perfect - exactly what I was after! The Condition statement in my IAM policy now looks like this:

"Condition": {
    "ArnLike": {
      "ec2:LaunchTemplate": "arn:aws:ec2:ap-southeast-2:xxxxxxx:launch-template/lt-xxxxxxx"
    },
    "Bool": {
      "ec2:IsLaunchTemplateResource": "true"
    }
  }

However, with this additional condition present, the RunInstances call fails even if the user makes no changes. After decoding the authorization failure message, I can see that AWS is reporting ec2:IsLaunchTemplateResource was not "true":

{
  "key": "ec2:IsLaunchTemplateResource",
  "values": {
    "items": [
      {
        "value": "false"
      }
    ]
  }
}

EDIT: After posting this, I continued to iterate, and noticed that the specific resource that was hitting up against this issue was th

Alternatively, is there another way I could allow an IAM user to launch an instance in line with a template, while preventing them from making changes (such as choosing a super-expensive instance type)?

I've encountered this problem last year and have circulated up to our AWS account's architect, who contacted their IAM division.

AWS's response is that this is intended behavior. Reason given was that "An instance-type spec on a launch template is not a resource, or conditional that can be used to granted/deny permissions to". Notice that inside the IAM policy, specifying a launch template is a condition to action "RunInstance", and the resource of said policy is an ec2 instance.

According to AWS IAM team, in order for you to restrict instance-type (a condition on the resource, "instance"), you must specify the restriction as part of the condition clause to be applied to the instance, like the following:

{
  "Effect": "Allow",
  "Action": "ec2:RunInstances",
  "Resource": "*",
  "Condition": {
    "ArnLike": {
      "ec2:LaunchTemplate": "arn:aws:ec2:ap-southeast-2:xxxxxxx:launch-template/lt-xxxxxxx"
    },
    "Bool": {
      "ec2:IsLaunchTemplateResource": "true"
    },
    "StringNotLikeIfExists": {
      "ec2:InstanceType": [
        "c5.*xlarge",
        "p3.*xlarge"
      ]
    }
  }
}

Obviously, it is near impossible to list all of the expensive instances we don't want our users to use, and kinda defeats the purpose of using a launch template. But in a messed-up way, in the IAM world AWS created, this actually makes sense.

Consider the docs here: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ExamplePolicies_EC2.html#iam-example-runinstances-launch-templates

Note the language: The policy uses the ec2:IsLaunchTemplateResource condition key to prevent users from overriding any of the launch template resources in the RunInstances request. So that clause only applies to resources (like NICs, IPs, etc), but not instance-type, which is not considered as a resource.

I asked that they revise their docs to explain this, and of course, nothing's changed.

StackExchange DevOps Q#4415, answer score: 1