Poner la API de EKS detrás de una VPN: orden de las operaciones

Habilite el endpoint privado, demuestre que kubectl llegó a él y luego cierre el público. Un runbook por etapas con los comandos y las comprobaciones entre cada paso.

La versión peligrosa de este cambio es un solo comando que cambia el endpoint y deja fuera a todos los administradores a la vez. La versión segura mantiene abiertos ambos caminos, demuestra que el privado funciona desde la VPN y solo entonces retira el endpoint público. Suponga un clúster existente, un túnel aprobado hacia su VPC y un kubeconfig que ya funciona; la tarea es el acceso privado a la API de Kubernetes, no los nodos privados ni un nuevo modelo de permisos. Cada paso de abajo tiene una comprobación en la que puede fallar de forma segura.

1. Inventaríe el endpoint y conserve una vía de vuelta

Registre el estado actual antes de cambiarlo, incluida la lista CIDR pública de direcciones permitidas y el grupo de seguridad del clúster. Esos dos son los que comparará cuando algo deje de funcionar, y la lista de permitidas también es su vía de reversión si la ruta privada resulta ser incorrecta.

aws eks describe-cluster --region REGION --name CLUSTER \
  --query 'cluster.{endpoint:endpoint,public:resourcesVpcConfig.endpointPublicAccess,private:resourcesVpcConfig.endpointPrivateAccess,cidrs:resourcesVpcConfig.publicAccessCidrs}'

REGION y CLUSTER son aquí marcadores de posición. Fíjese en lo que indica ahora el indicador privado, porque un clúster creado con el acceso privado ya habilitado necesita un primer paso distinto que uno que nunca lo ha tenido. Mantenga abierta al menos una vía de administración aprobada durante la transición; una VPN que depende de que el mismo clúster sea accesible no es una vía de recuperación.

2. Habilite el acceso privado con la ruta de red ya preparada

Encender el indicador es la mitad fácil. El túnel necesita una ruta hacia las direcciones privadas del endpoint, y el grupo de seguridad del clúster necesita TCP 443 desde la fuente que la VPN presenta realmente. Una asociación de Client VPN, una puerta de enlace de sitio a sitio y una VPC emparejada pueden presentar direcciones de origen distintas, así que use el modelo que desplegó en lugar de un rango privado genérico.

aws eks update-cluster-config --region REGION --name CLUSTER \
  --resources-vpc-config endpointPublicAccess=true,endpointPrivateAccess=true

aws eks describe-update --region REGION --name CLUSTER --update-id UPDATE_ID

La actualización es asíncrona. Consulte el id de actualización hasta que informe de éxito en lugar de esperar un número fijo de segundos y suponerlo. Deje tranquilo el tráfico de los nodos y del plano de control mientras hace esto: sustituir todo el grupo de seguridad del clúster por una regla para su portátil es la forma en que un plano de datos que funciona se convierte en un segundo incidente.

La documentación de los endpoints de EKS merece una lectura completa, porque dice que el acceso solo privado puede venir de la VPC o de una red conectada. Esa frase es toda la razón por la que esta migración es posible, y también es la razón por la que existe el paso siguiente.

3. Demuestre que la estación de trabajo usó la ruta privada

Con ambos endpoints habilitados, un kubectl get ns correcto no demuestra nada sobre cuál respondió. Resuelva el nombre de host del endpoint y compruebe si la dirección que obtuvo pertenece al rango privado o al público. Si su red conectada no recibe la vista privada a través de DNS, el comando tendrá éxito por el endpoint público y usted retirará la ruta pública con pruebas falsas. Es la forma más común de que esta migración salga mal, y se parece exactamente al éxito.

nslookup HASH.gr7.REGION.eks.amazonaws.com
kubectl cluster-info
kubectl get ns --request-timeout=10s

Mantenga el nombre de host y la validación del certificado exactamente como están. Sustituir una IP privada en el kubeconfig y saltarse la verificación TLS no es la migración que describió en el registro de cambios, y volverá a fallar en el momento en que el endpoint rote.

4. Retire el acceso público de forma deliberada

Una vez demostrada la ruta privada y aprobado el flujo de recuperación, cierre el endpoint público. Este es un cambio real y no una vista previa, así que ejecútelo contra la cuenta y la configuración que realmente pretende.

aws eks update-cluster-config --region REGION --name CLUSTER \
  --resources-vpc-config endpointPublicAccess=false,endpointPrivateAccess=true

En el modo solo privado, el nombre DNS público se resuelve a las direcciones privadas del endpoint desde dentro de la VPC, así que la resolución y la accesibilidad dejan de ser lo mismo. Todo lo que dependía de la dirección pública, incluidos los ejecutores de CI o un portátil en otra red, ahora necesita su propia vía de entrada.

5. Mantenga separadas la política de red y la política de identidad

La lista CIDR de acceso público rige solo el endpoint público. No restringe el endpoint privado, que en cambio queda limitado por el grupo de seguridad del clúster y la política de la red conectada. Si conserva el endpoint público, su lista de permitidas debe coincidir con la salida pública que sus clientes de API y nodos usan realmente; una dirección de grupo de VPN rara vez es esa fuente.

Nada de esto cambia IAM ni Kubernetes RBAC. La configuración del endpoint es una acción administrativa, y los usuarios normales no deberían recibir permiso para relajar el límite solo para llegar a la API. Escriba el estado final, la fecha y la vía de recuperación en el runbook y luego pruebe la vía de recuperación una vez mientras aún es fácil.

Artículos relacionados