Support setting EC2 instance metadata to require token (IMDSv2)

[geoffroyrenaud]

Following the announce on the aws security blog about improving SSRF vuln : https://aws.amazon.com/blogs/security/defense-in-depth-open-firewalls-reverse-proxies-ssrf-vulnerabilities-ec2-instance-metadata-service/

Use Case

EC2 instances can be set to require IMDSv2 only.

Proposed Solution

This can be done with running instances or by using correct IAM policy, documentation : https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html#configuring-instance-metadata-options

---

This is a 🚀 Feature Request

[mauricioharley]

Hello, team. What's the progress on this? Does CDK already support directly specifying IMDSv2 for new instances, or do we need to use custom resources?

If custom is the answer, is there any example to follow?

Thanks.

[jumi-dev]

@mauricioharley As long as it is not supported in the ec2 instance construct in CDK, you can use the AwsCustomResource to call SDK method modifyInstanceMetadataOptions. There, you can set the metadata options to enforce IMDSv2.

new cr.AwsCustomResource(this, "InstanceMetadataOptions", {
  onUpdate: {
    service: "EC2",
    action: "modifyInstanceMetadataOptions",
    parameters: {
      InstanceId: myInstance.instanceId,
      HttpEndpoint: 'enabled',
      HttpTokens: 'required'
    },
    region: this.region,
    physicalResourceId: cr.PhysicalResourceId.of(myInstance.instanceId),
  },
  policy: cr.AwsCustomResourcePolicy.fromSdkCalls({
    resources: [`arn:aws:ec2:${this.region}:${this.account}:instance/${myInstance.instanceId}`],
  }),
});

[jumi-dev]

The CloudFormation feature is missing to specifiy the instance metadata. A request is already created:
aws-cloudformation/cloudformation-coverage-roadmap#655

This issue could be flagged with label needs-cfn.

[skinny85]

The CloudFormation feature is missing to specifiy the instance metadata. A request is already created:
aws-cloudformation/aws-cloudformation-coverage-roadmap#655

This issue could be flagged with label needs-cfn.

Sir yes sir! 😃

[richarddotcodes]

Can this issue be updated with the current status? I'm interested in using higher level constructs (like the ASG) to set metadata options, but I'm not seeing a path forward after navigating through the various linked issues.

Is this still blocked by CloudFormation? The following docs appear to show it's now supported:

https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-as-launchconfig.html#cfn-autoscaling-launchconfig-metadataoptions

[rix0rrr]

@richarddotcodes you are right this can now be implemented. This means you can now use the regular Escape Hatching mechanism of CDK to configure these options, or someone can submit a PR to add the feature.

Example escape hatching code:

const launchConfig = autoScalingGroup.node.tryFindChild('LaunchConfig') as autoscaling.CfnLaunchConfiguration;

launchConfig.metadataOptions = { httpTokens: 'required' };
// OR
launchConfig.addPropertyOverride('MetadataOptions', {
  HttpTokens: 'required',
});

[rix0rrr]

An Aspect that applies the change for all ASGs and EC2 instances would be a welcome addition, but those could equally well be two different PRs.

[richarddotcodes]

I'd be happy to tackle this one. I agree that applying the change at larger scopes could be different PRs, so if all goes well, maybe I can take those later too.

[alexjfisher]

Is this still blocked by CloudFormation? The following docs appear to show it's now supported:

https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-as-launchconfig.html#cfn-autoscaling-launchconfig-metadataoptions

That looks like for EC2s created by ASGs only. Regular EC2 instances seem to still be missing this feature and aws-cloudformation/cloudformation-coverage-roadmap#655 is still open.

[alexjfisher]

I've been able to create an EC2 with IMDSv2 using launch templates.
CDK could possibly make this easier, but the following seems to work for me.

const launchTemplate = new ec2.LaunchTemplate(this, 'LaunchTemplate', {});

// The LaunchTemplate construct doesn't support setting the metadata options, so escape hatch time...
const CfnLaunchTemplate = launchTemplate.node.defaultChild as ec2.CfnLaunchTemplate;

CfnLaunchTemplate.launchTemplateData = {
  metadataOptions: {
    httpTokens: 'required',
  }
}

const myEC2= new ec2.Instance(this, 'Instance', {
  vpc,
  // etc.
}

// The Instance construct doesn't support setting the launch template, so break out _again_...
const CfnMyEC2 = myEC2.node.defaultChild as ec2.CfnInstance;

CfnMyEC2.launchTemplate = {
  launchTemplateId: launchTemplate.launchTemplateId,
  version: launchTemplate.versionNumber,
}

[richarddotcodes]

I've got a change ready that allows setting the metadata options in the autoscaling group construct. I created an interface to wrap the options and am passing it in via the asg props. It made sense to put this interface in the instance construct in aws-ec2, since it's a property of the instances and not asg. The issue I'm facing is that the ec2 tests fail awslint because I'm exporting this interface (for use in aws-autoscaling), but not using it directly in the instance class in instance.ts.

Any thoughts on my approach?

[richarddotcodes]

Checking in again. If I could get some feedback to unblock this change, it would be much appreciated. Thanks!

[jericht]

I also need this for AutoScalingGroup, Instance, and LaunchTemplate as well. It would be great to have options for these directly in the construct interfaces instead of having to escape hatch into the underlying L1 constructs.

An Aspect that applies the change for all ASGs and EC2 instances would be a welcome addition, but those could equally well be two different PRs.

@rix0rrr I'm currently implementing an Aspect that would achieve this for the AutoScalingGroup, Instance, and LaunchTemplate constructs, but I'm not sure where this Aspect should go. It's going to be dependent on a few of the service construct libraries (@aws-cdk/aws-ec2 and @aws-cdk/aws-autoscaling), so it probably shouldn't go in @aws-cdk/core. Does it make sense to make a new package like @aws-cdk/aspects for this? or maybe just a generic @aws-cdk/utils package?

Thought about this again, maybe it makes more sense to have different Aspects that achieve this per construct supported. Then, they could just exist in the corresponding service construct library. Instead of my original idea of having a single Aspect to handle all constructs that support the option to require IMDSv2, we'll just have one for each construct listed above. I think I'll start with this idea and create a PR, then go from there.

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

[Miradorn]

As i see it this is only fixed for ASG as of #16052 and not for ec2 (see #16051 for that). Correct?