Kops: Allow using AWS Instance Metadata Service Version 2 (IMDSv2) in InstanceGroups

[MichaelJDrK]

1. Describe IN DETAIL the feature/behavior/change you would like to see.

In AWS EC2 instances there is an Instance Metadata Service with Version 1 and Version 2
(https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html).

You can enforce usage of IMDSv2 (=disallow v1) setting "HttpTokens" to "required". Or you can turn off IMDS by setting "HttpEndpoint" to "disable".

AWS Foundational Security Best Practices v1.0.0 requires usage of IMDSv2 only with a severity of HIGH (see remediation instructions: https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-standards-fsbp-controls.html#ec2-8-remediation)

For compliance and security reasons it should be possible to change this setting for an instancegroup (like "httpTokens: required" or something like that.

[rifelpet]

I think this would be pretty straight forward to add. The main decision would be around the new API fields and their names. AWS, GCP, and Alibaba cloud use the term instance metadata, DO uses droplet metadata and Openstack seems to just use metadata. I think we could settle on instanceMetadata as a new section in the InstanceGroupSpec. I didn't want to just use metadata because it could be confused with the cluster resource's metadata itself.

spec:
  instanceMetadata:
    httpPutResponseHopLimit: 1
    httpTokens: required

Some kops and k8s components require access to instance metadata, so I don't think we should support disabling it altogether but we could definitely support requiring IMDSv2 (httpTokens = required) and adjusting the hop limit.

I think adding this would be pretty straight forward and roughly follow the docs we have.

• API + validation updates. If the new values are set:
  
  
  
  • Ensure we're on AWS
  
  
  • Ensure the LaunchTemplates feature flag isn't disabled which would fallback to launch configurations which don't support IMDSv2.
  
  

• Add the new fields to the LaunchTemplate task and pass it into the aws api call

• Add terraform and cloudformation support to include the new fields in their types

• Plumb the values from the API into the LT tasks in the model.

• Update the complex integration test to use the new fields and run ./hack/updated-expected.sh to confirm the new values end up in the terraform and cloudformation outputs.

I'm happy to provide more assistance if anyone wants to take this on 👍

[ivanlemeshev]

Hi @rifelpet I would like to take this issue. Could you assign it to me?

[rifelpet]

/assign @ivanlemeshev

[rifelpet]

@ivanlemeshev do you need any assistance with this? Just checking in

[bharath-123]

@rifelpet Would love to work on this if @ivanlemeshev is not actively working on this issue. Getting into the kops codebase nowadays :)

[rifelpet]

@bharath-123 feel free to open a PR

[bharath-123]

@rifelpet I see that launch configurations are able to support only IMDSv2. I am able to create a launch configuration in aws manually with only IMDSv2 enabled. I do think Launch configurations support IMDSv2?

[rifelpet]

Ah, I did not know that. We are moving away from LaunchConfigurations though- 1.19 will default to LaunchTemplates and a few minor releases after that I expect us to drop support for LaunchConfigurations, so I think only implementing this for LTs would be fine.