v0.24.3

🤖 Automatic Updates

Update context.tf @cloudpossebot (#81)

what

This is an auto-generated PR that updates the context.tf file to the latest version from cloudposse/terraform-null-label

why

To support all the features of the context interface.

v0.24.2

🤖 Automatic Updates

chore(deps): update terraform cloudposse/label/null to v0.25.0 @renovate (#80)

This PR contains the following updates:

Package	Type	Update	Change
cloudposse/label/null (source)	module	minor	0.24.1 -> 0.25.0

---

Release Notes

cloudposse/terraform-null-label

v0.25.0

Compare Source

Add "tenant", "labels_as_tags", and "descriptors" @​Nuru (#​132)

##### what - Add additional label and `id` component: `tenant` - New input `labels_as_tags` controls which labels are exported as tags - New input `descriptor_formats` generates new output `descriptors` - Update README, remove link to obsolete `terraform-terraform-label` ##### why - Support users that host resources on behalf of and/or dedicated to single customers - Supersedes and closes #​131, giving people control over which tags the module generates - Simple mechanism for creating multiple identifiers from the same inputs, reducing the need to create multiple instances of `null-label` - Document `tenant`, `labels_as_tags`, `descriptor_formats`, add additional clarification, stop promoting obsolete module

Fix: Update README Snippets @​korenyoni (#​130)

##### what * Update README snippets to reflect use of Terraform Registry. ##### why * Including snippets that reflect use of the Terraform Registry make it easier for users to quickly instantiate a null_label module. * README is out of date and does not include snippets that reflect use of the Terraform Registry. ##### references * N/A

Bridgecrew compliance @​Nuru (#​125)

##### what - Resolve Bridgecrew compliance complaint about example Autoscaling Group (BC_AWS_GENERAL_31) - Fix typo in README - Include Terraform lock file in `.gitignore` ##### why - Get clean Bridgecrew badge - Correct confusing error - Ensure lock files are not checked into GitHub ##### note The PR can and should be merged into `master` to update README and Bridgecrew without triggering a new release/version. These changes have no effect on the actual module in use and a release will create unnecessary ripple effects. However, merging to `master` will update the README and badges, so is worthwhile, and the changes will move forward into the next release.

---

Configuration

📅 Schedule: At any time (no schedule defined).

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

♻ Rebasing: Renovate will not automatically rebase this PR, because other commits have been found.

🔕 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 WhiteSource Renovate. View repository job log here.

v0.24.1

🤖 Automatic Updates

chore(deps): update terraform cloudposse/security-group/aws to v0.3.2 @renovate (#79)

This PR contains the following updates:

Package	Type	Update	Change
cloudposse/security-group/aws (source)	module	patch	0.3.1 -> 0.3.2

---

Release Notes

cloudposse/terraform-aws-security-group

v0.3.2

Compare Source

🚀 Enhancements

add missing required input (vpc_id) in the example @​Zaargh (#​20)

#### what * add missing required input `vpc_id` in the example

---

Configuration

📅 Schedule: At any time (no schedule defined).

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

♻ Rebasing: Renovate will not automatically rebase this PR, because other commits have been found.

🔕 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 WhiteSource Renovate. View repository job log here.

v0.24.0 Unstable Pre-Release

See note in Release v0.21.0 (https://github.com/cloudposse/terraform-aws-eks-node-group/releases/tag/0.21.0)

Always add var.security_groups to launch template if provided @cvittoriasona (#77)

what

• If var.security_groups is present, add any passed in security groups, along with the default cluster security group, to the launch template.

why

• var.security_groups is only added to the launch template if var.remote_access_enabled is true. Additional security groups should not be dependent on SSH access being enabled to be used.
• Specifically, ran into an issue when using a x-account shared VPC where the default security group for the VPC was not available to accounts the VPC was shared with. After encountering this error, when attempting to specify a security group for the launch template using var.security_groups, realized this var isn't active unless var.remote_access_enabled is also set. See below for output:

Error: error creating EKS Node Group (my-eks-node-group): InvalidRequestException: You do not have access to a default security group in VPC vpc-123456. Specify a security group, 310. Specify a security group, and try again.
│ {
│   RespMetadata: {
│     StatusCode: 400,
│     RequestID: "some-uuid"
│   },
│   Message_: "You do not have access to a default security group in VPC vpc-123456. Specify a security group, and try again."
│ }

This seems to be mostly a workaround for launch templates as EKS managed nodegroups should be auto-assigned to the default cluster security group, even if the launch template has no security groups attached to it.

Issue was present in v0.19.0 only when using var.kubernetes_taints, but in >=v0.20.0 this issue applied to all nodegroups created with this module.

references

• Tested with AWS provider v3.44.0 & v3.50.0

v0.23.0 Unstable Pre-release

See note in Release v0.21.0 (https://github.com/cloudposse/terraform-aws-eks-node-group/releases/tag/0.21.0)

Add flag to optionally not attach AmazonEKS_CNI_Policy to nodegroups @cvittoriasona (#76)

what

• Adds worker_role_cni_iam_enabled bool so nodegroups can have the AmazonEKS_CNI_Policy omitted from IAM Instance Role.
• Defaults to true to not break existing use cases.

why

• Meant to be used with EKS IAM role for aws-node service account
• Similar to worker_role_autoscale_iam_enabled bool so nodes are configured with least privileges required for EKS to work (AmazonEC2ContainerRegistryReadOnly and AmazonEKSWorkerNodePolicy) ref

v0.22.0 Unstable Pre-release

We are revising and standardizing our handling of security groups and security group rules across all our Terraform modules. This is an early attempt with significant breaking changes. We will make further breaking changes soon, so using this version is not recommended.

Feature: to be able to increase or decrease the timeouts for aws_eks_node_group resources @alfredo-gil (#70)

Feature: to be able to increase or decrease the timeouts for aws_eks_node_group resources

what

• This PR gives the possibility to increase or decrese the tiemouts managing the node groups

why

• We need it because we use node groups with more than 50 nodes
• When we need to change a node group it takes much more than 60 minutes
• For example, if we need to update the ami version for our node groups with no business impact we use create_before_destroy = true and it takes much more than 60 minutes.
• If we don'r increase the timeout terraform apply would fail because of the timeout

references

• The aws_eks_node_group resource has the option to configure the timeouts:
• https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/eks_node_group#timeouts

v0.21.0 Unstable Pre-Release

We are revising and standardizing our handling of security groups and security group rules across all our Terraform modules. This is an early attempt with significant breaking changes. We will make further breaking changes soon, so using this version is not recommended.

feat: use security-group module instead of resource @SweetOps (#68)

what

• use security-group module instead of resource
• update tests

why

• more flexible than current implementation
• bring configuration of security group/rules to one standard

references

• CPCO-409

v1.0.0 Initial release with production Semantic Versioning

This is the v1.0.0 release according to production Semantic Versioning, part of Cloud Posse's general policy to convert to production versioning as we make updates to relatively mature modules, especially those where we see breaking changes coming in the near future. This module already has a v2.0.0 with breaking changes where we convert it to use our security-group and make other incompatible fixes and enhancements.

This version is identical to v0.20.0. Versions between 0.20.0 and 0.25.0 are unsupported pre-release versions with no supported migration step. Our best suggestion is to downgrade to v0.20.0 and then upgrade to the latest v2.x version. For older versions, we recommend upgrading to v1.0.0 and then from there following the migration instructions to upgrade to v2.0.0 and then to the latest v2.x version.

v0.20.0

feat(aws_launch_template): parametrize metadata_options @abhinavkhanna-sf (#63)

what

• parametrized launch template metadata options
• moved default values to variables.tf

why

• Restricting access to the IMDS and Amazon EC2 instance profile credentials
• EKS Security Best Practices

references

• closes #62

v0.19.0 Allow list of instance types (may cause rebuild)

🚀 Enhancements

Because we now allow users to supply a list of up to 20 instance types, along with choosing Spot instances, this release may trigger your node group to get rebuilt. If you have not already, we strongly encourage you to take this opportunity to switch to create_before_destroy = true.

Since this release is likely to cause cluster rebuilds anyway, we took this opportunity to sort any lists (like subnet IDs) that, if changed, would trigger a node group rebuild. The first time, however, that will likely trigger a rebuild because you likely were not passing them in sorted to begin with. If you were getting them from a data source, they were likely coming in a different order every time anyway.

Fix allow several instance types @patrickjahns (#54)

what

• Allow to specify more than a single instance_types for eks node groups
• Possible to pass more than a single item in the list since the the introduction of capacity_type see upstream pr

why

• For utilising SPOT instances it is a good practice to specify more than a single instance type

references

• Related to #8
• See also instanceTypes in current AWS eks api