v2.9.0

Groundwork new workflows @max-lobur (#143)

Fix lint/format before workflows rollout

v2.8.0

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 aws/containers-roadmap#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 #133
• Closes #137

v2.7.0

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

🚀 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

🚀 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 #131 (comment)
• Other module also contains this as a default

v2.6.0

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

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

v2.4.0

With this release, we end the use of pre-production (version 0.x) Semantic Versions for this module. Earlier releases have been re-released to make upgrading using semantic versions possible.

This release has a change that may trigger an update. The ebs_optimized input was added in v2.2.0 (and v0.27.2) with a default value of false. In this release, we change the default value to true, which is the value recommended by AWS and is the default value for most instance types.

Although this release contains a fix to generate the correct values for the tags (with keys of the form k8s.io/cluster-autoscaler/node-template/taint/$TAINT) that give a hint to the Cluster Auto Scaler about what taints would be applied to nodes when launched (prior to his release, the tag values were invalid), the tags are only effective when applied to the auto scaling group controlling the node group, and even with this release, this module still does not apply the tags to the auto scaling group. See aws/containers-roadmap#608 for more details.

Other changes:

• Add updated documentation for migration to V2.0.0
• Add tags to the output, supersedes and closes #112, closes #111
• Fix the tag value for Auto Scaler tags that indicate taints

For details, see PR #118

v0.28.1

git.io->cloudposse.tools update @dylanbannon (#114)

what and why

Change all references to git.io/build-harness into cloudposse.tools/build-harness, since git.io redirects will stop working on April 29th, 2022.

References

• DEV-143

🤖 Automatic Updates

chore(deps): update terraform cloudposse/security-group/aws to v1 @renovate (#117)

This PR contains the following updates:

Package	Type	Update	Change
cloudposse/security-group/aws (source)	module	major	0.4.3 -> 1.0.1

---

v2.3.0 Requested features, general updates (#110)

Version 2.3.0 is exactly the same as v0.28.0 except for the version number, part of Cloud Posse's conversion to production Semantic Versioning for its Terraform modules.

This version is not recommended, because it includes the ebs_optimized input with a default value of false. The default has been changed to true in v2.4.0.

🚀 Enhancements

Requested features, general updates (#110)

what && why

Combine feature requests, bug fixes, and general updates into a single PR to reduce number of releases and also expedite requested changes to PRs.

• Allow ami_type="CUSTOM", resolves #96, thank you @ingledl
• Output ID and name of launch template, resolves #102, supersedes and closes #103, thank you @bwmetcalf
• Allow SSH access to provided ssh_access_security_group_ids whether or not an SSH key is provided, resolves #108, thank you @bcbrockway
• Update test framework, add test for enabled=false, update workflows: general maintenance and conformity

🐛 Bug Fixes

Properly handle launch template changes, ensure SSH egress (#110)

what && why

Combine feature requests, bug fixes, and general updates into a single PR to reduce number of releases and also expedite requested changes to PRs.

• Change name of node group when launch template ID changes. Supersedes and closes #106, thank you @woz5999
• Allow all TCP egress to destinations where SSH ingress is allowed because that is required for SSH to work (usually not a problem because usually node groups allow all egress to all destinations)