EKS supports access configuration via two methods:
aws-auth configmap
aws_eks_access_entry resources
This change enables progressive migration of downstream configuration from the old style to the new style.
Why
The use of configmap is headed out of favour:
It's inherently a bit messy (a yaml blob stored as a string inside a kubernetes resource, that gets constructed using templating by terraform).
It is prone to error and lacks a validation mechanism.
Typos fixed in the config map may not take effect for 30min or more, making debugging painful.
Errors in the configmap may brick the cluster (revoking permission for actors to revert the change, since the config itself is an in-cluster resource).
It tends to split the config across multiple terraform stages (cloud resources vs cluster resources), requiring effort to propagate info across terraform stages.
It attracts out-of-band changes (including some that are performed by AWS and reverted by terraform, e.g. when creating a fargate profile).
This change keeps pace with AWS API changes.
This change is motivated to more smoothly facilitate enabling Fargate hosting. (Fargate can be used for critical pods such as cluster autoscaler or karpenter, to protect against deadlocks and outages during node updates.)
Negative effects
Migration is optional, but an arguable downside is ambiguity if partial migrations leave multiple places where access could be configured.
This updates existing clusters in-line with updated AWS defaults (replacing the earlier configmap-only default). As such, it forces a particular setting (preventing complete deprecation of the configmap option) for something that could potentially be updated by clickops instead (that terraform probably would not otherwise override).
EKS supports access configuration via two methods:
aws-authconfigmapaws_eks_access_entryresourcesThis change enables progressive migration of downstream configuration from the old style to the new style.
Why
The use of configmap is headed out of favour:
This change keeps pace with AWS API changes.
This change is motivated to more smoothly facilitate enabling Fargate hosting. (Fargate can be used for critical pods such as cluster autoscaler or karpenter, to protect against deadlocks and outages during node updates.)
Negative effects
Migration is optional, but an arguable downside is ambiguity if partial migrations leave multiple places where access could be configured.
This updates existing clusters in-line with updated AWS defaults (replacing the earlier configmap-only default). As such, it forces a particular setting (preventing complete deprecation of the configmap option) for something that could potentially be updated by clickops instead (that terraform probably would not otherwise override).