EKS API'sini VPN'in arkasına alın: işlem sırası

Özel endpoint'i etkinleştirin, kubectl'in ona ulaştığını kanıtlayın, ardından genel olanı kapatın. Her adım arasındaki komutlar ve kontrollerle aşamalı bir runbook.

Bu değişikliğin tehlikeli sürümü, endpoint'i çeviren ve aynı anda tüm yöneticileri dışarıda bırakan tek bir komuttur. Güvenli sürüm iki yolu da açık tutar, özel yolun VPN'den çalıştığını kanıtlar ve ancak ondan sonra genel endpoint'i devreden çıkarır. Mevcut bir küme, VPC'sine onaylanmış bir tünel ve hâlihazırda çalışan bir kubeconfig varsayın; iş özel düğümler ve yeni bir izin modeli değil, Kubernetes API'sine özel erişimdir. Aşağıdaki her adımda güvenle başarısız olabileceğiniz bir kontrol vardır.

1. Endpoint'i envanterleyin ve geri dönüş yolunu koruyun

Değiştirmeden önce mevcut durumu kaydedin; genel CIDR izin listesi ve kümenin güvenlik grubu dahil. Bir şey çalışmayı bıraktığında karşılaştıracağınız bu ikisidir ve özel rota yanlış çıkarsa izin listesi aynı zamanda geri alma yolunuzdur.

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

REGION ve CLUSTER burada yer tutucudur. Özel bayrağın şu anda ne okuduğuna dikkat edin, çünkü özel erişimi zaten etkin olarak oluşturulmuş bir küme, hiç sahip olmamış olandan farklı bir ilk adım gerektirir. Geçiş sırasında en az bir onaylı yönetim yolunu açık tutun; aynı kümenin erişilebilir olmasına bağlı bir VPN, kurtarma yolu değildir.

2. Ağ yolu hazırken özel erişimi etkinleştirin

Bayrağı açmak işin kolay yarısıdır. Tünelin endpoint'in özel adreslerine bir rotası olmalı ve kümenin güvenlik grubu, VPN'in gerçekten sunduğu kaynaktan TCP 443 almalıdır. Bir Client VPN ilişkilendirmesi, site-to-site ağ geçidi ve eşlenmiş VPC farklı kaynak adresleri sunabilir, bu nedenle genel bir özel aralık yerine dağıttığınız modeli kullanın.

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

Güncelleme eşzamansızdır. Sabit bir saniye sayısı bekleyip varsaymak yerine güncelleme kimliğini başarı bildirene kadar sorgulayın. Bunu yaparken düğüm ve kontrol düzlemi trafiğini rahat bırakın: kümenin tüm güvenlik grubunu dizüstü bilgisayarınız için bir kuralla değiştirmek, çalışan bir veri düzlemini ikinci bir olaya dönüştürmenin yoludur.

EKS endpoint'leri belgeleri bir kez tamamen okumaya değer, çünkü yalnızca özel erişimin VPC'den veya bağlı bir ağdan gelebileceğini söyler. O cümle bu geçişi mümkün kılan tek nedendir ve sonraki adımın var olma nedeni de odur.

3. İş istasyonunun özel yolu kullandığını kanıtlayın

İki endpoint de etkinken başarılı bir kubectl get ns hangisinin yanıt verdiğine dair hiçbir şey kanıtlamaz. Endpoint'in ana bilgisayar adını çözün ve aldığınız adresin özel aralığa mı yoksa genel aralığa mı ait olduğunu kontrol edin. Bağlı ağınız özel görünümü DNS üzerinden almıyorsa komut genel endpoint üzerinden başarılı olur ve genel yolu yanlış kanıtlara dayanarak devreden çıkarırsınız. Bu, geçişin ters gitmesinin en yaygın yoludur ve tam olarak başarı gibi görünür.

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

Ana bilgisayar adını ve sertifika doğrulamasını olduğu gibi koruyun. kubeconfig'te özel bir IP ile değiştirmek ve TLS doğrulamasını atlamak, değişiklik kaydında tanımladığınız geçiş değildir ve endpoint döndüğü anda yeniden başarısız olur.

4. Genel erişimi bilinçli olarak devreden çıkarın

Özel yol gösterildikten ve kurtarma iş akışı onaylandıktan sonra genel endpoint'i kapatın. Bu bir önizleme değil gerçek bir değişikliktir, bu nedenle gerçekten kastettiğiniz hesap ve ayarlar üzerinde çalıştırın.

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

Yalnızca özel modda genel DNS adı, VPC'nin içinden endpoint'in özel adreslerine çözümlenir, böylece çözümleme ve erişilebilirlik artık aynı şey değildir. Genel adrese dayanan her şey, CI çalıştırıcıları veya başka bir ağdaki dizüstü bilgisayar dahil, artık kendi giriş yoluna ihtiyaç duyar.

5. Ağ politikasını ve kimlik politikasını ayrı tutun

Genel erişim CIDR listesi yalnızca genel endpoint'i yönetir. Özel endpoint'i kısıtlamaz; onu bunun yerine kümenin güvenlik grubu ve bağlı ağ politikası sınırlar. Genel endpoint'i korursanız, izin listesi API istemcilerinizin ve düğümlerinizin gerçekten kullandığı genel çıkışla eşleşmelidir; bir VPN havuzu adresi bu kaynak olduğunda nadirdir.

Bunların hiçbiri IAM veya Kubernetes RBAC'i değiştirmez. Endpoint ayarları idari bir eylemdir ve sıradan kullanıcılar yalnızca API'ye ulaşmak için sınırı gevşetme izni almamalıdır. Son durumu, tarihi ve kurtarma yolunu runbook'a yazın, ardından hâlâ kolayken kurtarma yolunu bir kez test edin.

İlgili makaleler