GCP Organization ve Proje Hiyerarşisi Yönetimi

Tarafındankomut
0 Comments

Büyük bir şirkette GCP kullanmaya başladığınızda ilk hafta her şey güzel görünür. Birkaç proje açarsınız, kaynakları dağıtırsınız, her şey çalışır. Sonra altı ay geçer ve elinizde 40 proje vardır, kimin neye erişebildiğini bilmiyorsunuzdur, faturalandırma kaostur ve güvenlik ekibi size sürekli sorular sormaktadır. İşte bu noktada GCP’nin Organization ve Proje Hiyerarşisi’ni doğru anlamış olmanın ne kadar kritik olduğunu anlıyorsunuz.

Bu yazıda gerçek dünya senaryolarıyla GCP kaynak hiyerarşisini nasıl düzgün kurmanız gerektiğini, Terraform ile nasıl otomatize edeceğinizi ve yaygın hataları nasıl önleyeceğinizi ele alacağız.

GCP Kaynak Hiyerarşisi Nedir?

GCP’de her şey bir hiyerarşi içinde yaşar. En tepede Organization, altında Folder‘lar, onların altında Project‘ler ve en altta da Cloud Resource’lar bulunur. Bu yapıyı anlamadan GCP yönetimi yapmak, temelsiz bina inşa etmek gibidir.

Hiyerarşinin katmanları şunlardır:

  • Organization: Google Workspace veya Cloud Identity domain’inizle eşleşen kök düğüm. Şirketinizi temsil eder.
  • Folder: Departmanları, ortamları veya iş birimlerini gruplamak için kullanılır. İç içe geçebilir.
  • Project: GCP kaynaklarının yaşadığı temel birim. Her kaynak bir projeye aittir.
  • Resource: VM’ler, bucket’lar, veritabanları gibi gerçek GCP servisleri.

IAM politikaları bu hiyerarşi üzerinde miras yoluyla aşağıya doğru akar. Organization seviyesinde verilen bir izin, tüm folder’lara ve projelere yansır. Bu güçlü ama tehlikeli bir özelliktir.

Organization Kurulumu

Organization’ı oluşturmak için Google Workspace veya Cloud Identity hesabınız olması gerekir. Domain verification tamamlandıktan sonra Organization otomatik oluşur. İlk yapmanız gereken şey Organization ID’nizi öğrenmektir.

# Organization ID'nizi listeleyin
gcloud organizations list

# Çıktı şuna benzer:
# DISPLAY_NAME    ID             DIRECTORY_CUSTOMER_ID
# example.com     123456789012   C0ab1cd2e

Organization kurulduktan sonra Super Admin hesabını güvence altına alın. Bu hesabı günlük işlemler için kullanmayın. Bunun yerine granüler roller tanımlayın.

# Organization seviyesinde roller atama
gcloud organizations add-iam-policy-binding 123456789012 
  --member="user:[email protected]" 
  --role="roles/resourcemanager.organizationAdmin"

# Billing hesabını Organization'a bağlama
gcloud organizations add-iam-policy-binding 123456789012 
  --member="user:[email protected]" 
  --role="roles/billing.admin"

Folder Yapısını Tasarlamak

Folder tasarımı şirketin yönetim yapısını yansıtmalıdır. İki yaygın yaklaşım vardır: Environment-first ve Team-first.

Environment-first yaklaşımında üst seviyede Production, Staging, Development gibi ortamlar bulunur. Güvenlik politikaları ortam bazında uygulanır ve production’a erişim doğal olarak kısıtlanır.

Team-first yaklaşımında üst seviyede Platform, Backend, Data gibi takımlar bulunur. Her takım kendi ortamlarını yönetir ve özerklik daha yüksektir.

Çoğu zaman hibrit bir yaklaşım daha mantıklıdır. İşte gerçek bir şirket yapısı örneği:

Organization: example.com
├── Folder: Shared-Services
│   ├── Project: networking-prod
│   ├── Project: security-tools
│   └── Project: monitoring-central
├── Folder: Production
│   ├── Folder: Backend-Team
│   │   ├── Project: api-service-prod
│   │   └── Project: auth-service-prod
│   └── Folder: Data-Team
│       ├── Project: analytics-prod
│       └── Project: datalake-prod
├── Folder: Non-Production
│   ├── Project: backend-staging
│   ├── Project: backend-dev
│   └── Project: data-dev
└── Folder: Sandbox
    └── Project: developer-experiments

Bu yapıyı gcloud CLI ile oluşturalım:

# Ana folder'ları oluşturma
gcloud resource-manager folders create 
  --display-name="Shared-Services" 
  --organization=123456789012

# Çıktıdan folder ID'sini alın, örnek: folders/987654321098

# Alt folder oluşturma
gcloud resource-manager folders create 
  --display-name="Backend-Team" 
  --folder=folders/111222333444

# Folder listesi görüntüleme
gcloud resource-manager folders list 
  --organization=123456789012

Proje Yönetimi

Proje isimlendirme konvansiyonu kritiktir. Rastgele isimler vermek ilerleyen dönemde büyük sorun yaratır. Şu formatı öneririm:

{şirket-kısaltması}-{takım}-{servis}-{ortam}

Örnek: acme-backend-api-prod, acme-data-lake-dev

# Proje oluşturma
gcloud projects create acme-backend-api-prod 
  --name="Backend API Production" 
  --folder=111222333444

# Projeyi billing hesabına bağlama (zorunlu)
gcloud billing projects link acme-backend-api-prod 
  --billing-account=XXXXXX-YYYYYY-ZZZZZZ

# Proje bilgilerini görüntüleme
gcloud projects describe acme-backend-api-prod

# Proje etiketleme (maliyet takibi için önemli)
gcloud projects update acme-backend-api-prod 
  --update-labels=team=backend,env=prod,cost-center=engineering

Projeler üzerinde label kullanımı göz ardı edilen ama çok değerli bir pratiktir. Billing export’u BigQuery’ye yönlendirip label’lara göre sorgu çektiğinizde, hangi takımın ne kadar harcadığını görebilirsiniz.

IAM Politikaları ve En İyi Pratikler

IAM’de temel prensip least privilege‘dır: Bir kullanıcı ya da servis hesabının yalnızca işini yapmasına yetecek kadar izni olmalıdır.

# Proje seviyesinde editor rolü atama
gcloud projects add-iam-policy-binding acme-backend-api-prod 
  --member="serviceAccount:[email protected]" 
  --role="roles/editor"

# Daha granüler yaklaşım - sadece Cloud Run için izin
gcloud projects add-iam-policy-binding acme-backend-api-prod 
  --member="serviceAccount:[email protected]" 
  --role="roles/run.developer"

# IAM politikasını görüntüleme
gcloud projects get-iam-policy acme-backend-api-prod 
  --format=json

# Folder seviyesinde izin atama (altındaki tüm projelere miras geçer)
gcloud resource-manager folders add-iam-policy-binding 111222333444 
  --member="group:[email protected]" 
  --role="roles/viewer"

Sık yapılan hata: Geliştiricilere Organization veya üst Folder seviyesinde Editor rolü vermek. Bu, production dahil her şeye erişim anlamına gelir. Bunun yerine Non-Production folder’ına Editor, Production folder’ına sadece Viewer verin.

Org Policy ile Guardrail’ler Oluşturma

Organization Policy, “ne yapılabilir, ne yapılamaz” kurallarını merkezi olarak belirlemenizi sağlar. Bu, güvenlik ekibinin en güçlü silahıdır.

# Belirli bölgelerde kaynak oluşturmayı kısıtlama
gcloud org-policies set-policy policy.yaml 
  --organization=123456789012

# Mevcut politikaları listeleme
gcloud org-policies list 
  --organization=123456789012

# Bir politikanın detayına bakma
gcloud org-policies describe 
  constraints/compute.restrictCloudSQLInstances 
  --organization=123456789012

Örnek bir policy YAML dosyası:

# policy.yaml - Sadece belirli region'lara izin ver
name: organizations/123456789012/policies/gcp.resourceLocations
spec:
  rules:
  - values:
      allowedValues:
      - in:europe-west1-locations
      - in:europe-west3-locations
  inherit_from_parent: false

Sık kullanılan ve uygulamanızı önerdiğim Org Policy constraint’leri:

  • constraints/iam.disableServiceAccountKeyCreation: Servis hesabı key oluşturmayı engeller, Workload Identity kullanımını zorunlu kılar.
  • constraints/compute.requireShieldedVm: Tüm VM’lerin Shielded VM olmasını zorunlu kılar.
  • constraints/storage.uniformBucketLevelAccess: Bucket seviyesinde ACL kullanımını engeller.
  • constraints/compute.restrictCloudSQLInstances: Public IP’li Cloud SQL engellenebilir.

Terraform ile Tüm Yapıyı Kod Olarak Yönetmek

Manuel yapılan her şey tekrarlanamaz ve hata yapılabilirdir. Organization hiyerarşisini Terraform ile yönetmek, Infrastructure as Code pratiğinin olmazsa olmazıdır.

# Terraform Google provider için kimlik doğrulama
gcloud auth application-default login

# Terraform state'i GCS bucket'ta tutmak için bucket oluşturma
gcloud storage buckets create gs://acme-terraform-state 
  --project=acme-shared-infra 
  --location=europe-west1 
  --uniform-bucket-level-access

Basit bir Terraform modülü:

# main.tf - Organization hiyerarşisi
# Bu dosyayı terraform/ klasörüne koyun

# Folder oluşturma
resource "google_folder" "production" {
  display_name = "Production"
  parent       = "organizations/123456789012"
}

resource "google_folder" "non_production" {
  display_name = "Non-Production"
  parent       = "organizations/123456789012"
}

# Proje oluşturma
resource "google_project" "api_prod" {
  name            = "Backend API Production"
  project_id      = "acme-backend-api-prod"
  folder_id       = google_folder.production.name
  billing_account = var.billing_account_id

  labels = {
    team        = "backend"
    env         = "prod"
    managed_by  = "terraform"
  }
}

# IAM binding
resource "google_folder_iam_member" "backend_dev_viewer" {
  folder = google_folder.production.name
  role   = "roles/viewer"
  member = "group:[email protected]"
}
# terraform apply öncesi plan çıktısını kaydetme
terraform plan -out=tfplan

# Değişiklikleri uygulama
terraform apply tfplan

# Belirli bir resource'u silmeden önce state'den çıkarma
terraform state rm google_project.api_prod

Maliyet Yönetimi ve Bütçe Alarmları

Hiyerarşi düzgün kurulmadan maliyet yönetimi yapılamaz. Label’lar ve proje yapısı doğru kurulduktan sonra billing export’u BigQuery’ye yönlendirin.

# Billing export BigQuery'ye yönlendirme (önce dataset oluşturun)
bq mk --dataset 
  --location=EU 
  acme-billing-export:billing_data

# Bütçe alarm oluşturma (API üzerinden)
# Önce billing account ID'nizi öğrenin
gcloud billing accounts list

# Proje bazlı bütçe alarm - Cloud Billing API
curl -X POST 
  -H "Authorization: Bearer $(gcloud auth print-access-token)" 
  -H "Content-Type: application/json" 
  -d '{
    "displayName": "Backend API Prod Monthly Budget",
    "budgetFilter": {
      "projects": ["projects/acme-backend-api-prod"]
    },
    "amount": {
      "specifiedAmount": {
        "currencyCode": "EUR",
        "units": "500"
      }
    },
    "thresholdRules": [
      {"thresholdPercent": 0.5},
      {"thresholdPercent": 0.9},
      {"thresholdPercent": 1.0}
    ]
  }' 
  "https://billingbudgets.googleapis.com/v1/billingAccounts/XXXXXX-YYYYYY-ZZZZZZ/budgets"

Her proje için bütçe alarm kurmak iş yükü gibi görünse de bu alarmlar sizi büyük sürprizlerden korur. Özellikle Sandbox folder’ındaki projelere agresif bütçe limitleri koyun.

Gerçek Dünya Senaryosu: Migration Süreci

Yeni bir müşteri projesinde tipik bir senaryo: Şirketin 25 projesi vardı, hiç folder yoktu, hepsi Organization root’una bağlıydı. IAM verilmemiş ve güvenlik denetimlerinde sürekli bulgu çıkıyordu.

Yeniden yapılandırma süreci şu adımları izledi:

# Mevcut projeleri listeleme ve audit
gcloud projects list --format="table(projectId,name,parent.id)" 
  --filter="lifecycleState=ACTIVE"

# Proje sayısını öğrenme
gcloud projects list --format="value(projectId)" | wc -l

# Her projenin IAM politikasını dışa aktarma
for project in $(gcloud projects list --format="value(projectId)"); do
  echo "=== $project ===" >> iam_audit.txt
  gcloud projects get-iam-policy $project 
    --format=json >> iam_audit.txt 2>/dev/null
done

# Projeyi yeni folder'a taşıma
gcloud projects move acme-backend-api-prod 
  --folder=111222333444

Migration sırasında dikkat edilmesi gerekenler:

  • Proje taşıma işlemi IAM mirasını değiştirir, öncesinde audit yapın.
  • Servis hesapları proje bazlıdır, taşıma onları etkilemez.
  • Org Policy değişiklikleri anlık etkili olur, plan yapın.
  • Billing bağlantısı proje taşımada korunur.

Shared VPC ile Network Yönetimi

Büyük organizasyonlarda her projenin kendi VPC’si olması yönetimi zorlaştırır. Shared VPC ile network’ü merkezi bir host project‘te tutup diğer service project‘leri buraya bağlayabilirsiniz.

# Shared VPC host project belirleme
gcloud compute shared-vpc enable acme-networking-prod

# Service project'i host'a bağlama
gcloud compute shared-vpc associated-projects add 
  acme-backend-api-prod 
  --host-project=acme-networking-prod

# Subnet bazlı IAM - sadece belirli subnet'e erişim
gcloud compute networks subnets add-iam-policy-binding backend-subnet 
  --region=europe-west1 
  --member="serviceAccount:[email protected]" 
  --role="roles/compute.networkUser" 
  --project=acme-networking-prod

Bu yaklaşımın avantajları:

  • Network politikaları merkezi yönetilir.
  • Firewall kuralları tek noktadan kontrol edilir.
  • Her takım kendi projesinde çalışır ama ortak network’ü kullanır.
  • VPC Service Controls daha etkin uygulanabilir.

Monitoring ve Audit Log Yapısı

Organization seviyesinde merkezi log toplama kurulumu:

# Organization seviyesinde log sink oluşturma
gcloud logging sinks create org-audit-sink 
  storage.googleapis.com/acme-audit-logs 
  --organization=123456789012 
  --include-children 
  --log-filter='logName:"cloudaudit.googleapis.com"'

# BigQuery'ye sink (analiz için)
gcloud logging sinks create org-audit-bq-sink 
  bigquery.googleapis.com/projects/acme-security/datasets/audit_logs 
  --organization=123456789012 
  --include-children 
  --log-filter='logName:"cloudaudit.googleapis.com" AND 
    protoPayload.methodName!="storage.objects.get"'

# Sink'in service account'ına bucket yazma izni verme
gcloud logging sinks describe org-audit-sink 
  --organization=123456789012 
  --format="value(writerIdentity)"
# Çıktıdaki service account'a bucket'a objectCreator rolü verin

--include-children flag’i kritiktir. Bu olmadan sadece Organization root’undaki loglar yakalanır, alt proje logları kaçar.

Sonuç

GCP Organization ve Proje Hiyerarşisi, üzerine her şeyi inşa edeceğiniz temeldir. Bu temel yanlış kurulursa güvenlik açıkları, maliyet kaosları ve yönetim cehennemleri kaçınılmaz olur.

Özetlemek gerekirse dikkat etmeniz gereken kritik noktalar:

  • Baştan planlayın: Folder yapısını işe başlamadan önce tasarlayın. Sonradan değiştirmek zordur.
  • Her şeyi etiketleyin: Proje, VM, bucket fark etmez. Maliyet takibi için label olmadan kör uçarsınız.
  • IAM’de least privilege: Editor rolünü kimseye kolayca vermeyin. Granüler roller zaman alır ama güvenliği sağlar.
  • Org Policy’yi erken uygulayın: Güvenlik guardrail’lerini baştan koyun, retroaktif olarak uygulamak çok daha zordur.
  • Terraform kullanın: Organization hiyerarşisini elle yönetmek ölçeklenemez. Kodu yazmak için harcanan zaman fazlasıyla geri döner.
  • Merkezi log ve monitoring: --include-children ile tüm organizasyonu kapsayan audit log yapısı kurun.
  • Shared VPC değerlendirin: 5’ten fazla projeniz varsa network merkezileştirmesi ciddi yönetim kolaylığı sağlar.

Bu yapıyı doğru kurduğunuzda, yeni bir takım geldiğinde Terraform ile birkaç dakikada izole bir ortam açabilir, güvenlik ekibi rahatlayabilir ve siz de gece 2’de kimden ne erişimi aldığını araştırmak yerine uyuyabilirsiniz.

Bir yanıt yazın

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