-
Notifications
You must be signed in to change notification settings - Fork 4.7k
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
Default IMDSv2 to "optional" for AWS #10655
Conversation
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: hakman The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Maybe we should default to required for new clusters only. I believe that would involve setting it in |
@rifelpet This would mean adding the setting to each IG on creation and may look a bit odd:
|
ce65f8e
to
37a674e
Compare
It would be interesting to know why it fails. It may be one rather wants to increase allowed number of hops. |
I think kube-router is because of the number of hops. |
upup/pkg/fi/cloudup/new_cluster.go
Outdated
if api.CloudProviderID(cluster.Spec.CloudProvider) == api.CloudProviderAWS && (g.Spec.InstanceMetadata == nil || g.Spec.InstanceMetadata.HTTPTokens == nil) { | ||
k8sVersion, err := version.ParseKubernetesVersion(cluster.Spec.KubernetesVersion) | ||
if err == nil && version.IsKubernetesGTE("1.20", *k8sVersion) { | ||
g.Spec.InstanceMetadata = &api.InstanceMetadataOptions{ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this will overwrite InstanceMetadata if it already exists but HTTPTokens is nil. We should probably only create InstanceMetadata if it is nil, otherwise just set HTTPTokens and HTTPPutResponseHopLimit if they arent set.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks. I think this last change should do it.
37a674e
to
512eda8
Compare
upup/pkg/fi/cloudup/new_cluster.go
Outdated
@@ -674,6 +674,16 @@ func setupMasters(opt *NewClusterOptions, cluster *api.Cluster, zoneToSubnetMap | |||
g.Spec.Zones = []string{zone} | |||
} | |||
|
|||
if api.CloudProviderID(cluster.Spec.CloudProvider) == api.CloudProviderAWS && (g.Spec.InstanceMetadata == nil || g.Spec.InstanceMetadata.HTTPTokens == nil) { | |||
k8sVersion, err := version.ParseKubernetesVersion(cluster.Spec.KubernetesVersion) | |||
if err == nil && version.IsKubernetesGTE("1.20", *k8sVersion) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like it will be enabled on new clusters with k8s 1.20+. Do we really need the k8s check here when it is only for new clusters?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I discussed a bit with @rifelpet and he is worried that this may break some existing clusters if operators don't read the release notes.
I would question a bit the requirement for 1.20+ and change to skip for debian 9 and flatcar images.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If the intention is to only do this for new clusters, it won't break any existing ones (I hope)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think historically we've made node-level cloud provider changes by only affecting new clusters and the newly supported k8s version. That way someone creating k8s 1.18 clusters wont have a change in behavior when upgrading from kops 1.18 to 1.19.
This might be especially important for changes that could break workloads like this one.
I don't nt have a particularly strong opinion about this though as long as the release notes make it abundantly clear. Given that this is for 1.20 perhaps we get more input at the mext office hours?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point, Friday it is then. 😄
512eda8
to
12cb288
Compare
as discussed in office hours: |
IMDSv2 breaks any setup using Flatcar or Debian 9 as base image and seems to be the reason kube-router tests stoped working. The change, even though recommended by AWS seems to be highly disruptive in our case and for now should remain optional.
/cc @rifelpet @olemarkus