chore(deps): update terraform cloudposse/eks-node-group/aws to v2.12.0

[renovate]

This PR contains the following updates:

Package	Type	Update	Change
cloudposse/eks-node-group/aws (source)	module	minor	2.4.0 -> 2.12.0

---

Release Notes

cloudposse/terraform-aws-eks-node-group (cloudposse/eks-node-group/aws)

v2.12.0

Compare Source

Add `force_update_version` and `replace_node_group_on_version_update` variables @​aknysh (#​151)

what

• Add force_update_version and replace_node_group_on_version_update variables

why

• force_update_version allows forcing version update if existing pods are unable to be drained due to a pod disruption budget issue. Default is false for backwards compatibility

• If the variable replace_node_group_on_version_update is set to true and the EKS cluster is updated to a new Kubernetes version, the Node Groups will be replaced instead of updated in-place. This is useful when updating very old EKS clusters to a new Kubernetes version where some old releases prevent nodes from being drained (due to PodDisruptionBudget or taint/toleration issues), but replacing the Node Groups works without forcing the pods to leave the old nodes by using the force_update_version variable. This is related, for example, to istio. Default is false for backwards compatibility

references

• https://docs.aws.amazon.com/eks/latest/userguide/managed-node-update-behavior.html
• https://github.com/aws/containers-roadmap/issues/1282

v2.11.0

Compare Source

Better block device support @​Nuru (#​150)

Notable Changes

• With this PR/release, the default type of block device changes from gp2 to gp3. If you were relying on the default, this will cause your node group to change, but it should be without interruption.
• We no longer automatically apply a custom taint to Window nodes. Pods should select (or not) Windows nodes via the kubernetes.io/os tag. If that is not sufficient, you are free to add your own "NO_EXECUTE" taint via kubernetes_taints

what

• Better support for block device mapping
• Update dependency terraform-aws-security-group to current v2.2.0
• Revert portions of #​139

why

• Take advantage of optional() to allow the block device mapping input to be fully specified, with defaults, rather than the previous list(any), which had no type checking and did not advertise which features were or were not supported
• Closes #​134
• Bad practices that were not caught in time

add core_count and threads_per_core options to launch templates @​Dmitry1987 (#​149)

what

added core_count and threads_per_core options in order to run instances with no hyperthreading, for applications that need maximize single core performance (in some cases it's required).

why

the config option is available in the module but was not available in variables

references

https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/launch_template#example-usage

Support AWS Provider V5 @​max-lobur (#​147)

what

Support AWS Provider V5
Linter fixes

why

Maintenance

references

https://github.com/hashicorp/terraform-provider-aws/releases/tag/v5.0.0

Do not sort instance types @​xeivieni (#​142)

what

Remove sorting on instance type list in the node group definition

why

Because the order of the list is used to define priorities on the type of instance to use.

references

• https://github.com/cloudposse/terraform-aws-eks-node-group/issues/135
• https://docs.aws.amazon.com/eks/latest/userguide/managed-node-groups.html

Managed node groups use the order of instance types passed in the API to determine which instance type to use first when fulfilling On-Demand capacity. For example, you might specify three instance types in the following order: c5.large, c4.large, and c3.large. When your On-Demand Instances are launched, the managed node group fulfills On-Demand capacity by starting with c5.large, then c4.large, and then c3.large

Sync github @​max-lobur (#​145)

Rebuild github dir from the template

🤖 Automatic Updates

Update README.md and docs @​cloudpossebot (#​148)

what

This is an auto-generated PR that updates the README.md and docs

why

To have most recent changes of README.md and doc from origin templates

v2.10.0

Compare Source

• No changes

v2.9.1

Compare Source

Use cloudposse/template for arm support @​nitrocode (#​129)

what

• Use cloudposse/template for arm support

why

• The new cloudposse/template provider has a darwin arm binary for M1 laptops

references

• https://github.com/cloudposse/terraform-provider-template
• https://registry.terraform.io/providers/cloudposse/template/latest

🚀 Enhancements

fix: variable description for var.bootstrap_additional_options @​venkatamutyala (#​144)

what

• Fixing variable description as it references another variable that doesn't exist.

why

Should save someone time in the future when they try and find the variable as mentioned in the description.

v2.9.0

Compare Source

Groundwork new workflows @​max-lobur (#​143)

Fix lint/format before workflows rollout

v2.8.0

Compare Source

Windows node support @​ChrisMcKee (#​139)

what

• Adds support for 2019/2022 (windows lts) ami-types as per the aws sdk docs
• Docs to support usage and link to ref docs https://docs.aws.amazon.com/eks/latest/userguide/windows-support.html

why

• Windows EKS Managed node support https://github.com/aws/containers-roadmap/issues/584

references

• https://docs.aws.amazon.com/eks/latest/userguide/windows-support.html
• https://docs.aws.amazon.com/eks/latest/userguide/eks-ami-versions-windows.html

Tested

module "eks_windows_node_group" {

### source  = "cloudposse/eks-node-group/aws"
### version = "2.6.1"
  source = "github.com/ChrisMcKee/terraform-aws-eks-node-group"

  instance_types     = ["t3.large", "t3a.large", "c5.large", "c6i.large", "m6i.large", "r6i.large"]
  subnet_ids         = [data.terraform_remote_state.network.outputs.private_subnets[1]]
  min_size           = 1
  max_size           = 1
  desired_size       = 1
  cluster_name       = module.eks_cluster.eks_cluster_id
  kubernetes_version = var.kubernetes_version == null || var.kubernetes_version == "" ? [] : [var.kubernetes_version]
  kubernetes_labels  = var.labels

  ami_type = "WINDOWS_CORE_2019_x86_64"

  update_config = [{ max_unavailable = 1 }]

  capacity_type = "SPOT"

  kubernetes_taints = [{
    key    = "OS"
    value  = "Windows"
    effect = "NO_SCHEDULE"
  }]

  node_role_arn                = [aws_iam_role.worker_role_nt.arn]
  node_role_cni_policy_enabled = false #We use the Service Account as per best practice

  associated_security_group_ids = [data.terraform_remote_state.network.outputs.ops_ssh, aws_security_group.workers.id]

### Enable the Kubernetes cluster auto-scaler to find the auto-scaling group
  cluster_autoscaler_enabled = true

  context = module.windowslabel.context

### Ensure the cluster is fully created before trying to add the node group
  module_depends_on = [module.eks_cluster.kubernetes_config_map_id]

### Ensure ordering of resource creation to eliminate the race conditions when applying the Kubernetes Auth ConfigMap.
### Do not create Node Group before the EKS cluster is created and the `aws-auth` Kubernetes ConfigMap is applied.
  depends_on = [module.eks_cluster, module.eks_cluster.kubernetes_config_map_id]

  create_before_destroy = true

  node_role_policy_arns = ["arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore"]

  block_device_mappings = [
    {
      "delete_on_termination" : true,
      "device_name" : "/dev/xvda",
      "encrypted" : true,
      "volume_size" : 80,
      "volume_type" : "gp3"
    }
  ]

  node_group_terraform_timeouts = [{
    create = "40m"
    update = null
    delete = "20m"
  }]

  #Valid types are "instance", "volume", "elastic-gpu", "spot-instances-request", "network-interface".
  resources_to_tag = ["instance", "volume", "spot-instances-request", "network-interface"]
}

related

• Closes https://github.com/cloudposse/terraform-aws-eks-node-group/issues/133
• Closes https://github.com/cloudposse/terraform-aws-eks-node-group/pull/137

v2.7.0

Compare Source

Conditionnaly disable default eks security group @​xeivieni (#​141)

what

Adds the possibility to remove association of the default eks security groups to the launch template

why

• The default security group contains very wide rules (all ports inbound on itself)
• Using the module it gets associated to all nodes by default
• In some cases users may need to explicitly whitelist part of the traffic instead of allowing everything

references

v2.6.2

Compare Source

🚀 Enhancements

Prevent unexpected privileges escalation @​gillg (#​136)

what

The current variable input_metadata_http_put_response_hop_limit condition, prevent to protect users of this module, to be protected against privileges escalation.
The first intent of IMDSv2 is to prevent containers beeing able to assume an EC2 instance profile. It's not a bad idea at all to prevent that. The good practice then is to use the module cloudposse/eks-iam-role/aws to create a kubernetes service account mapped with IAM permissions throug an OIDC IdP.

references

• https://aws.github.io/aws-eks-best-practices/security/docs/iam/#restrict-access-to-the-instance-profile-assigned-to-the-worker-node

v2.6.1

Compare Source

🚀 Enhancements

Add instance, volume, network-interface as resource tag defaults @​nitrocode (#​132)

what

• Add instance, volume, network-interface as resource tag defaults

why

• Reasonable tagging defaults

references

• Closes https://github.com/cloudposse/terraform-aws-eks-node-group/issues/131#issuecomment-1319252027
• Other module also contains this as a default

v2.6.0

Compare Source

Detailed monitoring @​IkePCampbell (#​126)

What did I do

• Add detailed monitoring flag to the launch template of EC2 nodes

Why did I do this

• Some compliance tools will flag nodes used by this module because they don't have detailed monitoring. This also allows metrics to be reported every minute as opposed to five minute intervals

Helpful references

• More AWS Documentation

v2.5.0: IPv6 support, non-breaking changes expected

Compare Source

Upgrading to this version, if you have node_role_cni_policy_enabled set to true (the default), will cause a new IAM policy to be created and your existing node group IAM role to have its permissions updated. This will cause a transient interruption in the ability of the node to manage its network interface, but it should heal itself with no interruption to existing services. It may cause a short (some seconds) delay in being able to deploy new Pods.

references

• Documentation of recommended IPv6 permissions
• Third-party documentation of AmazonEKS_CNI_Policy.

details

Add support for IPv6 @​Nuru (#​121)

what

• Update node group IAM role permissions to support IPv6

why

• Previous permissions, using AWS managed policy AmazonEKS_CNI_Policy, are insufficient to enable proper functioning of the node when using IPv6

---

Configuration

📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

---

• If you want to rebase/retry this PR, check this box

---

This PR has been generated by Mend Renovate. View repository job log here.

[mergify]

/terratest