Zet de EKS-API achter een VPN: de volgorde van de operaties

Schakel het private endpoint in, bewijs dat kubectl het heeft bereikt en sluit daarna het publieke. Een stapsgewijze runbook met de commando’s en de controles tussen elke stap.

De gevaarlijke versie van deze wijziging is één commando dat het endpoint omzet en tegelijk alle beheerders buitensluit. De veilige versie houdt beide paden open, bewijst dat het private pad vanaf de VPN werkt, en trekt pas daarna het publieke endpoint terug. Ga uit van een bestaand cluster, een goedgekeurde tunnel naar de VPC en een kubeconfig die al werkt; de taak is private toegang tot de Kubernetes-API, niet private nodes en geen nieuw rechtenmodel. Elke stap hieronder heeft een controle waarop je veilig kunt falen.

1. Inventariseer het endpoint en houd een weg terug

Leg de huidige toestand vast voordat je die wijzigt, inclusief de publieke CIDR-allowlist en de beveiligingsgroep van het cluster. Juist die twee vergelijk je wanneer iets stopt met werken, en de allowlist is ook je terugweg als de private route verkeerd blijkt.

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

REGION en CLUSTER zijn hier plaatsaanduidingen. Let op wat de private vlag nu aangeeft, want een cluster dat is gemaakt met private toegang al ingeschakeld heeft een andere eerste stap nodig dan een dat die nooit heeft gehad. Houd tijdens de overgang ten minste één goedgekeurd beheerpad open; een VPN die afhankelijk is van de bereikbaarheid van hetzelfde cluster is geen herstelpad.

2. Schakel private toegang in als het netwerkpad er is

De vlag aanzetten is de makkelijke helft. De tunnel heeft een route nodig naar de private adressen van het endpoint, en de beveiligingsgroep van het cluster heeft TCP 443 nodig vanaf de bron die de VPN werkelijk presenteert. Een Client VPN-koppeling, een site-to-site-gateway en een gepeerde VPC kunnen allemaal verschillende bronadressen presenteren, dus gebruik het model dat je hebt uitgerold in plaats van een generiek privaat bereik.

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

De update is asynchroon. Vraag de update-id op tot die succes meldt in plaats van een vast aantal seconden te wachten en het aan te nemen. Laat het verkeer van nodes en het controlepad met rust terwijl je dit doet: de hele beveiligingsgroep van het cluster vervangen door een regel voor je laptop is de manier waarop een werkend dataverkeer een tweede incident wordt.

De documentatie over EKS-endpoints is een keer volledig lezen waard, omdat er staat dat toegang alleen via privaat verkeer kan komen uit de VPC of een verbonden netwerk. Die zin is de hele reden dat deze migratie mogelijk is, en het is ook de reden dat de volgende stap bestaat.

3. Bewijs dat de werkplek het private pad gebruikte

Met beide endpoints ingeschakeld bewijst een geslaagde kubectl get ns niets over welk endpoint antwoordde. Los de hostnaam van het endpoint op en controleer of het adres dat je kreeg bij het private of het publieke bereik hoort. Als je verbonden netwerk de private weergave niet via DNS ontvangt, slaagt het commando via het publieke endpoint en trek je het publieke pad terug op valse bewijzen. Dat is de meest voorkomende manier waarop deze migratie misgaat, en het lijkt precies op succes.

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

Houd de hostnaam en de certificaatvalidatie precies zoals ze zijn. Vervangen door een privaat IP in de kubeconfig en TLS-verificatie overslaan is niet de migratie die je in het wijzigingsrecord beschreef, en het zal opnieuw mislukken op het moment dat het endpoint roteert.

4. Trek publieke toegang bewust terug

Zodra het private pad is aangetoond en de herstelworkflow is goedgekeurd, sluit je het publieke endpoint. Dit is een echte wijziging en geen voorbeeld, dus voer die uit op het account en de instellingen die je werkelijk bedoelt.

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

In de modus alleen privaat wordt de publieke DNS-naam van binnen de VPC naar de private adressen van het endpoint omgezet, dus resolutie en bereikbaarheid zijn niet langer hetzelfde. Alles wat op het publieke adres vertrouwde, inclusief CI-runners of een laptop op een ander netwerk, heeft nu zijn eigen weg naar binnen nodig.

5. Houd netwerkbeleid en identiteitsbeleid gescheiden

De CIDR-lijst voor publieke toegang beheert alleen het publieke endpoint. Die beperkt het private endpoint niet, dat in plaats daarvan wordt begrensd door de beveiligingsgroep van het cluster en het beleid van het verbonden netwerk. Als je het publieke endpoint houdt, moet de allowlist overeenkomen met de publieke uitgaande verbinding die je API-clients en nodes werkelijk gebruiken; een adres uit een VPN-pool is zelden die bron.

Niets hiervan verandert IAM of Kubernetes RBAC. Endpointinstellingen zijn een administratieve actie, en gewone gebruikers zouden geen toestemming moeten krijgen om de grens te verruimen alleen om de API te bereiken. Schrijf de eindtoestand, de datum en het herstelpad in de runbook en test het herstelpad daarna één keer terwijl het nog makkelijk is.

Gerelateerde artikelen