GCP IAM ile Kullanıcı ve Rol Yönetimi

Tarafındankomut
0 Comments

Bulut ortamında kimin neye erişebileceğini belirlemek, güvenliğin temel taşıdır. GCP’de bu sorumluluğu IAM (Identity and Access Management) üstlenir. Yeni bir projeye dahil olduğunuzda ya da bir ekibin bulut altyapısını devraldığınızda, önce IAM yapısına bakarsınız. Kim hangi yetkiyle ne yapıyor? Gereksiz izinler var mı? Servis hesapları düzgün yapılandırılmış mı? Bu soruların cevabı, hem güvenlik hem de operasyonel sağlık açısından kritiktir.

Bu yazıda GCP IAM’i sysadmin perspektifinden, yani “nasıl çalıştığını anlayalım” değil “gerçekten nasıl kullanılır” açısından ele alacağız.

GCP IAM’in Temel Kavramları

GCP IAM’de her şey üç kavram etrafında döner: Principal (kimlik), Role (rol), Policy (politika).

Principal, kim olduğunu tanımlar. Bir Google hesabı, bir servis hesabı, bir grup ya da bir domain olabilir.

Role, ne yapabileceğini tanımlar. Roller permission’lardan oluşur. Örneğin storage.objects.get gibi atomik izinler, roller içinde gruplanır.

Policy, kimi neye bağladığını tanımlar. Bir kaynak üzerinde hangi principal’ın hangi role sahip olduğunu binding’ler aracılığıyla belirtir.

Bu üçlü yapı, GCP’nin her seviyesinde geçerlidir: Organization, Folder, Project ve kaynak seviyesinde. Alt seviyeler üst seviyeden izinleri miras alır, bu da hiyerarşiyi dikkatli yönetmeyi zorunlu kılar.

Rol Türleri

GCP’de üç tür rol vardır:

  • Primitive Roles (Temel Roller): Owner, Editor, Viewer. Bunlar legacy rollerdir, son derece geniş izinler içerir. Üretim ortamında kullanımından kaçının.
  • Predefined Roles (Önceden Tanımlı Roller): Google tarafından sunulan, belirli servislere özel roller. roles/compute.instanceAdmin, roles/storage.objectViewer gibi. Bunlar tercih edilmelidir.
  • Custom Roles (Özel Roller): Kendi tanımladığınız roller. Minimum privilege prensibi için idealdir.

gcloud CLI ile Temel IAM Operasyonları

Günlük iş akışında Cloud Console yerine gcloud CLI kullanmak hem hızlı hem de scriptable. Önce temel komutları görelim.

Mevcut projedeki IAM politikasını listelemek için:

# Mevcut projenin IAM politikasını görüntüle
gcloud projects get-iam-policy my-project-id

# YAML formatında daha okunabilir çıktı
gcloud projects get-iam-policy my-project-id --format=yaml

# Sadece belirli bir üyenin binding'lerini filtrele
gcloud projects get-iam-policy my-project-id 
  --flatten="bindings[].members" 
  --format="table(bindings.role,bindings.members)" 
  --filter="bindings.members:user:[email protected]"

Kullanıcıya rol atamak için add-iam-policy-binding kullanılır:

# Tek kullanıcıya predefined rol ata
gcloud projects add-iam-policy-binding my-project-id 
  --member="user:[email protected]" 
  --role="roles/compute.viewer"

# Servis hesabına rol ata
gcloud projects add-iam-policy-binding my-project-id 
  --member="serviceAccount:[email protected]" 
  --role="roles/storage.objectAdmin"

# Google grubuna rol ata
gcloud projects add-iam-policy-binding my-project-id 
  --member="group:[email protected]" 
  --role="roles/container.developer"

Rol kaldırmak için:

gcloud projects remove-iam-policy-binding my-project-id 
  --member="user:[email protected]" 
  --role="roles/compute.viewer"

Servis Hesabı Yönetimi

Servis hesapları (Service Accounts), uygulamaların ve VM’lerin GCP servisleriyle iletişim kurmasını sağlar. Servis hesabı yönetimi IAM’in en kritik kısmıdır çünkü kötü yapılandırılmış bir servis hesabı ciddi güvenlik açıkları yaratır.

# Yeni servis hesabı oluştur
gcloud iam service-accounts create my-app-sa 
  --display-name="My Application Service Account" 
  --description="Production uygulaması için servis hesabı"

# Mevcut servis hesaplarını listele
gcloud iam service-accounts list --project=my-project-id

# Servis hesabına proje seviyesinde rol ata
gcloud projects add-iam-policy-binding my-project-id 
  --member="serviceAccount:[email protected]" 
  --role="roles/pubsub.publisher"

# Servis hesabı key oluştur (dikkatli kullanın!)
gcloud iam service-accounts keys create ./sa-key.json 
  [email protected]

# Mevcut keyleri listele
gcloud iam service-accounts keys list 
  [email protected]

Önemli not: Servis hesabı key dosyaları son derece hassastır. Mümkün olduğunca Workload Identity Federation veya VM’e atanmış servis hesabı kullanın, JSON key’lerden kaçının. Eğer key kullanmak zorundaysanız, Secret Manager’da saklayın ve rotasyon politikası uygulayın.

Servis Hesabına Servis Hesabı Olarak Davranmak (Impersonation)

Gerçek kullanım senaryolarında servis hesabını taklit etme (impersonation) önemli bir güvenlik pratiğidir. Key dosyası oluşturmak yerine impersonation kullanabilirsiniz:

# Kullanıcıya servis hesabını taklit etme yetkisi ver
gcloud iam service-accounts add-iam-policy-binding 
  [email protected] 
  --member="user:[email protected]" 
  --role="roles/iam.serviceAccountTokenCreator"

# Impersonation ile komut çalıştır
gcloud storage ls 
  --impersonate-service-account=my-app-sa@my-project-id.iam.gserviceaccount.com

Custom Role Oluşturma

Minimum privilege prensibini uygulamanın en iyi yolu custom role’lerdir. Örneğin bir uygulamanın sadece Cloud SQL’den veri okuyup Pub/Sub’a mesaj yayınlaması gerekiyorsa, bu iki izni içeren özel bir rol oluşturmak mantıklıdır.

Önce hangi izinlerin mevcut olduğunu öğrenelim:

# Belirli bir servis için mevcut izinleri listele
gcloud iam list-testable-permissions 
  //cloudresourcemanager.googleapis.com/projects/my-project-id 
  --filter="name:cloudsql"

# Bir rolün içerdiği izinleri görüntüle
gcloud iam roles describe roles/cloudsql.viewer

YAML dosyasıyla custom role oluşturalım:

# custom-role.yaml dosyası oluştur
cat > custom-role.yaml << 'EOF'
title: "App Data Reader"
description: "Cloud SQL okuma ve Pub/Sub yayinlama icin minimal rol"
stage: "GA"
includedPermissions:
  - cloudsql.instances.connect
  - cloudsql.instances.get
  - pubsub.topics.publish
  - pubsub.topics.get
EOF

# Custom role'ü proje seviyesinde oluştur
gcloud iam roles create AppDataReader 
  --project=my-project-id 
  --file=custom-role.yaml

# Oluşturulan rolü doğrula
gcloud iam roles describe AppDataReader --project=my-project-id

# Custom role'ü güncelle
gcloud iam roles update AppDataReader 
  --project=my-project-id 
  --add-permissions="cloudsql.databases.get"

Gerçek Dünya Senaryosu: Çok Katmanlı Erişim Yönetimi

Bir şirkette farklı ekipler farklı izin seviyelerine ihtiyaç duyar. Tipik bir yapı şöyle olabilir:

DevOps Ekibi: Compute, Kubernetes, CI/CD pipeline’larına tam erişim, billing’e salt okunur erişim. Developer Ekibi: Geliştirme projesinde tam erişim, production projesinde sadece log okuma. Security Ekibi: Tüm projelerde audit log okuma, IAM politikalarını görüntüleme ama değiştirememe. Data Ekibi: BigQuery ve Cloud Storage’a belirli erişim.

Bu yapıyı otomatize etmek için bir script yazalım:

#!/bin/bash
# team-iam-setup.sh

PROJECT_ID="my-project-id"
DEVOPS_GROUP="[email protected]"
DEV_GROUP="[email protected]"
SECURITY_GROUP="[email protected]"
DATA_GROUP="[email protected]"

echo "IAM rollerini yapilandiriyorum..."

# DevOps grubu rolleri
DEVOPS_ROLES=(
  "roles/compute.admin"
  "roles/container.admin"
  "roles/cloudbuild.builds.editor"
  "roles/billing.viewer"
  "roles/monitoring.admin"
  "roles/logging.admin"
)

for role in "${DEVOPS_ROLES[@]}"; do
  gcloud projects add-iam-policy-binding "$PROJECT_ID" 
    --member="group:$DEVOPS_GROUP" 
    --role="$role" 
    --quiet
  echo "DevOps - $role atandi"
done

# Developer grubu rolleri
DEV_ROLES=(
  "roles/clouddebugger.user"
  "roles/logging.viewer"
  "roles/monitoring.viewer"
  "roles/cloudtrace.user"
)

for role in "${DEV_ROLES[@]}"; do
  gcloud projects add-iam-policy-binding "$PROJECT_ID" 
    --member="group:$DEV_GROUP" 
    --role="$role" 
    --quiet
  echo "Developer - $role atandi"
done

# Security grubu rolleri
gcloud projects add-iam-policy-binding "$PROJECT_ID" 
  --member="group:$SECURITY_GROUP" 
  --role="roles/iam.securityReviewer" 
  --quiet

gcloud projects add-iam-policy-binding "$PROJECT_ID" 
  --member="group:$SECURITY_GROUP" 
  --role="roles/logging.privateLogViewer" 
  --quiet

# Data ekibi rolleri
DATA_ROLES=(
  "roles/bigquery.dataEditor"
  "roles/bigquery.jobUser"
  "roles/storage.objectViewer"
)

for role in "${DATA_ROLES[@]}"; do
  gcloud projects add-iam-policy-binding "$PROJECT_ID" 
    --member="group:$DATA_GROUP" 
    --role="$role" 
    --quiet
  echo "Data - $role atandi"
done

echo "IAM yapilandirmasi tamamlandi!"

Kaynak Seviyesinde IAM

IAM sadece proje seviyesinde değil, tek tek kaynaklar üzerinde de uygulanabilir. Bu özellikle büyük organizasyonlarda hassas kaynakları izole etmek için kullanışlıdır.

# Belirli bir Cloud Storage bucket'ına izin ver
gsutil iam ch 
  serviceAccount:[email protected]:objectViewer 
  gs://my-sensitive-bucket

# Bucket'ın IAM politikasını görüntüle
gsutil iam get gs://my-sensitive-bucket

# BigQuery dataset seviyesinde izin
bq query --use_legacy_sql=false 
  "GRANT `roles/bigquery.dataViewer` ON SCHEMA my_project.my_dataset TO 'group:[email protected]'"

# Compute instance seviyesinde IAM
gcloud compute instances add-iam-policy-binding my-instance 
  --zone=europe-west1-b 
  --member="user:[email protected]" 
  --role="roles/compute.instanceAdmin.v1"

IAM Denetimi ve Sorun Giderme

Kimse neden erişim alamadığını veya neden birinin beklenmedik yetkisi olduğunu araştırmak ister. GCP’nin bu konuda sunduğu araçlar oldukça güçlüdür.

Policy Troubleshooter

# Belirli bir kullanıcının belirli bir izne sahip olup olmadığını test et
gcloud policy-troubleshoot iam 
  //cloudresourcemanager.googleapis.com/projects/my-project-id 
  [email protected] 
  --permission=compute.instances.create

# Servis hesabı için kontrol
gcloud policy-troubleshoot iam 
  //storage.googleapis.com/projects/_/buckets/my-bucket 
  --principal-email=my-app-sa@my-project-id.iam.gserviceaccount.com 
  --permission=storage.objects.get

IAM Audit Logları

Cloud Audit Logs, IAM değişikliklerini takip eder. Log Explorer’dan sorgulayabilirsiniz:

# gcloud ile IAM audit loglarını sorgula
gcloud logging read 
  'logName="projects/my-project-id/logs/cloudaudit.googleapis.com%2Factivity" AND protoPayload.serviceName="iam.googleapis.com"' 
  --project=my-project-id 
  --limit=50 
  --format=json | jq '.[].protoPayload | {methodName, authenticationInfo, request}'

Kullanılmayan Rolleri Tespit Etme

Policy Analyzer ile proje genelindeki IAM kullanımını analiz edebilirsiniz:

# Belirli bir rol için kimin erişimi olduğunu sorgula
gcloud asset search-all-iam-policies 
  --scope="projects/my-project-id" 
  --query="policy:roles/editor" 
  --format="json" | jq '.[].policy.bindings[]'

# Servis hesabı kullanımını analiz et
gcloud iam service-accounts list 
  --project=my-project-id 
  --format="table(email, disabled, displayName)"

Koşullu IAM Binding’leri

GCP IAM’in güçlü özelliklerinden biri Condition’lar. Belirli koşullar altında izin verebilirsiniz: zaman bazlı erişim, kaynak etiketi bazlı erişim, istek tipi bazlı erişim gibi.

# Sadece belirli bir tarih aralığında geçerli geçici erişim
gcloud projects add-iam-policy-binding my-project-id 
  --member="user:[email protected]" 
  --role="roles/compute.viewer" 
  --condition='expression=request.time < timestamp("2024-12-31T23:59:59Z"),title=Temporary Access,description=Danismanlik sureci icin gecici erisim'

# Sadece "env=prod" etiketi olan kaynaklara erişim
gcloud projects add-iam-policy-binding my-project-id 
  --member="serviceAccount:[email protected]" 
  --role="roles/compute.instanceAdmin.v1" 
  --condition='expression=resource.matchTag("my-project-id/env", "prod"),title=Prod Only Access,description=Sadece production instance yonetimi'

IAM Best Practices: Operasyonel Öneriler

Yıllar içinde öğrenilen derslerden çıkardığım pratik öneriler:

  • Primitive roller kullanmayın: Owner ve Editor rolleri üretimde afet reçetesidir. Ekip üyesi ayrılsa bile bu roller aktif kalır ve fark edilmez.
  • Gruplara rol atayın, bireylere değil: Bireysel kullanıcılara rol atamak yönetimi imkansız hale getirir. Google Workspace grupları veya Cloud Identity grupları üzerinden yönetin. Birisi ekibe katıldığında ya da ayrıldığında sadece grup üyeliğini düzenleyin.
  • Servis hesabı key’lerini minimize edin: JSON key dosyaları secrets’tır. GCE veya GKE kullanıyorsanız, Workload Identity veya attached service account kullanın. Key rotasyonunu otomatize edin.
  • Periyodik erişim gözden geçirmesi yapın: Her çeyrekte IAM politikasını gözden geçirin. Hangi kullanıcılar artık şirkette çalışmıyor? Hangi servis hesaplarının keyleri var?
  • Least privilege ile başlayın, ihtiyaç oldukça genişletin: Tam tersini yapanlar eninde sonunda pişman olur.
  • Koşullu binding’lerle geçici erişim verin: Dış danışmanlar veya incident response için tarih sınırlı erişim kullanın.
  • IAM Recommender’ı kullanın: GCP, gereksiz izinleri tespit edip öneri sunar. Düzenli olarak kontrol edin.
  • Organization Policy ile sınırlar koyun: IAM’in üstüne Organization Policy ekleyerek servis hesabı key oluşturmayı yasaklayabilir, dışa veri aktarımını sınırlayabilirsiniz.

Terraform ile IAM Otomasyonu

Büyük ölçekli ortamlarda IAM’i kod olarak yönetmek (IaC) şarttır. Manuel değişiklikler tutarsızlığa yol açar ve denetimi zorlaştırır.

# Basit bir Terraform IAM konfigürasyonu örneği
# Bu dosyayı main.tf olarak kaydedin

# Terraform plan çalıştır
terraform init
terraform plan -out=iam-changes.tfplan

# Planı gözden geçirdikten sonra uygula
terraform apply iam-changes.tfplan

# Mevcut state'i kontrol et
terraform state list | grep google_project_iam

# Drift detection: gerçek ortam ile code arasındaki farkı bul
terraform plan -detailed-exitcode

Terraform HCL örneği ayrı bir .tf dosyasına yazılmalı, ancak burada gcloud ile eşdeğer yaklaşımı göstermek önemli. Her IAM değişikliği pull request ile gelmeli, gözden geçirilmeli ve ancak sonra uygulanmalıdır.

IAM Politikası Export ve Backup

Bir felakette IAM politikasını geri yükleyebilmek için düzenli yedek almak iyi bir pratiktir:

#!/bin/bash
# iam-backup.sh

PROJECTS=("project-1" "project-2" "project-3")
BACKUP_DIR="/backup/iam/$(date +%Y%m%d)"

mkdir -p "$BACKUP_DIR"

for project in "${PROJECTS[@]}"; do
  echo "Yedekleniyor: $project"
  
  # Proje IAM politikasını yedekle
  gcloud projects get-iam-policy "$project" 
    --format=json > "$BACKUP_DIR/${project}-iam-policy.json"
  
  # Servis hesaplarını yedekle
  gcloud iam service-accounts list 
    --project="$project" 
    --format=json > "$BACKUP_DIR/${project}-service-accounts.json"
  
  # Custom rolleri yedekle
  gcloud iam roles list 
    --project="$project" 
    --format=json > "$BACKUP_DIR/${project}-custom-roles.json"
  
  echo "$project yedeklendi."
done

echo "Tum yedekler $BACKUP_DIR dizinine kaydedildi."

# Cloud Storage'a aktar
gsutil -m cp -r "$BACKUP_DIR" gs://my-iam-backups/

Sonuç

GCP IAM, yüzeysel bakıldığında basit görünen ama derinleşince oldukça katmanlı bir sistemdir. Temel olarak şu prensipleri içselleştirirseniz çok büyük sorunların önüne geçersiniz: gruplara atama yapın, minimum privilege uygulayın, servis hesabı key’lerinden mümkün olduğunca kaçının ve her şeyi kod olarak yönetin.

Özellikle büyüyen ekiplerde IAM yönetimi bir süre sonra kontrolden çıkabilir. Bunu önlemenin yolu düzenli gözden geçirme süreçleri ve IAM Recommender gibi araçları rutin iş akışına dahil etmektir. Manuel değişiklikler her zaman bir sonraki kişinin kafasını karıştırır, bu yüzden Terraform veya Deployment Manager gibi araçlarla her şeyi versiyonlanmış tutun.

Güvenlik bir hedefe ulaşmak değil, süregelen bir süreçtir. IAM de bu sürecin en kritik parçasıdır. Bir kez yapıp bırakmak yerine, periyodik audit alışkanlığı edindiğinizde hem güvenlik duruşunuz güçlenir hem de compliance gereksinimlerini karşılamak kolaylaşır.

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir