GKE Özel Küme Oluşturma ve Uygulama Dağıtımı: Adım Adım Rehber

GKE özel küme nedir ve neden bu kadar önemli? Cloud NAT ile güvenli ve izole bir GKE özel küme nasıl oluşturulur, uygulamalar nasıl dağıtılır ve ağ çıkışı nasıl yönetilir? Bu kapsamlı rehberde adım adım öğreneceksiniz.

Günümüzün dijital dünyasında, bulut tabanlı uygulamalar iş süreçlerinin kalbinde yer alıyor. Bu uygulamaları yönetmek için Kubernetes gibi orkestrasyon araçları, özellikle de Google Kubernetes Engine (GKE) gibi tam yönetilen hizmetler, geliştiriciler ve operasyon ekipleri için vazgeçilmez hale geldi. Ancak, hızla büyüyen bu ekosistemde güvenlik, ölçeklenebilirlik ve uyumluluk konuları her zaman öncelikli olmaya devam ediyor. Özellikle finans, sağlık veya devlet gibi sıkı düzenlemelere tabi sektörlerde faaliyet gösteren kuruluşlar için, uygulamaların ağ izolasyonu hayati bir öneme sahiptir. Peki, GKE’nin sağladığı tüm avantajlardan yararlanırken, aynı zamanda en üst düzeyde ağ güvenliğini nasıl sağlayabiliriz? İşte tam da bu noktada, GKE özel kümeler ve Cloud NAT kombinasyonu devreye giriyor.

Geleneksel olarak, bir Kubernetes kümesindeki düğümlerin (VM’ler) internete erişimi genellikle genel IP adresleri aracılığıyla sağlanır. Bu yaklaşım, basit dağıtımlar için uygun olsa da, potansiyel güvenlik risklerini de beraberinde getirir. Herhangi bir dışarıdan erişilebilir IP adresi, kötü niyetli saldırganlar için potansiyel bir hedef anlamına gelir. Bu nedenle, birçok kurum, uygulamalarını yalnızca iç ağlarından erişilebilir olacak şekilde, yani genel IP adresleri olmadan çalıştırmayı tercih eder. Ancak, düğümlerin genel IP’si olmadığında, bu düğümlerin internetten yazılım güncellemelerini çekmesi, Docker imajlarını indirmesi veya harici API’lere bağlanması gibi temel işlevleri yerine getirmesi imkansız hale gelir. Bu paradoksu çözmek için Google Cloud, GKE özel kümeler ile Cloud NAT hizmetini mükemmel bir uyum içinde sunar. Bu ikili, düğümlerinize genel IP adresi atamadan, güvenli ve kontrollü bir şekilde internete çıkış imkanı sağlar.

Bu makale boyunca, GKE özel küme mimarisinin temel prensiplerinden başlayarak, neden bu kadar önemli olduğunu açıklayacağız. Ardından, adım adım bir GKE özel küme nasıl oluşturulur, bu kümeye Cloud NAT nasıl entegre edilir ve son olarak bu güvenli ortama bir uygulama nasıl dağıtılır, pratik örneklerle göstereceğiz. Amacımız, ister buluta yeni başlayan biri olun ister deneyimli bir DevOps mühendisi, bu güçlü kombinasyonu kendi projelerinizde başarıyla uygulayabilmeniz için size kapsamlı ve anlaşılır bir rehber sunmaktır. Güvenliği birinci öncelik haline getirirken, uygulamalarınızın internet erişimini akıllıca yönetmenin kapılarını aralayacağız. Örneğin, bir bankanın müşteri verilerini işleyen mikro hizmetlerinin, hiçbir şekilde doğrudan internete açık olmadan, ancak gerekli güncellemeleri alabilmesi ve üçüncü taraf ödeme API’lerine güvenle erişebilmesi gibi senaryolar, bu mimarinin neden bu kadar kritik olduğunu açıkça ortaya koymaktadır.

Temel Kavramlar: GKE Özel Küme ve Cloud NAT Nedir, Neden Birlikte Kullanılır?

GKE özel kümeler ve Cloud NAT, modern bulut altyapılarında güvenlik ve ağ yönetimi açısından kritik öneme sahip iki ayrı ancak birbiriyle sıkıca entegre çalışan hizmettir. Bu bölümde, her birinin ne anlama geldiğini, nasıl çalıştığını ve neden genellikle birlikte kullanıldıklarını detaylı bir şekilde inceleyeceğiz. Bu kavramları anlamak, güvenli ve verimli bir GKE altyapısı kurmak için temel oluşturacaktır.

GKE Özel Küme Nedir ve Ne İşe Yarar?

Google Kubernetes Engine (GKE) özel küme, adından da anlaşılacağı gibi, düğümlerinin (Kubernetes iş yüklerini barındıran sanal makineler) yalnızca özel (dahili) IP adreslerine sahip olduğu bir Kubernetes kümesidir. Bu, düğümlerin internetten doğrudan erişilemez olduğu anlamına gelir. Bir GKE özel kümesi genellikle iki ana bileşenden oluşur:

• Kontrol Düzlemi (Master): Kümenin beyni gibidir. Kubernetes API sunucusu, zamanlayıcı, kontrolör yöneticileri gibi bileşenleri barındırır. Özel kümelerde kontrol düzleminin bir kısmı Google tarafından yönetilir ve siz bu bileşenlere erişemezsiniz. Ancak, kontrol düzlemi ile düğümleriniz arasındaki iletişim tamamen özel bir ağ üzerinden gerçekleşir. Kontrol düzlemi için iki farklı erişim türü mevcuttur:
  • Genel Uç Nokta (Public Endpoint): Kontrol düzlemi, internetten erişilebilir bir genel IP adresine sahiptir, ancak bu erişim “Master Authorized Networks” özelliği ile belirli IP aralıklarıyla kısıtlanabilir. Bu, geliştiricilerin VPN veya bastion host olmadan küme API’sine erişmesine olanak tanır.
  • Özel Uç Nokta (Private Endpoint): Kontrol düzlemi, yalnızca özel IP adreslerine sahiptir ve yalnızca aynı VPC ağı içinden erişilebilir. Bu, en yüksek güvenlik seviyesini sağlar ve API erişimi için genellikle bir VPN veya Cloud Interconnect bağlantısı gerektirir.
• Düğümler (Nodes): Uygulama kapsayıcılarınızın çalıştığı sanal makinelerdir. Özel kümelerde, bu düğümlerin tamamı yalnızca iç IP adreslerine sahiptir. Bu, düğümlere dışarıdan doğrudan erişilemeyeceği anlamına gelir ve potansiyel saldırı yüzeyini önemli ölçüde azaltır.

GKE Özel Kümelerin Avantajları:

• Gelişmiş Güvenlik: Düğümlerin genel IP adresine sahip olmaması, saldırganların kümenize doğrudan erişme olasılığını ortadan kaldırır.
• Ağ İzolasyonu: Kümeniz, diğer ağlardan izole bir şekilde çalışır, bu da hassas verileri işleyen uygulamalar için idealdir.
• Uyum: PCI DSS, HIPAA gibi katı uyumluluk standartlarına sahip sektörler için genellikle bir gerekliliktir.
• Kontrollü Çıkış: Düğümlerin dışarıya erişimi yalnızca sizin belirlediğiniz yöntemlerle (örneğin Cloud NAT) gerçekleşir, bu da giden trafiği üzerinde tam kontrol sağlar.

Cloud NAT (Network Address Translation) Nedir ve Ne İşe Yarar?

Cloud NAT (Ağ Adresi Çevirisi), Google Cloud Platform’da genel IP adresine sahip olmayan sanal makinelerin (bizim durumumuzda GKE düğümleri) güvenli bir şekilde internete çıkış yapmasını sağlayan bir hizmettir. Temel olarak, dahili IP adreslerine sahip kaynakların internet üzerindeki harici hedeflerle iletişim kurabilmesi için bu kaynakların dahili IP adreslerini, NAT geçidi üzerinden atanmış genel IP adreslerine çevirir.

Cloud NAT’ın Çalışma Prensibi:

1. GKE düğümünüz gibi dahili bir VM, internetteki bir kaynağa (örneğin bir yazılım deposu veya Docker Hub) bağlanmak ister.
2. Bu istek, VPC ağınızdaki Cloud Router tarafından yönetilen Cloud NAT geçidine yönlendirilir.
3. Cloud NAT, isteğin kaynak IP adresini (düğümünüzün dahili IP’si) kendi havuzundan bir genel IP adresine çevirir.
4. İstek, artık Cloud NAT’ın genel IP adresiyle internete gönderilir.
5. Yanıt döndüğünde, Cloud NAT bu genel IP adresini kullanarak yanıtı tekrar düğümünüzün dahili IP adresine çevirir ve düğüme iletir.

Cloud NAT’ın Avantajları:

• Daha Az Genel IP: Tek bir Cloud NAT geçidi, birden fazla dahili VM için internet erişimi sağlayabilir, bu da genel IP adreslerinin verimli kullanılmasını sağlar ve maliyetleri düşürür.
• Geliştirilmiş Güvenlik: VM’lerinize genel IP atamanıza gerek kalmaz, bu da saldırı yüzeyini azaltır.
• Yüksek Erişilebilirlik ve Ölçeklenebilirlik: Cloud NAT, tam yönetilen bir hizmet olduğu için yüksek erişilebilirlik ve performans sunar.
• Kolay Yönetim: Karmaşık NAT kuralları yapılandırmanıza gerek kalmaz. Sadece hangi alt ağlar için NAT hizmeti vereceğini belirtmeniz yeterlidir.

Neden GKE Özel Kümeler ve Cloud NAT Birlikte Kullanılır?

GKE özel kümeler ve Cloud NAT’ın birlikte kullanılması, birbirlerinin eksikliklerini gideren ve güçlü bir sinerji oluşturan mantıklı bir kombinasyondur. Özel kümelerin güvenlik faydaları göz önüne alındığında, düğümlerin internet erişimi için bir mekanizmaya ihtiyaç duymaları kaçınılmazdır. İşte bu noktada Cloud NAT devreye girer:

• Güvenlik ve İşlevsellik Dengesi: Özel küme, düğümlerin doğrudan internetten erişimini engellerken, Cloud NAT bu düğümlerin internete kontrollü bir şekilde çıkış yapmasına olanak tanır. Böylece, düğümler Docker imajlarını çekebilir, işletim sistemi güncellemelerini alabilir, harici bağımlılıklara erişebilir ve izleme/telemetri verilerini bulut hizmetlerine gönderebilirler.
• Saldırı Yüzeyini Azaltma: Her bir düğüme ayrı ayrı genel IP adresi atamak yerine, tüm internet çıkış trafiği tek bir Cloud NAT geçidi üzerinden geçer. Bu, yönetilmesi gereken potansiyel giriş noktalarının sayısını önemli ölçüde azaltır.
• Uyumluluk Gereksinimleri: Birçok düzenleyici çerçeve, hassas verileri işleyen sistemlerin genel internete açık olmamasını gerektirir. Özel kümeler bu gereksinimi karşılarken, Cloud NAT kümenin operasyonel ihtiyaçlarını karşılamaya devam etmesini sağlar.

Kısacası, GKE özel küme, uygulama çalıştırma ortamınızın ağ güvenliğini en üst düzeye çıkarırken, Cloud NAT bu güvenli ortamın dış dünya ile kontrollü ve güvenli bir şekilde etkileşim kurmasını sağlayan köprü görevi görür. Bu entegrasyon, modern ve güvenli bulut mimarileri için altın standartlardan biridir.

Adım Adım Kurulum: GKE Özel Küme ve Cloud NAT Altyapısı Nasıl Oluşturulur?

Şimdi teoriden pratiğe geçme zamanı! Bu bölümde, Google Cloud Platform üzerinde sıfırdan bir GKE özel küme ve ona entegre Cloud NAT altyapısı oluşturma sürecini adım adım ele alacağız. Bu adımları takip ederek kendi güvenli ve izole Kubernetes ortamınızı kurabileceksiniz.

Ön Koşullar

Başlamadan önce aşağıdaki ön koşulları yerine getirdiğinizden emin olun:

• Bir Google Cloud Projesi ve bu projede faturalandırmanın etkinleştirilmiş olması.
• gcloud CLI’nin yerel makinenize kurulmuş ve yapılandırılmış olması.
• Gerekli izinlere sahip bir kullanıcı hesabınızın olması (örneğin, Project Editor rolü veya özel rollerle compute.* ve container.* izinleri).

Adım 1: VPC Ağı ve Alt Ağları Oluşturma

GKE özel kümeniz, özel bir VPC ağı üzerinde çalışacaktır. Bu ağ için düğümlerin, Pod’ların ve Service’lerin kullanacağı IP aralıklarını belirlememiz gerekmektedir.

Öncelikle bir VPC ağı oluşturalım:

gcloud compute networks create my-private-gke-vpc \
    --subnet-mode=custom

Şimdi bu VPC ağı içinde GKE düğümleri için birincil alt ağ ve Pod'lar ile Service'ler için ikincil IP aralıkları içeren bir alt ağ oluşturalım. Bu ikincil IP aralıkları, GKE'nin VPC native yeteneklerini kullanarak Pod'lara ve Service'lere dahili IP'ler atamasını sağlar.

gcloud compute networks subnets create gke-subnet-01 \
    --network=my-private-gke-vpc \
    --range=10.0.0.0/20 \
    --region=us-central1 \
    --enable-private-ip-google-access \
    --secondary-range pods-range=10.10.0.0/16 \
    --secondary-range services-range=10.20.0.0/16

Yukarıdaki komutta:

• --range=10.0.0.0/20: GKE düğümlerinin alacağı IP aralığıdır.
• --secondary-range pods-range=10.10.0.0/16: Pod'lar için ayrılan IP aralığıdır.
• --secondary-range services-range=10.20.0.0/16: Service'ler için ayrılan IP aralığıdır.
• --enable-private-ip-google-access: Bu, düğümlerin internete çıkmadan Google API'lerine (örneğin GCR, Cloud Logging) özel IP üzerinden erişmesini sağlar. Bu, Cloud NAT'a olan bağımlılığı azaltır ancak internete çıkış için Cloud NAT hala gereklidir.

Adım 2: GKE Özel Küme Oluşturma

Artık VPC ağımız hazır olduğuna göre, GKE özel kümemizi oluşturabiliriz. Bu adımda özellikle özel düğümleri etkinleştirmeye ve kontrol düzlemi erişimini yapılandırmaya dikkat edeceğiz.

gcloud container clusters create private-gke-cluster \
    --enable-private-nodes \
    --master-ipv4-cidr=172.16.0.0/28 \
    --enable-master-authorized-networks \
    --master-authorized-networks=0.0.0.0/0 \
    --enable-ip-alias \
    --network=my-private-gke-vpc \
    --subnetwork=gke-subnet-01 \
    --cluster-secondary-range-name=pods-range \
    --services-secondary-range-name=services-range \
    --region=us-central1 \
    --machine-type=e2-medium \
    --num-nodes=1 \
    --node-locations=us-central1-a \
    --no-enable-public-ip

Bu uzun komutu inceleyelim:

• --enable-private-nodes: Bu en kritik parametredir. Düğümlerin genel IP adresi almasını engeller ve yalnızca iç IP'lere sahip olmalarını sağlar.
• --master-ipv4-cidr=172.16.0.0/28: Küme kontrol düzlemi için ayrılacak IP aralığıdır. Bu aralık, VPC ağınızdaki diğer IP aralıklarıyla çakışmamalıdır.
• --enable-master-authorized-networks ve --master-authorized-networks=0.0.0.0/0: Kontrol düzlemi varsayılan olarak genel bir uç noktaya sahip olacaktır (ancak düğümler özeldir). 0.0.0.0/0 ile tüm IP'lerden erişime izin veriyoruz, ancak gerçek bir senaryoda buraya sadece kendi ofis IP'nizi veya VPN ağınızın IP'lerini ekleyerek kontrol düzlemi erişimini kısıtlamalısınız. Alternatif olarak, tamamen özel bir kontrol düzlemi için --enable-private-endpoint kullanabilirsiniz.
• --enable-ip-alias: VPC native kümeleri etkinleştirir. Bu, Pod'lara ve Service'lere VPC IP adresleri atamasını sağlar.
• --network ve --subnetwork: Yukarıda oluşturduğumuz VPC ağını ve alt ağı belirtir.
• --cluster-secondary-range-name ve --services-secondary-range-name: Pod'lar ve Service'ler için belirlediğimiz ikincil IP aralıklarının isimlerini belirtir.
• --no-enable-public-ip: Düğümlerin genel IP'ye sahip olmamasını sağlar (--enable-private-nodes ile aynı etkiyi yapar, ancak açıkça belirtmek güvenlik açısından iyi bir pratiktir).

Adım 3: Cloud Router Oluşturma

Cloud NAT hizmeti, bir Cloud Router'a bağlı olarak çalışır. Bu yüzden Cloud NAT'ı yapılandırmadan önce bir Cloud Router oluşturmamız gerekiyor.

gcloud compute routers create nat-router-us-central1 \
    --region=us-central1 \
    --network=my-private-gke-vpc

Adım 4: Cloud NAT Yapılandırma

Şimdi nihayet Cloud NAT hizmetini yapılandırabiliriz. Bu, GKE düğümlerimizin internete güvenli bir şekilde çıkış yapmasını sağlayacaktır.

gcloud compute routers nat create gke-nat-config \
    --router=nat-router-us-central1 \
    --region=us-central1 \
    --nat-custom-subnet-ip-ranges=gke-subnet-01 \
    --auto-allocate-nat-external-ips \
    --enable-endpoint-independent-mapping

Bu komuttaki önemli parametreler:

• --router=nat-router-us-central1: Yukarıda oluşturduğumuz Cloud Router'ı belirtir.
• --nat-custom-subnet-ip-ranges=gke-subnet-01: NAT hizmeti vereceği alt ağı belirtir. GKE düğümlerinin bulunduğu alt ağı seçiyoruz.
• --auto-allocate-nat-external-ips: Cloud NAT'ın otomatik olarak genel IP adresleri ayırmasını sağlar. İsterseniz önceden ayrılmış statik genel IP adreslerini de kullanabilirsiniz (--nat-external-ips ile).
• --enable-endpoint-independent-mapping: Çoğu senaryo için varsayılan olarak etkinleştirilmesi önerilen bir seçenektir. Daha iyi uyumluluk ve performans sağlar.

Adım 5: Kurulumu Doğrulama

Tüm adımları tamamladığımıza göre, kurulumu doğrulamamız gerekiyor.

1. GKE Düğümlerinin IP'lerini Kontrol Etme: Düğümlerin yalnızca dahili IP adreslerine sahip olduğunu doğrulamak için:

   
           kubectl get nodes -o wide
           

   EXTERNAL-IP sütununun boş olduğunu veya sadece internal IP olduğunu görmelisiniz.

2. Düğümden İnternet Erişimi Testi: Bir düğüme SSH ile bağlanarak internet erişimini test edebiliriz. Ancak özel düğümlere doğrudan SSH ile bağlanamazsınız. Bunun için kümenin içinde bir Pod dağıtıp oradan test etmek veya bir bastion host kullanmak daha iyidir.

   
           gcloud compute ssh gke-private-gke-cluster-default-pool-xxx \
               --zone us-central1-a --internal-ip
           

   Eğer bastion host kullanıyorsanız:

   
           # Bastion host'a bağlanın
           # Bastion host'tan GKE düğümüne bağlanın (iç IP üzerinden)
           # GKE düğümünde interneti test edin
           curl google.com
           

   Bu komut başarılı olursa, Cloud NAT'ın düzgün çalıştığını gösterir.

Bu adımlarla, güvenli bir GKE özel küme ve internete çıkışı yöneten Cloud NAT altyapısını başarıyla oluşturmuş oldunuz. Artık bu güvenli ortamda uygulamalarınızı dağıtmaya hazırsınız.

Uygulama Dağıtımı: Özel Kümenize Bir Nginx Uygulaması Nasıl Konuşlandırılır?

Altyapımız hazır olduğuna göre, şimdi sıra GKE özel kümemize bir uygulama dağıtmaya geldi. Bu bölümde, basit bir Nginx web sunucusunu özel kümemize nasıl dağıtacağımızı ve dış dünyadan erişim için gerekli ayarlamaları nasıl yapacağımızı adım adım inceleyeceğiz. Bu dağıtım, Cloud NAT'ın uygulama katmanında nasıl çalıştığını anlamanıza yardımcı olacaktır.

Adım 1: Kubernetes Kimlik Doğrulaması

İlk olarak, kubectl komut satırı aracınızı yeni oluşturduğunuz özel kümenizle iletişim kuracak şekilde yapılandırmanız gerekir. Bu, gcloud CLI kullanılarak kolayca yapılabilir.

gcloud container clusters get-credentials private-gke-cluster --region us-central1

Bu komut, küme kimlik bilgilerini yerel kubeconfig dosyanıza ekleyecektir. Artık kubectl komutlarını kullanarak kümenizle etkileşim kurabilirsiniz.

Adım 2: Nginx Deployment Oluşturma

Bir Nginx web sunucusu çalıştırmak için bir Kubernetes Deployment nesnesi tanımlayacağız. Bu Deployment, Nginx Pod'larını oluşturmaktan ve yönetmekten sorumlu olacaktır. Nginx imajı Docker Hub'dan (veya Google Container Registry'den) çekilecektir ve bu işlem için Cloud NAT gereklidir, zira düğümlerin genel IP'si yoktur.

Aşağıdaki YAML içeriğini nginx-deployment.yaml adıyla kaydedin:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:latest # Docker Hub'dan çekilecek, Cloud NAT gerekli
        ports:
        - containerPort: 80
        resources:
          requests:
            cpu: "100m"
            memory: "128Mi"
          limits:
            cpu: "200m"
            memory: "256Mi"

Bu Deployment dosyasını kümenize uygulayın:

kubectl apply -f nginx-deployment.yaml

Deployment'ın durumunu kontrol etmek için:

kubectl get deployments
kubectl get pods -o wide

Pod'ların çalıştığını ve internal IP adreslerine sahip olduğunu göreceksiniz. Eğer imaj çekilirken sorun yaşanırsa, Cloud NAT yapılandırmanızda veya ağ güvenlik duvarı kurallarınızda bir problem olabilir.

Adım 3: Nginx Service Oluşturma (Internal Erişime Açma)

Deployment'ımız çalışıyor, ancak Pod'lara doğrudan erişim genellikle önerilmez. Pod'lar geçici oldukları için IP adresleri değişebilir. Bu nedenle, Nginx Pod'larına dahili erişim sağlamak için bir Kubernetes Service nesnesi oluşturacağız. En yaygın Service türlerinden biri olan ClusterIP kullanacağız, bu da Service'e yalnızca küme içinden erişilebilen bir IP adresi atar.

Aşağıdaki YAML içeriğini nginx-service.yaml adıyla kaydedin:

apiVersion: v1
kind: Service
metadata:
  name: nginx-service
spec:
  selector:
    app: nginx
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
  type: ClusterIP # Küme içinden erişim için

Bu Service dosyasını kümenize uygulayın:

kubectl apply -f nginx-service.yaml

Service'in durumunu kontrol etmek için:

kubectl get services

nginx-service için bir ClusterIP atandığını göreceksiniz. Bu IP adresine küme içindeki herhangi bir Pod'dan erişebilirsiniz.

Adım 4: Uygulamayı Dışarıya Açma (LoadBalancer veya Ingress Kullanımı)

Eğer Nginx uygulamanızın internetten erişilebilir olmasını istiyorsanız, bir LoadBalancer türünde Service veya bir Ingress Controller kullanmanız gerekir. Cloud NAT, düğümlerin internete çıkışı için olsa da, uygulamaların dışarıdan erişilebilir olması için GCP'nin Yük Dengeleyici hizmetleri devreye girer. Bu hizmetler, kümenizdeki düğümlere yönlendirilen bir genel IP adresi atar ve trafiği ilgili Pod'lara iletir.

Seçenek A: LoadBalancer Tipi Service Oluşturma

En basit yol, LoadBalancer tipi bir Service oluşturmaktır. Bu, GCP'de bir Ağ Yük Dengeleyici (Network Load Balancer) oluşturacak ve ona bir genel IP adresi atayacaktır.

Aşağıdaki YAML içeriğini nginx-loadbalancer.yaml adıyla kaydedin:

apiVersion: v1
kind: Service
metadata:
  name: nginx-external-service
spec:
  selector:
    app: nginx
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
  type: LoadBalancer # Dışarıdan erişim için

Bu Service dosyasını kümenize uygulayın:

kubectl apply -f nginx-loadbalancer.yaml

Birkaç dakika bekledikten sonra, Service'in durumunu kontrol edin:

kubectl get services

nginx-external-service için EXTERNAL-IP sütununda bir IP adresi göreceksiniz. Bu IP adresini bir tarayıcıda açarak Nginx uygulamanıza internetten erişip erişemediğinizi test edebilirsiniz. Bu genel IP adresi, düğümlere atanmamıştır; doğrudan Google Cloud'un yük dengeleyici altyapısı tarafından yönetilir ve trafiği dahili IP'lere sahip düğümlerinize yönlendirir.

Seçenek B: Ingress Controller Kullanımı (Daha Gelişmiş Senaryolar İçin)

Birden fazla uygulamayı aynı IP adresi üzerinden farklı alan adları veya URL yolları ile dışarıya açmanız gerekiyorsa, bir Ingress Controller kullanmak daha esnektir. GKE, yerleşik bir Ingress Controller ile gelir (GCP Load Balancer'ı kullanır), ancak Nginx Ingress Controller gibi açık kaynaklı çözümleri de dağıtabilirsiniz.

Bu makalenin kapsamını aşacağı için, Ingress kurulum detaylarına burada yer vermiyoruz. Ancak genel işleyiş şöyledir: Ingress Controller, bir Load Balancer Service (genellikle tipi NodePort veya ClusterIP olan bir Service'i önünde) aracılığıyla dış dünyaya açılır ve gelen HTTP/S trafiğini URL'ye veya host adına göre yönlendirir. Ingress'in kendisi GCP HTTP(S) Load Balancer'ını tetikler ve bu yük dengeleyici de bir genel IP adresine sahip olur.

Adım 5: Uygulamanın Erişilebilirliğini Test Etme

LoadBalancer tipi Service ile dağıtım yaptıysanız, kubectl get services çıktısındaki EXTERNAL-IP adresini tarayıcınızda açarak Nginx varsayılan sayfasını görmelisiniz. Bu, uygulamanızın özel GKE kümenizde başarıyla çalıştığını ve Cloud NAT ile düğümlerin imajları çekebildiğini, ayrıca GCP Yük Dengeleyici aracılığıyla dışarıdan erişilebilir olduğunu kanıtlar. Bu kurulum, güvenlikten ödün vermeden uygulamalarınızı dünyaya açmanın etkili bir yoludur.

Güvenlik ve İleri Konular: Kümenizi Daha da Güçlü Hale Getirmek İçin Ne Yapmalısınız?

Bir GKE özel küme ve Cloud NAT kurulumu, başlı başına güçlü bir güvenlik temeli oluşturur. Ancak, modern siber güvenlik tehditlerinin karmaşıklığı göz önüne alındığında, bu temeli daha da güçlendirmek ve kümenizi her yönden korumak için ek adımlar atmak önemlidir. Bu bölümde, kümenizin güvenliğini artırmak, yönetilebilirliğini geliştirmek ve daha gelişmiş senaryolara uyum sağlamak için kullanabileceğiniz ileri düzey konuları ve en iyi uygulamaları ele alacağız.

Master Authorized Networks (Kontrol Düzlemi Yetkilendirilmiş Ağlar)

Daha önce de belirttiğimiz gibi, GKE kontrol düzleminize erişimi kısıtlamak kritik öneme sahiptir. Kontrol düzlemi genel bir uç noktaya sahip olsa bile, Master Authorized Networks özelliğini kullanarak bu erişimi yalnızca belirlediğiniz IP aralıklarıyla sınırlayabilirsiniz. Bu, potansiyel saldırganların kümenizin API sunucusuna erişmesini zorlaştırır.

# Küme oluşturma sırasında
gcloud container clusters create private-gke-cluster \
    --enable-master-authorized-networks \
    --master-authorized-networks=CIDR_BLOGU_1,CIDR_BLOGU_2 \
    ...

# Mevcut kümeyi güncellemek için
gcloud container clusters update private-gke-cluster \
    --enable-master-authorized-networks \
    --master-authorized-networks=KENDI_IP_ADRESINIZ/32,OFIS_VPN_CIDR

Gerçek dünya senaryosunda, bu IP aralıkları genellikle geliştirme ofisinizin statik genel IP adresi, bir VPN geçidinizin genel IP'si veya bir bastion host'un genel IP'si olacaktır. Asla 0.0.0.0/0 kullanmaktan kaçının, zira bu tüm dünyaya erişim izni verir.

VPC Service Controls ile Veri Sızıntısı Önleme

Hassas verilerle çalışıyorsanız, VPC Service Controls (VPC SC) kullanarak veri sızıntısı (data exfiltration) riskini azaltabilirsiniz. VPC SC, Google Cloud hizmetleri etrafında bir "güvenlik sınırı" (security perimeter) oluşturmanıza olanak tanır. Bu sınırlar, yetkisiz ağlardan gelen erişimi engeller ve hizmetler arasındaki veri akışını kısıtlar. Örneğin, GKE kümenizdeki Pod'ların Cloud Storage veya BigQuery gibi hizmetlere yalnızca belirli bir VPC SC sınırı içinden erişebilmesini sağlayabilirsiniz. Bu, bir uygulamanın ele geçirilmesi durumunda bile hassas verilerin dışarı sızmasını engellemeye yardımcı olur.

Güvenlik Duvarı Kuralları ile Ağ Erişimini İnce Ayarlama

Cloud NAT, dahili düğümlerinizin internete çıkışını sağlarken, güvenlik duvarı kuralları bu çıkış trafiğini daha da hassas bir şekilde kontrol etmenize olanak tanır. Örneğin, düğümlerinizin yalnızca belirli portlara (HTTP/HTTPS için 80/443 gibi) veya belirli harici IP adreslerine erişmesine izin veren kurallar oluşturabilirsiniz.

# Sadece belirli bir harici IP adresine 443 portundan çıkışa izin veren kural
gcloud compute firewall-rules create allow-egress-to-external-api \
    --network=my-private-gke-vpc \
    --action=ALLOW \
    --direction=EGRESS \
    --rules=tcp:443 \
    --destination-ranges=EXTERNAL_API_IP_ADRESI/32 \
    --source-ranges=GKE_SUBNET_IP_RANGE \
    --priority=65534

Varsayılan izin veren güvenlik duvarı kurallarının önüne geçerek bu özel kuralları belirlemek, "en az ayrıcalık" prensibini uygulamanızı sağlar.

Logging ve İzleme: Her An Haberdar Olun

Herhangi bir üretim ortamında olduğu gibi, GKE özel kümenizin ve Cloud NAT'ın performansını ve güvenliğini sürekli olarak izlemek hayati öneme sahiptir. Google Cloud'ın yerleşik izleme ve günlük kaydı hizmetleri olan Cloud Logging ve Cloud Monitoring'i kullanarak bunu kolayca yapabilirsiniz. Kümenizin düğümlerinden, Pod'larından ve Cloud NAT geçidinden gelen metrikleri ve günlükleri toplayın. Anormal davranışları veya potansiyel güvenlik olaylarını tespit etmek için uyarılar (alerts) ayarlayın.

Örneğin, Cloud NAT günlüklerinde ani bir trafik artışı, bir veri sızıntısı girişimine işaret edebilirken, GKE düğümlerindeki CPU kullanımındaki anormallikler kötü amaçlı yazılım aktivitesine işaret edebilir. Bu araçlar, proaktif bir güvenlik duruşu sergilemenize yardımcı olur.

Otomatik Bakım ve Güncellemeler

GKE, küme düğümleriniz için otomatik bakım ve yükseltme özellikleri sunar. Bu özellikleri etkinleştirerek, güvenlik yamalarının ve yeni Kubernetes sürümlerinin otomatik olarak uygulanmasını sağlayabilirsiniz. Bu, güvenlik açıklarını kapatmak ve kümenizi güncel tutmak için kritik öneme sahiptir.

gcloud container clusters update private-gke-cluster \
    --enable-autoupgrade \
    --enable-autorepair \
    --maintenance-window-start=2024-06-01T03:00:00Z \
    --maintenance-window-end=2024-06-01T07:00:00Z

Bir bakım penceresi belirlemek, güncellemelerin iş yüklerinizin en az etkileneceği zamanlarda yapılmasını sağlar.

Vaka Analizi: Büyük Bir Finans Kuruluşunun PCI DSS Uyumluluğu Yolculuğu

Büyük bir finans kuruluşu olan "FinBank", ödeme işlemlerini yürüten ve müşteri verilerini işleyen mikro hizmet tabanlı uygulamalarını GKE'ye taşımaya karar verdi. Ancak, PCI DSS (Payment Card Industry Data Security Standard) uyumluluk gereksinimleri, kart sahibi verilerini işleyen tüm sistemlerin internetten tamamen izole edilmesini şart koşuyordu. Bu, FinBank'ın GKE düğümlerinin genel IP adreslerine sahip olamayacağı anlamına geliyordu.

Zorluk: Özel GKE kümesindeki mikro hizmetler, dışarıdaki banka API'lerine bağlanmak, Docker imajlarını çekmek ve işletim sistemi güncellemelerini almak için yine de internet erişimine ihtiyaç duyuyordu.

Çözüm: FinBank, GKE özel kümeleri ve Cloud NAT kombinasyonunu uyguladı. Tüm GKE düğümleri yalnızca dahili IP adreslerine sahipti. Cloud NAT, bu düğümlerin internete çıkışını tek bir kontrol noktasından yönetti. Ayrıca:

• Kontrol düzlemi erişimi, FinBank'ın kendi veri merkezinden gelen VPN trafiğiyle sınırlanmış Master Authorized Networks kullanılarak güvence altına alındı.
• Cloud Firewall kuralları, düğümlerin yalnızca belirli finansal API'lerin IP adreslerine ve portlarına (443) erişmesine izin verecek şekilde yapılandırıldı.
• VPC Service Controls, FinBank'ın Cloud Storage ve BigQuery gibi hassas verileri barındıran diğer GCP hizmetleriyle GKE arasındaki veri akışını izole eden bir güvenlik sınırı oluşturmak için kullanıldı.
• Tüm küme için detaylı Cloud Logging ve Cloud Monitoring yapılandırıldı, uyarılar potansiyel güvenlik ihlallerini veya performans anormalliklerini anında tespit etmek için ayarlandı.

Sonuç: Bu entegre güvenlik yaklaşımı sayesinde FinBank, PCI DSS uyumluluk gereksinimlerini karşılarken, GKE'nin sağladığı ölçeklenebilirlik ve esneklikten tam olarak faydalanabildi. Müşteri verileri güvende tutulurken, uygulamalar operasyonel ihtiyaçları için gerekli internet erişimine sahip oldu, ancak bu erişim tamamen kontrol altındaydı.

Sonuç: Güvenli ve Ölçeklenebilir Bir Geleceğe Adım Atın

Bu kapsamlı rehber boyunca, Google Kubernetes Engine (GKE) özel kümelerin ve Cloud NAT'ın gücünü bir araya getirerek, bulut tabanlı uygulamalarınız için nasıl son derece güvenli, izole ve aynı zamanda işlevsel bir ortam oluşturabileceğinizi adım adım ele aldık. Gördüğümüz gibi, GKE özel kümeler, düğümlerin genel IP adreslerine sahip olmamasını sağlayarak potansiyel saldırı yüzeyini önemli ölçüde azaltırken, Cloud NAT bu izole düğümlerin internete kontrollü ve güvenli bir şekilde çıkış yapmasına olanak tanır. Bu ikili kombinasyon, özellikle finans, sağlık gibi sıkı düzenlemelere tabi sektörler ve hassas verileri işleyen uygulamalar için vazgeçilmezdir.

Uygulamalı adımlarla, VPC ağımızı oluşturmaktan, GKE özel kümemizi yapılandırmaya ve Cloud NAT geçidini devreye almaya kadar tüm süreci detaylandırdık. Daha sonra, bu güvenli altyapıya basit bir Nginx uygulamasını nasıl dağıtabileceğinizi ve onu dış dünyaya güvenli bir şekilde nasıl açabileceğinizi gösterdik. Son olarak, Master Authorized Networks, VPC Service Controls, detaylı güvenlik duvarı kuralları, izleme ve otomatik güncellemeler gibi ileri düzey güvenlik konularına değinerek kümenizi daha da güçlendirmek için atabileceğiniz adımları paylaştık. Bir finans kuruluşunun vaka analizi, bu mimarinin gerçek dünyadaki önemini ve uyumluluk gereksinimlerini nasıl karşıladığını net bir şekilde ortaya koydu.

Unutmayın ki güvenlik sürekli bir yolculuktur ve "tek seferlik" bir yapılandırma ile tamamlanmaz. En iyi uygulamaları takip etmek, güvenlik yamalarını düzenli olarak uygulamak, sistemlerinizi izlemek ve güvenlik duruşunuzu sürekli iyileştirmek esastır. GKE özel kümeler ve Cloud NAT, bu yolculukta size önemli bir avantaj sağlayarak, modern bulut altyapınızın temellerini sağlam bir şekilde atmanıza yardımcı olur. Artık, güvenliğinizi tehlikeye atmadan, uygulamalarınızı GKE üzerinde ölçeklenebilir ve yüksek performanslı bir şekilde çalıştırabilirsiniz. Bu bilgilerle donanmış olarak, daha güvenli ve dirençli bulut çözümleri geliştirmeye hazırsınız!

Sıkça Sorulan Sorular (SSS)

GKE özel kümenin maliyeti normal (genel) kümeden farklı mı?

Hayır, GKE özel kümelerin düğümleri için ek bir maliyet yoktur. GKE kontrol düzleminin maliyeti, özel veya genel uç nokta olmasına bakılmaksızın aynıdır. Ancak, Cloud NAT hizmetinin kendisinin kullanımına bağlı olarak ek maliyetler oluşur. Cloud NAT, NAT ağ geçitlerinin çalışma süresi ve işlenen veri miktarı üzerinden ücretlendirilir. Bu maliyetler genellikle genel IP'lere sahip düğümlerin maliyetinden daha düşüktür ve sunduğu güvenlik avantajları göz önüne alındığında genellikle tercih edilir.

Cloud NAT'ın alternatifleri nelerdir?

Cloud NAT'ın başlıca alternatifi, düğümlere genel IP adresleri atamak ve bu IP'leri güvenlik duvarı kurallarıyla kısıtlamaktır. Ancak bu, yönetim karmaşıklığını artırır ve her düğümün internete doğrudan açık olması nedeniyle güvenlik riskini yükseltir. Diğer bir alternatif, bir ara sunucu (proxy) veya bastion host aracılığıyla internet erişimi sağlamaktır, ancak bu da ek yönetim yükü ve tek hata noktası riski taşıyabilir. Cloud NAT, tam yönetilen, yüksek oranda ölçeklenebilir ve güvenli bir çözüm olarak bu alternatiflere göre genellikle daha avantajlıdır.

Özel kümede çalışan uygulamanın dış dünyaya açılması nasıl yapılır?

Özel kümede çalışan bir uygulamayı dış dünyaya açmak için düğümlere genel IP adresleri atamak yerine, Google Cloud'ın yük dengeleyici hizmetlerini kullanırsınız. En yaygın yöntem, LoadBalancer tipi bir Kubernetes Service oluşturmaktır. Bu, Google Cloud'da otomatik olarak bir Ağ Yük Dengeleyici (Network Load Balancer) veya HTTP(S) Yük Dengeleyici (Eğer Ingress kullanılıyorsa) oluşturur ve bu yük dengeleyiciye bir genel IP adresi atar. Gelen trafik bu genel IP üzerinden yük dengeleyiciye ulaşır ve oradan kümenizin özel IP'lere sahip düğümlerindeki Pod'lara yönlendirilir. Düğümlerin kendisi hala internetten doğrudan erişilemez durumda kalır.

GKE özel küme performansı nasıl etkiler?

GKE özel kümeler, performans üzerinde doğrudan önemli bir olumsuz etkiye sahip değildir. Aslında, ağ trafiğinin özel VPC ağı içinde kalması, bazen daha düşük gecikme süreleri ve daha iyi performans sağlayabilir. Cloud NAT, giden internet trafiği için bir ara sunucu görevi gördüğünden, bu trafiğe küçük bir gecikme ekleyebilir, ancak çoğu uygulama için bu fark ihmal edilebilir düzeydedir. Performansı etkileyen asıl faktörler genellikle Pod kaynakları, düğüm türleri, ağ yapılandırması ve uygulama mimarisidir.

Bir kümede birden fazla Cloud NAT kullanabilir miyim?

Evet, bir GKE özel kümesinde birden fazla Cloud NAT yapılandırması kullanabilirsiniz. Cloud NAT, bölgesel bir hizmettir ve genellikle belirli bir alt ağa veya alt ağlara hizmet verecek şekilde yapılandırılır. Eğer kümenizin farklı düğüm havuzları farklı alt ağlarda bulunuyorsa veya farklı bölgelerde düğüm havuzlarınız varsa, her bölge veya alt ağ için ayrı Cloud NAT geçitleri yapılandırmanız gerekebilir. Bu, ağ trafiği üzerinde daha granüler kontrol sağlar ve yedeklilik için de faydalı olabilir.