Pór a API de EKS detrás dunha VPN: orde das operacións

Active o endpoint privado, demostre que kubectl chegou a el e despois peche o público. Un runbook por etapas cos comandos e as comprobacións entre cada paso.

A versión perigosa deste cambio é un só comando que cambia o endpoint e deixa fóra a todos os administradores ao mesmo tempo. A versión segura mantén abertos os dous camiños, demostra que o privado funciona desde a VPN e só entón retira o endpoint público. Supoña un clúster existente, un túnel aprobado cara ao seu VPC e un kubeconfig que xa funciona; a tarefa é o acceso privado á API de Kubernetes, non os nodos privados nin un novo modelo de permisos. Cada paso de abaixo ten unha comprobación na que pode fallar de forma segura.

1. Inventaríe o endpoint e conserve unha vía de volta

Rexiste o estado actual antes de cambialo, incluída a lista CIDR pública de enderezos permitidos e o grupo de seguridade do clúster. Eses dous son os que comparará cando algo deixe de funcionar, e a lista de permitidos tamén é a súa vía de reversión se a 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 e CLUSTER son aquí marcadores de posición. Fíxese no que indica agora o indicador privado, porque un clúster creado co acceso privado xa habilitado necesita un primeiro paso distinto que un que nunca o tivo. Manteña aberta polo menos unha vía de administración aprobada durante a transición; unha VPN que depende de que o mesmo clúster sexa accesible non é unha vía de recuperación.

2. Active o acceso privado coa ruta de rede xa preparada

Acender o indicador é a metade fácil. O túnel necesita unha ruta cara aos enderezos privados do endpoint, e o grupo de seguridade do clúster necesita TCP 443 desde a fonte que a VPN presenta realmente. Unha asociación de Client VPN, unha pasarela de sitio a sitio e un VPC emparellado poden presentar enderezos de orixe distintos, así que use o modelo que despregou en lugar dun rango privado xené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

A actualización é asíncrona. Consulte o id de actualización ata que informe de éxito en lugar de esperar un número fixo de segundos e supoñelo. Deixe tranquilo o tráfico dos nodos e do plano de control mentres fai isto: substituír todo o grupo de seguridade do clúster por unha regra para o seu portátil é a forma en que un plano de datos que funciona se converte nun segundo incidente.

A documentación dos endpoints de EKS merece unha lectura completa, porque di que o acceso só privado pode vir do VPC ou dunha rede conectada. Esa frase é toda a razón pola que esta migración é posible, e tamén é a razón pola que existe o paso seguinte.

3. Demostre que a estación de traballo usou a ruta privada

Con ambos os endpoints habilitados, un kubectl get ns correcto non demostra nada sobre cal respondeu. Resolva o nome de host do endpoint e comprobe se o enderezo que obtivo pertence ao rango privado ou ao público. Se a súa rede conectada non recibe a vista privada a través de DNS, o comando terá éxito polo endpoint público e vostede retirará a ruta pública con probas falsas. É a forma máis común de que esta migración saia mal, e parécese exactamente ao éxito.

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

Manteña o nome de host e a validación do certificado exactamente como están. Substituír unha IP privada no kubeconfig e saltarse a verificación TLS non é a migración que describiu no rexistro de cambios, e volverá fallar no momento en que o endpoint rote.

4. Retire o acceso público de forma deliberada

Unha vez demostrada a ruta privada e aprobado o fluxo de recuperación, peche o endpoint público. Este é un cambio real e non unha previsualización, así que execúteo contra a conta e a configuración que realmente pretende.

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

No modo só privado, o nome DNS público resólvese nos enderezos privados do endpoint desde dentro do VPC, así que a resolución e a accesibilidade deixan de ser o mesmo. Todo o que dependía do enderezo público, incluídos os executores de CI ou un portátil noutra rede, agora necesita a súa propia vía de entrada.

5. Manteña separadas a política de rede e a política de identidade

A lista CIDR de acceso público rexe só o endpoint público. Non restrinxe o endpoint privado, que en cambio queda limitado polo grupo de seguridade do clúster e a política da rede conectada. Se conserva o endpoint público, a súa lista de permitidos debe coincidir coa saída pública que os seus clientes de API e nodos usan realmente; un enderezo de grupo de VPN raramente é esa fonte.

Nada disto cambia IAM nin Kubernetes RBAC. A configuración do endpoint é unha acción administrativa, e os usuarios normais non deberían recibir permiso para relaxar o límite só para chegar á API. Escriba o estado final, a data e a vía de recuperación no runbook e despois probe a vía de recuperación unha vez mentres aínda é fácil.

Artigos relacionados