Add option to overwrite (or importing current one) access entry. about terraform-aws-eks HOT 8 CLOSED

@bryantbiggs thanks for your thoughts on all this! I had not seen your upgrade guide, only the changelog in this repo. Thank you for pointing that out.

from terraform-aws-eks.

We're running into the same issue. Simply using terraform import is not ideal and not a complete solution - we need something that will work for new and existing clusters created by this module.

We have a company-standard terraform module containing this one. We are creating clusters everyday and maintaining existing clusters with this same module. For existing clusters, we could just set authenticationMode to API_AND_CONFIGMAP with no access_entries and let the EKS API set the two default access entries for cluster creator and worker nodes. This is what EKS automatically does when making this transition. Because of this, we cannot use the import block because those resources don't exist when starting a terraform apply.

So when we have an access entry defined (either manually or via the enable_cluster_creator_admin_permissions property), this has to be a multi-step operation with the first one resulting in failure:

1. Upgrade the module w/ new EKS Access Entries
2. Run terraform apply, fully expecting it to fail with the error mentioned in this thread.
3. Run terraform import, as prescribed.
4. Re-run terraform apply to complete the operation.

Another option could be manually going through the clusters and running:

aws eks update-cluster-config \
   --name <CLUSTER_NAME> \
   --access-config authenticationMode=API_AND_CONFIG_MAP

before running terraform apply. Coupled with the addition of a import block in the module, this could avoid running into the error.

I think this will be our game plan. Thank you @yaroslav-nakonechnikov for raising this issue! This helped me think through this problem better 😄

from terraform-aws-eks.

you can use https://developer.hashicorp.com/terraform/language/import

from terraform-aws-eks.

Because of this, we cannot use the import block because those resources don't exist when starting a terraform apply

which is exactly why we cannot support it in this module

we need something that will work for new and existing clusters created by this module

I am open to thoughts, but I cannot do anything about resources created outside of this module. I don't know when they will or will not exist, I don't know what they will be named or what users will name their resources - its an unknown of unknowns problem

Have you seen the upgrade guide? If you followed the upgrade guide, you still have a multi-part process but without errors. Using https://github.com/clowdhaus/terraform-aws-eks-migrate-v19-to-v20 which was created specifically for aiding in the upgrade process will avoid the apply error you listed above in step 2

from terraform-aws-eks.

@bryantbiggs https://github.com/clowdhaus/terraform-aws-eks-migrate-v19-to-v20 mentioned only ones, with a note to have terraform 1.7+.
so it can't be used by all, and looks like a workaround.

still, i'd lile to see option, which won't force adding/removing access entries.
not all using single runner to run terraform deploy, so there is a possibility to utilize different roles.
and atm it looks like each role will be overriden by others.
Would be good if i'm wrong, so keeping process of upgrading further.

from terraform-aws-eks.

I think you need to familiarized yourself with how EKS provided access to clusters prior to cluster access entry, and what EKS is doing when you opt into cluster access entry on those clusters

from terraform-aws-eks.

just to be clear, this is the upgrade guide which we store under the docs/ directory https://github.com/terraform-aws-modules/terraform-aws-eks/blob/master/docs/UPGRADE-20.0.md

in there, it refers to this one off repo used to aid in migrating from v19 to v20

from terraform-aws-eks.

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.

from terraform-aws-eks.