#terraform-aws-modules (2024-02)

@Aayush Harwani what error are you seeing? Asking b/c what you added in the PR is already implemented here https://github.com/cloudposse/terraform-aws-components/blob/main/modules/vpc/main.tf#L5

@Andriy Knysh (Cloud Posse), my bad, i was getting error due to this,, here in remote-state.tf var is used instead of local. - https://github.com/cloudposse/terraform-aws-components/pull/972

I faced this issue, while trying out atmos.

thanks @Aayush Harwani https://github.com/cloudposse/terraform-aws-components/releases/tag/1.398.0

@Aayush Harwani this is not related to Atmos, this is pure Terraform. The component uses a local module https://github.com/cloudposse/terraform-aws-components/blob/main/modules/sqs-queue/main.tf#L6

the module is defined in the modules folder https://github.com/cloudposse/terraform-aws-components/tree/main/modules/sqs-queue/modules/terraform-aws-sqs-queue

This is a correct and used Terraform pattern. Why do you think it’s a problem?

whenever i am pulling this module using vendor pull, modules folder is not getting pulled and it is giving error.

please add this to the included_paths in vendor.yaml

(the Go lib that Atmos uses to download the sources does not create sub-folders automatically, they need to be specified in included_paths)

Can you show the error?

There you go @Joe Niland

Would you happen to know how to add multiple “Rules” in the configuration, like this?

I’m finding that the following rule is required to avoid the error shown above…

{
      namespace = "aws:elbv2:listener:443"
      name      = "Rules"
      value     = "default"
 },

However, when I use that rule, I am unable to add a secondary rule as shown in the screenshot.

i believe if you didn’t use it before, it should not affect you (but you have to test it)

There isnt any particular reason that the module version hasnt been updated. It was likely the case of pushing a quick fix for a requirement and neglecting to upgrade the module version at the same time.

If you do upgrade that version and everything works as expected, please feel free to submit a PR to the component!

(this is more a refarch question, as it’s components)

We do not automatically update dependencies in terraform-aws-components right now because we lack automated testing. We want/need these to be vetted & working modules. They there’re will lag behind because we upgrade them mostly when we need to to retrieve new functionality.

We’re in parallel in the early stages of building out refarch v2 components. These will add terratests (we’re adding a helper for terratest to support atmos). All v2 components will have tests out-of-the-box. This means we can accept more contributions, automatically update component dependencies, and ensure everything continues to work.

i’m using tf overrides for these kind of updates. So far, all working very nice

I was going to ask for this, and found your message… I think this will simplify things

https://aws.amazon.com/blogs/containers/a-deep-dive-into-simplified-amazon-eks-access-management-controls/

Yes, this is actively under development. In fact, the coding is mostly done, but the upgrade path is complicated and there is a lot of testing to do and documentation to write. I plan to release a pre-release version next week to get feedback.

@Luis Longo Please try eks-cluster v4.0.0-rc1 (PR 206) and let us know what you think. It (finally!) ditches all the hacks needed to update the aws-auth ConfigMap and uses the new AWS API for access control. Be sure to read the migration doc, as there a few manual steps needed to upgrade, and a lot of deprecated features finally removed.

Note: at present, v4.0.0-rc1 is not available via the Terraform registry. Use a git ref instead:

source = "github.com/cloudposse/terraform-aws-eks-cluster?ref=v4.0.0-rc1"

@Jeremy G (Cloud Posse) Hi !

Thanks for the work.

I’m testing it and I have this error during terraform plan:

│ Error: Get “<http://localhost/api/v1/namespaces/kube-system/configmaps/aws-auth>”: dial tcp [::1]:80: connect: connection refused

I can’t figure why

My values comply with the migration guide

@Quentin BERTRAND Verify that you really are on v4.0.0-rc1. (It is now available via the Terraform Registry.) That error comes from settings that have been removed. If you are on the right version, and have removed the auth-map as detailed in the migration guide, and are still having this issue, then you may need to manually remove ...null_resource.wait_for_cluster[0] the way you removed the auth-map resource. Please let me know if this helps, and if it does not, please let me know what settings you previously had for all the inputs that start with “kube”.

@Jeremy G (Cloud Posse) Hello,

Verify that you really are on v4.0.0-rc1 I use source = "[github.com/cloudposse/terraform-aws-eks-cluster?ref=v4.0.0-rc1](http://github.com/cloudposse/terraform-aws-eks-cluster?ref=v4.0.0-rc1)" on my terragrunt.hcl :white_check_mark:

I removed manually ...null_resource.wait_for_cluster[0]

Now I have these states;

❯ terragrunt state list
data.aws_iam_policy_document.assume_role[0]
data.aws_iam_policy_document.cluster_elb_service_role[0]
data.aws_partition.current[0]
data.tls_certificate.cluster[0]
aws_eks_cluster.default[0]
aws_iam_openid_connect_provider.default[0]
aws_iam_policy.cluster_elb_service_role[0]
aws_iam_role.default[0]
aws_iam_role_policy_attachment.amazon_eks_cluster_policy[0]
aws_iam_role_policy_attachment.amazon_eks_service_policy[0]
aws_iam_role_policy_attachment.cluster_elb_service_role[0]
aws_security_group_rule.managed_ingress_cidr_blocks[0]
aws_security_group_rule.managed_ingress_security_groups[0]
kubernetes_config_map.aws_auth_ignore_changes[0]

I keep getting the error during terraform plan/apply;

Error: Get "<http://localhost/api/v1/namespaces/kube-system/configmaps/aws-auth>": dial tcp 127.0.0.1:80: connect: connection refused

``` Do I have to delete kubernetes_config_map.aws_auth_ignore_changes[0] ?

:face_palm: Yes, of course, my mistake. You need to delete (terraform state rm):

kubernetes_config_map.aws_auth_ignore_changes[0]

@Quentin BERTRAND Also, if you have kubernetes in your required_providers block (usually in [versions.tf](http://versions.tf)) and/or have provider "kubernetes" in your [providers.tf](http://providers.tf) you need to remove those, too.

@Quentin BERTRAND Did you not get this error:

│ Error: Provider configuration not present
│ 
│ To work with module.eks_cluster.kubernetes_config_map.aws_auth_ignore_changes[0] (orphan) its original provider configuration at
│ module.eks_cluster.provider["registry.terraform.io/hashicorp/kubernetes"] is required, but it has been removed. This occurs when a provider
│ configuration is removed while objects created by that provider still exist in the state. Re-add the provider configuration to destroy
│ module.eks_cluster.kubernetes_config_map.aws_auth_ignore_changes[0] (orphan), after which you can remove the provider configuration again.

or something almost exactly like it? If not, I’m curious how, because I cannot reproduce the case where that error does not show up.

@Jeremy G (Cloud Posse) Hello It’s better after deleting kubernetes_config_map.aws_auth_ignore_changes[0] Thank you

if that isn’t a good solution, I could take a stab at it

@Erik Osterman (Cloud Posse) Who is our best resource for ElastiCache?

Maybe @Dan Miller (Cloud Posse)

unfortunately no. I’ve not worked on elasticache more than the basics of setting it up

I should have raised my hand sooner, but missed the DM’s about this till now

reading the PR

so, from what I’ve gathered, our module doesn’t use random_password. In fact, the code explicitly requests a variable. This means that the behavior is out of scope.

To be clear, I empathize with the issue. I would recommend using the -target flag, which lets you apply the state of just one resource in a stack. If you need to rotate the password, just use something like taint, and then run another -target apply.

here’s more on the -target argument in Terraform

The tl;dr is that we want to ensure that when you destroy an EKS cluster via terraform destroy it does not leave orphaned resources like the Karpenter IAM role. If eks/karpenter creates the role, and then you destroy the EKS cluster, you then don’t have a good way to destroy the Karpenter IAM role. You cannot terraform destroy the eks/karpenter component at that point because the cluster is gone and you get errors.

Previously, we ran into even greater issues with bringing up a new cluster with the orphaned role still lying around, the exact details of which I don’t recall, but it had something to do with the special relationship between IAM roles and EC2 instance profiles.

Anyway, it just works out better for eks/cluster to be responsible for all the IAM roles in the cluster that are part of the cluster infrastructure (rather than the applications).

Also, updated Karpenter support is high on our to-do list. It has been held up by our work on updating eks/cluster to use the new AWS API for access control, but now that we have a release candidate for that, we hope to have updated Karpenter support “real soon now”

Thank you @Jeremy G (Cloud Posse)! I did not think about race-condition or sudo circular dependency between eks/karpenter and its IAM role.

Also, updated Karpenter support is high on our to-do list. It has been held up by our work on updating eks/cluster to use the new AWS API for access control, but now that we have a release candidate for that, we hope to have updated Karpenter support “real soon now” I would love to see this support too. I am hopeful that EKS Pod Identity can improve EKS deployment, upgrade, and management experiences.

@Brian I encourage you to try out eks-cluster v4.0.0-rc1 to validate our approach to migrating to the new AWS API for EKS access control, and give us any feedback before we release a production version.

Okay. Ill check it out. I am in the process of upgrading eks k8s clusters from v1.27 to v1.29 using the blue-green upgrade pattern, so this is probably good timing.