v0.43.0

Manage `aws_eks_addon` resources @nitrocode (#125)

what

• Manage aws_eks_addon resources

why

• To install addons using a variable

references

• Closes #113
• https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/eks_addon
• Validation https://github.com/juozasget/terraform-provider-aws/blob/0d232c2ccd5c09f9c130f64925a25b6fcd7b8b49/aws/resource_aws_eks_addon.go#L61
• terraform-aws-eks is working on an implementation too

notes

module "eks" {
  # ...
  addons = [
    {
      addon_name               = "vpc-cni"
      addon_version            = "v1.8.0-eksbuild.1"
      resolve_conflicts        = "NONE"
      service_account_role_arn = null
    }
  ]
  # ...
}

v0.42.1 Fix EKS upgrades, enable choice of service role (patch)

Minor changes to 0.42.0, please see release notes there.

🚀 Enhancements

Update example @savannahar68 (#120), Fix order of roles in auth-map @Nuru (#121)

what

Quick fixes to #119

• Incorporate #120
• Insert roles into aws-auth in the correct order when not ignoring them

why

• Reduce complaints from Terraform

v0.42.0 Fix EKS upgrades, enable choice of service role

Update

AWS finally released an API for managing access control to EKS clusters, and this module replaces all of the hacks described in the original release notes, along with the Kubernetes provider itself, with the official API in version 4.0.0 of this module.

Original Release Notes

This release resumes compatibility with v0.39.0 and adds new features:

• Releases and builds on PR #116 by providing the create_eks_service_role option that allows you to disable the automatic creation and assignment of a service role to the EKS cluster and use one you provide instead. (Breaking change from v0.41.0: create_eks_service_role defaults to false and must be explicitly set. It is not enough just to set eks_cluster_service_role_arn to a non-empty string.)
• In an effort to cope with persistent issues surrounding the management of the aws-auth ConfigMap, this release:
  • Provides a new default Kubernetes Terraform provider configuration that works in more circumstances. In particular, it works when upgrading the EKS cluster to a new minor version of Kubernetes, which v0.39.0 could not do. Note: this configuration includes a hack, dummy_kubeapi_server, which works around current issues with the Kubernetes provider and the way Terraform handles provider initialization. We are not committed to supporting this hack, and if it starts to cause problems you can always disable it by setting dummy_kubeapi_server to null.
  • Provides additional guidance in the README on how the module works and configuration issues people have run into.
  • Provides 3 options for how to configure the Kubernetes Terraform provider:
    1. Using an auth token retrieved by an aws_eks_cluster_auth data source (kube_data_auth_enabled). This is the mechanism used in v0.39.0 and remains the default, but now it is only 1 of 3 options. Note: This is the only configuration we are committed to supporting long-term. The other 2 options below are hacks to work around current issues with the Kubernetes provider (v2.3.2) and the way Terraform handles provider initialization, and may be deprecated at any time. Even this option is planned to be deprecated and the Kubernetes provider removed entirely from the module once the AWS provider provides the capability of modifying the aws-auth ConfigMap. (See request to add API to modify aws-auth)
    2. Using an auth token retrieved using the Kubernetes exec feature to run the AWS CLI command aws eks get-token with the further option of setting the --profile or --role-arn options to that command (kube_exec_auth_enabled, kube_exec_auth_aws_profile_enabled, kube_exec_auth_aws_profile, kube_exec_auth_role_arn_enabled, kube_exec_auth_role_arn). This option seems to work better than the data source method (avoids issues of stale or cached tokens), provided you have aws available and configured properly. (The data source method is the default because it requires no external utilities or additional configuration.) Note: As stated above, this option is a workaround for external issues, and we are not committed to supporting it long-term. Also, this option has external dependencies (see #123, #124), and was broken by changes in AWS CLI versions 1.20.9 and 2.2.24 (fixed in subsequent releases of the CLI). We are not going address issues where this option does not work because of external dependencies or configuration problems. If this does not work for you, please use kube_data_auth_enabled.
    3. Using a kubeconfig file to configure access to the cluster. This option seems to work best, but of course you cannot provide a kubeconfig file to access a cluster before you create the cluster. Also, if you generate a kubeconfig file, you must ensure that it remains available, which can be an issue with automated systems that start each task with a "clean installation". Note: We know this option does not work in some circumstances and we are not going to do anything about it. This option is available for people to use when it works for them, and in particular to enable users to import resources while hashicorp/terraform#27934 remains open, but we have no plans to support or enhance it and in general will not consider failures of this option to be bugs. Use it if it works for you, and if it does not, then please use the supported kube_data_auth_enabled option instead.
• Adds aws_auth_yaml_strip_quotes to toggle whether or not aws-auth YAML is generated with or without quotes. Terraform will show a diff during plan if this module generates YAML with quotes but the data source returns YAML without quotes, or vice versa. Whether the data source returns YAML with or without quotes seems to depend on what Kubernetes version the EKS cluster is running.

---

Enhance Kubernetes provider configuration @Nuru (#119)

what

• Make Kubernetes provider configuration more robust, and provide alternative options.
• Enhance and correct README
• Make explicit the dependency of EKS cluster on Security Group rules
• Revert PR #114
• Add create_eks_service_role option
• Add aws_auth_yaml_strip_quotes to toggle whether or not aws-auth YAML is generated with or without quotes
• Update Cloud Posse standard GitHub configuration to current

why

• Closes #58, closes #63, closes #104, closes #118
• Closes #106
• Closes #112
• Undo breaking changes made prematurely
• Enhance PR #116 feature so that it does not run into problems with derived values, for example if the service role being passed in is created in the root module at the same time as this cluster is being created
• Terraform will show a diff during plan if this module generates YAML with quotes but the data source returns YAML without quotes, or vice versa. Whether the data source returns YAML with or without quotes seems to depend on what Kubernetes version the EKS cluster is running.
• Routine maintenance

v0.41.0 Breaking Changes from v0.39.0

This version has breaking changes if upgrading from version 0.39.0 or earlier. Do not use this version. Use 0.39.0 or 0.42.0 or later instead.

Allow service role to be passed in @nitrocode (#116)

what

• Accept eks_cluster_service_role_arn as a paramater to use an already defined eks service role instead of creating one.

why

• Allows module to be run without IAM:CreateRole
• Allows reuse of an already created service role.

references

• Fixed merge conflict with #82

@Tritium-VLK

v0.40.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 (#114)

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

v0.39.0

OIDC thumbprint_list can be retrieved and tags added to OIDC provider @nnsense (#115)

what/why

• Thanks to hashicorp/terraform-provider-tls#62 the sha1_fingerprint can be set automatically instead of be hardcoded, which is prone to error since some region has a different one.
• Minor, but useful: the OIDC provider wasn't tagged, which makes hard to find it and delete if the cluster is gone. I've just added the beloved module.label.tags

references

• hashicorp/terraform-provider-tls#52 and related PR: hashicorp/terraform-provider-tls#62
• The change is also reported into the data source examples: https://registry.terraform.io/providers/hashicorp/tls/latest/docs/data-sources/tls_certificate

v0.38.0

Enable cluster encryption by default @aknysh (#111)

what

• Enable cluster encryption by default
• Update example to use and test encryption
• Update example to the latest module versions

why

• Enable encryption of secrets - good security default
• Keep up to date

v0.37.0 Set `hashicorp/kubernetes` lower bound to 1.0

Set hashicorp/kubernetes lower bound to 1.0 @johncblandii (#109)

what

• Set hashicorp/kubernetes lower bound to 1.0

why

• The lower bound allows consumers to use ~> 1.0 to force the 1.0 version of the provider
• hashicorp/kubernetes provider 2.0 breaks terraform-aws-eks-cluster

references

• #96
• #104
• hashicorp/terraform-provider-kubernetes#1095
• hashicorp/terraform#4149

v0.36.0

feat(aws_iam_role): add permission_boundary to aws_iam_role @abhinavkhanna-sf (#108)

what

• added permission_boundary input to aws_iam_role
• created a variable
• updated readme

why

• adding permission boundary to IAM Role

references

• closes #107

v0.35.0

Fix typo in README.md @BrunoChauvet (#105)

what

• Fix typo in README.md file

why

• Because of my OCD issues

references

• worker