Letakkan API EKS di Belakang VPN: Urutan Operasi

Aktifkan endpoint privat, buktikan bahwa kubectl mencapainya, lalu tutup endpoint publik. Runbook bertahap dengan perintah dan pemeriksaan di antara setiap langkah.

Versi berbahaya dari perubahan ini adalah satu perintah yang membalik endpoint dan mengunci semua administrator pada saat yang sama. Versi aman menjaga kedua jalur tetap terbuka, membuktikan jalur privat berfungsi dari VPN, dan baru setelah itu menonaktifkan endpoint publik. Asumsikan klaster yang sudah ada, terowongan yang disetujui ke VPC-nya, dan kubeconfig yang sudah berfungsi; tugasnya adalah akses privat ke API Kubernetes, bukan node privat dan bukan model izin baru. Setiap langkah di bawah memiliki pemeriksaan yang bisa Anda lewati dengan aman bila gagal.

1. Inventarisasi endpoint dan pertahankan jalur kembali

Catat keadaan saat ini sebelum mengubahnya, termasuk daftar izin CIDR publik dan grup keamanan klaster. Keduanya adalah yang akan Anda bandingkan ketika sesuatu berhenti berfungsi, dan daftar izin itu juga jalur rollback Anda jika rute privat ternyata salah.

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

REGION dan CLUSTER adalah tempat penampung di sini. Perhatikan apa yang dibaca flag privat sekarang, karena klaster yang dibuat dengan akses privat sudah aktif memerlukan langkah pertama yang berbeda dari klaster yang belum pernah memilikinya. Jaga setidaknya satu jalur administrasi yang disetujui tetap terbuka selama transisi; VPN yang bergantung pada klaster yang sama tetap dapat dijangkau bukanlah jalur pemulihan.

2. Aktifkan akses privat dengan jalur jaringan sudah siap

Menyalakan flag adalah separuh yang mudah. Terowongan membutuhkan rute ke alamat privat endpoint, dan grup keamanan klaster membutuhkan TCP 443 dari sumber yang benar-benar disajikan VPN. Asosiasi Client VPN, gateway situs-ke-situs, dan VPC yang di-peer semuanya dapat menyajikan alamat sumber berbeda, jadi gunakan model yang Anda terapkan alih-alih rentang privat generik.

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

Pembaruan bersifat asinkron. Tanyakan id pembaruan sampai melaporkan sukses alih-alih menunggu jumlah detik tetap dan mengasumsikannya. Biarkan lalu lintas node dan bidang kontrol tenang selama Anda melakukan ini: mengganti seluruh grup keamanan klaster dengan aturan untuk laptop Anda adalah cara bidang data yang berfungsi menjadi insiden kedua.

Dokumentasi endpoint EKS layak dibaca sekali secara penuh, karena menyatakan bahwa akses hanya-privat dapat berasal dari VPC atau jaringan terhubung. Kalimat itulah seluruh alasan migrasi ini mungkin dilakukan, dan itu juga alasan langkah berikutnya ada.

3. Buktikan stasiun kerja menggunakan jalur privat

Dengan kedua endpoint diaktifkan, kubectl get ns yang berhasil tidak membuktikan apa pun tentang mana yang menjawab. Selesaikan nama host endpoint dan periksa apakah alamat yang Anda peroleh termasuk rentang privat atau publik. Jika jaringan terhubung Anda tidak menerima tampilan privat melalui DNS, perintah akan berhasil melalui endpoint publik dan Anda akan menonaktifkan jalur publik berdasarkan bukti palsu. Inilah cara paling umum migrasi ini salah, dan tampilannya persis seperti keberhasilan.

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

Pertahankan nama host dan validasi sertifikat persis seperti adanya. Mengganti dengan IP privat di kubeconfig dan melewati verifikasi TLS bukanlah migrasi yang Anda jelaskan dalam catatan perubahan, dan itu akan gagal lagi saat endpoint berputar.

4. Nonaktifkan akses publik secara sengaja

Setelah jalur privat ditunjukkan dan alur pemulihan disetujui, tutup endpoint publik. Ini perubahan nyata, bukan pratinjau, jadi jalankan pada akun dan pengaturan yang benar-benar Anda maksud.

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

Dalam mode hanya-privat, nama DNS publik diselesaikan ke alamat privat endpoint dari dalam VPC, sehingga resolusi dan keterjangkauan tidak lagi menjadi hal yang sama. Apa pun yang bergantung pada alamat publik, termasuk runner CI atau laptop di jaringan lain, kini memerlukan jalur masuknya sendiri.

5. Pisahkan kebijakan jaringan dan kebijakan identitas

Daftar CIDR akses publik hanya mengatur endpoint publik. Itu tidak membatasi endpoint privat, yang justru dibatasi oleh grup keamanan klaster dan kebijakan jaringan terhubung. Jika Anda mempertahankan endpoint publik, daftar izinnya harus cocok dengan egress publik yang benar-benar digunakan klien API dan node Anda; alamat kumpulan VPN jarang menjadi sumber itu.

Tidak ada yang mengubah IAM atau Kubernetes RBAC. Pengaturan endpoint adalah tindakan administratif, dan pengguna biasa tidak seharusnya menerima izin untuk melonggarkan batas hanya demi mencapai API. Tuliskan keadaan akhir, tanggal, dan jalur pemulihan ke dalam runbook, lalu uji jalur pemulihan sekali saat masih mudah.

Artikel terkait