GKE ve Cloud Run için Workload Identity: Anahtarsız Bulut Güvenliği

Bulut güvenliğinde en büyük risklerden biri, yanlış yönetilen kimlik bilgileridir. Geleneksel olarak, uygulamaların Google Cloud API'lerine erişmesi için uzun ömürlü Service Account (Hizmet Hesabı) anahtarları (JSON dosyaları) kullanılırdı. Ancak bu anahtarların sızdırılması, ciddi güvenlik açıklarına yol açabilir. Bu yazıda, Google Kubernetes Engine (GKE) ve Cloud Run üzerinde Workload Identity kullanarak bu riski nasıl ortadan kaldıracağınızı inceleyeceğiz.

Workload Identity Akışı

Neden 'Anahtarsız' (Keyless) Yaklaşım?

Birçok DevOps mühendisi, CI/CD süreçlerinde (örneğin Jenkins veya GitLab CI) veya uygulama dağıtımlarında servis hesabı anahtarlarını yönetmekte zorlanır. Bu anahtarlar:

Rotasyon gerektirir.
Geliştiricilerin bilgisayarlarında unutulabilir.
Yanlışlıkla git depolarına yüklenebilir.

AWS dünyasındaki IAM Roles for Service Accounts (IRSA) mantığına benzer şekilde, Google Cloud da Workload Identity çözümünü sunar. Bu yöntem, Kubernetes servis hesaplarını Google Cloud IAM servis hesaplarına bağlayarak, Docker konteynerlerinizin herhangi bir anahtar dosyası olmadan Google Cloud kaynaklarına erişmesini sağlar.

Workload Identity Nasıl Çalışır?

Workload Identity, GKE cluster'ınızdaki bir Kubernetes Service Account (KSA) ile bir Google Cloud IAM Service Account (GSA) arasında bir güven ilişkisi kurar. Pod içerisindeki uygulama, GKE metadata sunucusu üzerinden kimlik doğrulaması yapar ve geçici erişim tokenları alır.

Workload Identity Mimarisi

GKE Üzerinde Kurulum

Workload Identity'yi Etkinleştirin: Cluster oluştururken veya güncellerken bu özelliği açmanız gerekir.
```
gcloud container clusters update my-cluster \
  --workload-pool=PROJECT_ID.svc.id.goog
```

IAM Bağlantısını Yapın: IAM Service Account'a, Kubernetes Service Account'ı taklit etme (impersonate) yetkisi verin.

gcloud iam service-accounts add-iam-policy-binding GSA_NAME@PROJECT_ID.iam.gserviceaccount.com \
  --role roles/iam.workloadIdentityUser \
  --member "serviceAccount:PROJECT_ID.svc.id.goog[K8S_NAMESPACE/KSA_NAME]"

Kubernetes Service Account'ı Annotate Edin:

kubectl annotate serviceaccount KSA_NAME \
  --namespace K8S_NAMESPACE \
  iam.gke.io/gcp-service-account=GSA_NAME@PROJECT_ID.iam.gserviceaccount.com

Bu adımlar tamamlandığında, EKS üzerindeki Pod Identity'ye benzer şekilde, podlarınız artık doğrudan Google Cloud API'lerine (örneğin Cloud Storage veya BigQuery) güvenli bir şekilde erişebilir.

Cloud Run ve Workload Identity

Cloud Run servisi için süreç daha da basittir. Cloud Run servisiniz varsayılan olarak bir kimliğe sahiptir, ancak en iyi uygulama olarak her servis için özel bir Service Account oluşturmalısınız.

gcloud run deploy my-service \
  --image gcr.io/project/image \
  --service-account my-service-account@project.iam.gserviceaccount.com

Bu sayede, uygulamanızın sadece ihtiyaç duyduğu yetkilere sahip olmasını (Least Privilege prensibi) sağlarsınız.

Sonuç

Statik anahtarları yönetmek hem operasyonel bir yük hem de güvenlik riskidir. GKE ve Cloud Run üzerinde Workload Identity kullanarak, bu yükten kurtulabilir ve altyapınızı modern güvenlik standartlarına taşıyabilirsiniz.