Placer l’API EKS derrière un VPN : l’ordre des opérations

Activez le point de terminaison privé, prouvez que kubectl l’a atteint, puis fermez le public. Un runbook par étapes avec les commandes et les vérifications entre chaque étape.

La version dangereuse de ce changement est une seule commande qui bascule le point de terminaison et verrouille tous les administrateurs en même temps. La version sûre garde les deux chemins ouverts, prouve que le privé fonctionne depuis le VPN, et ne retire le point de terminaison public qu’ensuite. Supposez un cluster existant, un tunnel approuvé vers son VPC et un kubeconfig qui fonctionne déjà ; le travail est l’accès privé à l’API Kubernetes, pas les nœuds privés ni un nouveau modèle d’autorisations. Chaque étape ci-dessous comporte une vérification où vous pouvez échouer en toute sécurité.

1. Inventoriez le point de terminaison et gardez un chemin de retour

Enregistrez l’état actuel avant de le modifier, y compris la liste CIDR publique des adresses autorisées et le groupe de sécurité du cluster. Ce sont ces deux éléments que vous comparerez quand quelque chose cessera de fonctionner, et la liste des autorisées est aussi votre chemin de retour si la route privée s’avère erronée.

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

REGION et CLUSTER sont ici des espaces réservés. Notez ce qu’indique le drapeau privé maintenant, car un cluster créé avec l’accès privé déjà activé a besoin d’une première étape différente de celui qui ne l’a jamais eu. Gardez au moins un chemin d’administration approuvé ouvert pendant la transition ; un VPN qui dépend de l’accessibilité du même cluster n’est pas un chemin de récupération.

2. Activez l’accès privé avec le chemin réseau en place

Activer le drapeau est la moitié facile. Le tunnel a besoin d’une route vers les adresses privées du point de terminaison, et le groupe de sécurité du cluster a besoin de TCP 443 depuis la source que le VPN présente réellement. Une association Client VPN, une passerelle site à site et un VPC appairé peuvent tous présenter des adresses source différentes, utilisez donc le modèle que vous avez déployé plutôt qu’une plage privée générique.

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 mise à jour est asynchrone. Interrogez l’id de mise à jour jusqu’à ce qu’il signale un succès au lieu d’attendre un nombre fixe de secondes en le supposant. Laissez le trafic des nœuds et du plan de contrôle tranquille pendant cette opération : remplacer tout le groupe de sécurité du cluster par une règle pour votre ordinateur portable est la façon dont un plan de données qui fonctionne devient un second incident.

La documentation des points de terminaison EKS vaut une lecture complète, car elle indique que l’accès uniquement privé peut venir du VPC ou d’un réseau connecté. Cette phrase est toute la raison pour laquelle cette migration est possible, et c’est aussi pourquoi l’étape suivante existe.

3. Prouvez que le poste de travail a utilisé le chemin privé

Avec les deux points de terminaison activés, un kubectl get ns réussi ne prouve rien sur celui qui a répondu. Résolvez le nom d’hôte du point de terminaison et vérifiez si l’adresse obtenue appartient à la plage privée ou à la publique. Si votre réseau connecté ne reçoit pas la vue privée via DNS, la commande réussira via le point de terminaison public et vous retirerez le chemin public sur de fausses preuves. C’est la façon la plus courante dont cette migration tourne mal, et cela ressemble exactement à un succès.

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

Gardez le nom d’hôte et la validation du certificat exactement tels qu’ils sont. Remplacer par une IP privée dans le kubeconfig et ignorer la vérification TLS n’est pas la migration que vous avez décrite dans l’enregistrement de changement, et elle échouera de nouveau dès que le point de terminaison tournera.

4. Retirez l’accès public délibérément

Une fois le chemin privé démontré et le flux de récupération approuvé, fermez le point de terminaison public. C’est un vrai changement et non un aperçu, exécutez-le donc contre le compte et les réglages que vous visez réellement.

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

En mode privé uniquement, le nom DNS public se résout vers les adresses privées du point de terminaison depuis l’intérieur du VPC, si bien que la résolution et l’accessibilité cessent d’être la même chose. Tout ce qui dépendait de l’adresse publique, y compris les exécuteurs CI ou un ordinateur portable sur un autre réseau, a maintenant besoin de son propre chemin d’entrée.

5. Gardez la politique réseau et la politique d’identité séparées

La liste CIDR d’accès public ne régit que le point de terminaison public. Elle ne contraint pas le point de terminaison privé, qui est plutôt borné par le groupe de sécurité du cluster et la politique du réseau connecté. Si vous conservez le point de terminaison public, sa liste d’autorisations doit correspondre à la sortie publique que vos clients API et vos nœuds utilisent réellement ; une adresse de pool VPN est rarement cette source.

Rien de tout cela ne change IAM ni Kubernetes RBAC. Les paramètres du point de terminaison sont une action administrative, et les utilisateurs ordinaires ne devraient pas recevoir l’autorisation d’assouplir la frontière juste pour atteindre l’API. Écrivez l’état final, la date et le chemin de récupération dans le runbook, puis testez le chemin de récupération une fois pendant qu’il est encore facile.

Articles similaires