feat(eks): pin the cluster addon versions with addon_versions

[agustincelentano]

El problema

El módulo instala cinco addons y los deja con el default de upstream, most_recent = true:

addons = {
  aws-ebs-csi-driver     = { service_account_role_arn = aws_iam_role.ebs_csi_driver.arn }
  coredns                = {}
  eks-pod-identity-agent = { before_compute = true }
  kube-proxy             = {}
  vpc-cni                = { before_compute = true }
}

Con eso, cada plan consulta a EKS cuál es la versión más nueva y la compara con la instalada. El resultado es que una instalación que no tocó nada de su EKS ve drift apenas AWS publica un build. Nos pasó tres veces en la misma semana en una instalación real:

~ addon_version = "v1.65.0-eksbuild.1" -> "v1.65.0-eksbuild.2"   # aws-ebs-csi-driver
~ addon_version = "v1.23.0-eksbuild.1" -> "v1.23.1-eksbuild.1"   # vpc-cni
~ addon_version = "v1.34.6-eksbuild.21" -> "v1.34.6-eksbuild.25" # kube-proxy

Ese drift aparece mezclado con cambios de otro módulo, y quien está aplicando otra cosa tiene que decidir en el momento si se lleva puesto un upgrade del CNI del cluster. Es justo lo que VERSIONS.md pide evitar: ahí la política dice pinear charts, imágenes y refs, y los addons eran lo único que quedaba resuelto como "lo último que haya".

Qué cambia

Un input nuevo, addon_versions, un mapa por nombre de addon:

addon_versions = {
  vpc-cni    = "v1.23.1-eksbuild.1"
  kube-proxy = "v1.34.6-eksbuild.25"
}

Cada addon pasa su valor con lookup(var.addon_versions, "<nombre>", null). Upstream resuelve coalesce(addon_version, data.aws_eks_addon_version.this[...].version), así que el pin gana sobre la consulta de "más reciente", y un addon que no esté en el mapa sigue exactamente como hoy.

Una validation rechaza nombres que el módulo no instala, para que un typo (vpc-cni-typo) falle en el plan en vez de quedar sin efecto y sin aviso.

Compatibilidad

El default es {}: sin pasar nada, los values renderizados son idénticos a los de hoy. Ninguna instalación cambia al bumpear la versión.

Verificado contra una instalación real (EKS, cluster con los cinco addons)

Apuntando el module "eks" a este branch:

1. Sin addon_versions → No changes. El default no altera nada.
2. Con los cinco pineados a las versiones instaladas → No changes.
3. Con vpc-cni pineado a una versión anterior a la instalada → el plan propone el downgrade, que es la prueba de que el pin gana sobre most_recent:

   # module.eks.module.eks.aws_eks_addon.before_compute["vpc-cni"] will be updated in-place
   ~ addon_version = "v1.23.1-eksbuild.1" -> "v1.23.0-eksbuild.1"
   

   (No se aplicó.)
4. Con un nombre inválido → Error: Invalid value for variable en el plan.

tofu validate y tofu fmt -check OK.

Cómo leer los valores actuales para pinear

for a in aws-ebs-csi-driver coredns eks-pod-identity-agent kube-proxy vpc-cni; do
  echo "$a = $(aws eks describe-addon --cluster-name <cluster> --addon-name $a \
    --query addon.addonVersion --output text)"
done

La contrapartida esperada: con los addons pineados, los upgrades pasan a ser una decisión explícita en el tfvars, incluidos los parches de seguridad del CNI. Por eso el default no pinea nada y cada instalación elige.

🤖 Generated with Claude Code