Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

eks: support for blocking node-level instance metadata #31124

Open
2 tasks
trondhindenes opened this issue Aug 15, 2024 · 5 comments
Open
2 tasks

eks: support for blocking node-level instance metadata #31124

trondhindenes opened this issue Aug 15, 2024 · 5 comments
Labels
@aws-cdk/aws-eks Related to Amazon Elastic Kubernetes Service effort/medium Medium work item – several days of effort feature-request A feature should be added or improved. p2

Comments

@trondhindenes
Copy link

Describe the feature

According to https://aws.github.io/aws-eks-best-practices/security/docs/iam/#restrict-access-to-the-instance-profile-assigned-to-the-worker-node, its strongly recommended to disallow pods accessing the node's instance metadata.

Since this is a strong recommendation, it's troubling that cdk-eks doesn't support this for managed node groups. The only way I can see it possible to do this today, is by specifying a full node template, which kindof defeats the purpose of manage node groups.

Use Case

To follow AWS' best practices

Proposed Solution

Allow supplying an optional "metadata options" object to the node group.

Other Information

No response

Acknowledgements

  • I may be able to implement this feature request
  • This feature might incur a breaking change

CDK version used

2.151.0

Environment details (OS name and version, etc.)

Ubuntu 24

@trondhindenes trondhindenes added feature-request A feature should be added or improved. needs-triage This issue or PR still needs to be triaged. labels Aug 15, 2024
@github-actions github-actions bot added the @aws-cdk/aws-eks Related to Amazon Elastic Kubernetes Service label Aug 15, 2024
@pahud
Copy link
Contributor

pahud commented Aug 15, 2024

Thank you for bringing this to our attention. Except for baking your own launchTemplate for MNG, I didn't see any option out-of-the-box for that in cloudformation. But I noticed this:

EKS adds support IMDSv2 by enabling both v1 and v2 and changing the hop limit to 2 on nodes provisioned by eksctl or with the official CloudFormation templates.

I will reach out internally to see what we can do from CFN's perspective and improve CDK accordingly.

@pahud pahud added p2 and removed needs-triage This issue or PR still needs to be triaged. labels Aug 15, 2024
@pahud
Copy link
Contributor

pahud commented Aug 15, 2024

internal tracking: V1486188294

@pahud pahud added the effort/medium Medium work item – several days of effort label Aug 15, 2024
@pahud
Copy link
Contributor

pahud commented Aug 15, 2024

OK I tried to create a default nodegroup using the code like this:

    new eks.Cluster(this, 'dummy-eks-cluster', {
      clusterName: 'dummy-eks-cluster',
      vpc,
      version: eks.KubernetesVersion.V1_30,
      kubectlLayer: new KubectlV30Layer(this, 'kubectl'),
      defaultCapacity: 1,
    } )

And checked the launchTemplate the manage nodegroup is associated with.

I see this:

image

So I am pretty sure:

  1. the default token hop limit would be 2
  2. there's no props like metadataOptions in AWS::EKS::Nodegroup to allow you to customize that in CFN so CDK won't be able to do that as well.
  3. setting the hop limit to 2 should be generally recommended for compatibility as described here but in some cases if you really have to set it to 1, you need to bake your own launchTemplate and pass it to the manage nodegroup.
  4. If you would like to have AWS::EKS::Nodegroup to include the metadataOptions property, the best place is to submit a FR at https:/aws-cloudformation/cloudformation-coverage-roadmap/issues

Let me know if you have any other concerns.

@pahud pahud added the response-requested Waiting on additional info and feedback. Will move to "closing-soon" in 7 days. label Aug 15, 2024
Copy link

This issue has not received a response in a while. If you want to keep this issue open, please leave a comment below and auto-close will be canceled.

@github-actions github-actions bot added the closing-soon This issue will automatically close in 4 days unless further comments are made. label Aug 17, 2024
@trondhindenes
Copy link
Author

Thanks for checking up on this. The guidance in the eks-best-practices docs are a bit counter-intuitive for me, since it recommends both "1" and "2" as topen-hop limits - its not clear to me when we'd need to set the limit to 2 and when it should be lowered to 1. But that's not CDK's fault. Thanks for checking up on this anyway!

@github-actions github-actions bot removed closing-soon This issue will automatically close in 4 days unless further comments are made. response-requested Waiting on additional info and feedback. Will move to "closing-soon" in 7 days. labels Aug 20, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
@aws-cdk/aws-eks Related to Amazon Elastic Kubernetes Service effort/medium Medium work item – several days of effort feature-request A feature should be added or improved. p2
Projects
None yet
Development

No branches or pull requests

2 participants