GCP Cloud CLI ile Proje ve Kimlik Yönetimi
Google Cloud projelerini CLI üzerinden yönetmek, birçok sysadmin için başlangıçta biraz kafa karıştırıcı gelebilir. Özellikle birden fazla proje ve servis hesabıyla çalışırken hangi kimlikle hangi projeye bağlı olduğunuzu takip etmek zorlaşıyor. Bu yazıda gcloud CLI aracının proje ve kimlik yönetimi özelliklerini, gerçek dünya senaryolarıyla birlikte ele alacağız.
Neden CLI ile Proje Yönetimi?
Web konsoldan her şeyi yapabilirsiniz, bunu biliyoruz. Ama günde onlarca farklı projeye geçiş yapıyorsanız, servis hesaplarını script üzerinden yönetmeniz gerekiyorsa ya da CI/CD pipeline’larınızda GCP kaynaklarına erişim sağlamanız gerekiyorsa CLI kaçınılmaz oluyor. gcloud sadece bir araç değil, GCP yönetiminin bel kemiği haline geliyor.
Tipik bir senaryoyu düşünelim: Birden fazla müşterinin GCP altyapısını yönetiyorsunuz. Sabah birinin production ortamında bir şeye bakıyorsunuz, öğleden sonra diğerinin staging projesinde deployment yapıyorsunuz. Bu geçişleri hızlı ve hatasız yapabilmek kritik önem taşıyor.
gcloud CLI Kurulumu ve İlk Yapılandırma
Başlamadan önce sisteminizde gcloud CLI’nin kurulu olduğundan emin olun. Google Cloud SDK’yı indirip kurduktan sonra ilk yapılandırmayı başlatmak için:
gcloud initBu komut sizi interaktif bir kurulum sürecine götürür. Hesabınızı seçer, varsayılan projenizi belirlersiniz. Ancak bu sadece başlangıç noktası. Gerçek güç, yapılandırma profillerini (configuration) anladığınızda ortaya çıkıyor.
Mevcut kurulumunuzu kontrol etmek için:
gcloud infoBu çıktı size hangi hesapla giriş yaptığınızı, aktif projenizi, SDK sürümünüzü ve konfigürasyon dosyalarının nerede olduğunu gösterir. Sorun gidermede ilk bakılacak yer burasıdır.
Konfigürasyon Profilleri: Çoklu Ortam Yönetiminin Kalbi
gcloud konfigürasyonları, birden fazla GCP hesabı ve projesiyle çalışırken hayat kurtarıcı oluyor. Her konfigürasyon farklı bir profil gibi düşünebilirsiniz.
Mevcut konfigürasyonları listelemek için:
gcloud config configurations listYeni bir konfigürasyon oluşturmak için:
gcloud config configurations create musteri-a-prodBir konfigürasyonu aktif etmek için:
gcloud config configurations activate musteri-a-prodAktif konfigürasyona hesap ve proje bilgisi eklemek:
gcloud config set account [email protected]
gcloud config set project musteri-a-production-2024
gcloud config set compute/region europe-west1
gcloud config set compute/zone europe-west1-bArtık musteri-a-prod konfigürasyonunu aktif ettiğinizde, tüm komutlar otomatik olarak bu hesap ve projeyi kullanacak. Müşteri B’ye geçmek için sadece:
gcloud config configurations activate musteri-b-stagingKonfigürasyonları silmek gerektiğinde:
gcloud config configurations delete eski-konfigurasyonProje Yönetimi
Projeleri Listeleme ve Filtreleme
Erişiminiz olan tüm projeleri görmek için:
gcloud projects listOnlarca proje varsa filtreleme şart oluyor:
# İsme göre filtrele
gcloud projects list --filter="name:production"
# Belirli bir label'a göre filtrele
gcloud projects list --filter="labels.env=prod"
# Sadece belirli alanları göster
gcloud projects list --format="table(projectId, name, projectNumber)"Proje Oluşturma ve Yapılandırma
Yeni proje oluşturmak basit görünür ama bazı incelikler var. Proje ID’si global olarak benzersiz olmalı ve bir kez belirlendikten sonra değiştirilemiyor:
gcloud projects create my-app-backend-2024
--name="My App Backend"
--labels=env=prod,team=backend,owner=sysadminProjeyi oluşturduktan sonra billing hesabına bağlamayı unutmayın. Billing olmadan birçok servis kullanamıyorsunuz:
# Billing hesaplarını listele
gcloud billing accounts list
# Projeyi billing'e bağla
gcloud billing projects link my-app-backend-2024
--billing-account=0X0X0X-0X0X0X-0X0X0XAktif projeyi değiştirmek için:
gcloud config set project my-app-backend-2024Ya da tek bir komut için farklı proje kullanmak istiyorsanız (konfigürasyonu değiştirmeden):
gcloud compute instances list --project=baska-proje-idIAM ve Kimlik Yönetimi
IAM (Identity and Access Management) GCP’nin en kritik konularından biri. Kimin neye erişebileceğini doğru yapılandırmak, hem güvenlik hem de operasyonel açıdan hayati önem taşıyor.
Mevcut IAM Politikalarını İnceleme
Bir projenin IAM politikasını görmek için:
gcloud projects get-iam-policy my-app-backend-2024Çıktı YAML formatında geliyor. JSON formatında almak isterseniz:
gcloud projects get-iam-policy my-app-backend-2024
--format=json > iam-policy-backup.jsonBu çıktıyı düzenli olarak almanızı ve versiyon kontrolüne almanızı öneririm. IAM politikasında beklenmedik bir değişiklik olduğunda geri dönmek için kritik.
Rol Atama ve Yönetimi
Bir kullanıcıya rol atamak için:
gcloud projects add-iam-policy-binding my-app-backend-2024
--member="user:[email protected]"
--role="roles/compute.viewer"Rol kaldırmak için:
gcloud projects remove-iam-policy-binding my-app-backend-2024
--member="user:[email protected]"
--role="roles/compute.viewer"Bir kullanıcının hangi rollere sahip olduğunu sorgulamak:
gcloud projects get-iam-policy my-app-backend-2024
--flatten="bindings[].members"
--filter="bindings.members:[email protected]"
--format="table(bindings.role)"Servis Hesapları: CI/CD ve Otomasyon için
Servis hesapları, uygulamaların ve otomasyonların GCP API’larına erişmesi için kullanılan özel kimlikler. Gerçek kullanıcı hesapları yerine servis hesabı kullanmak, güvenlik açısından en iyi pratik.
Servis Hesabı Oluşturma
gcloud iam service-accounts create github-actions-deploy
--display-name="GitHub Actions Deployment"
--description="CI/CD pipeline için kullanılan servis hesabı"Oluşturulan servis hesabını listelemek için:
gcloud iam service-accounts listServis Hesabına Rol Atama
Servis hesabının e-posta adresi formatı: HESAP_ADI@PROJE_ID.iam.gserviceaccount.com
gcloud projects add-iam-policy-binding my-app-backend-2024
--member="serviceAccount:github-actions-deploy@my-app-backend-2024.iam.gserviceaccount.com"
--role="roles/container.developer"
gcloud projects add-iam-policy-binding my-app-backend-2024
--member="serviceAccount:github-actions-deploy@my-app-backend-2024.iam.gserviceaccount.com"
--role="roles/storage.objectAdmin"Servis Hesabı Anahtarı Oluşturma
CI/CD sistemleri için JSON key dosyası oluşturmanız gerekebilir:
gcloud iam service-accounts keys create ~/keys/github-actions-key.json
--iam-account=github-actions-deploy@my-app-backend-2024.iam.gserviceaccount.comÖnemli uyarı: Bu JSON dosyasını kesinlikle versiyon kontrolüne eklemeyin. .gitignore dosyanıza ekleyin ve güvenli bir şekilde saklayın. Mümkün olduğunda Workload Identity Federation kullanın, bu yöntem anahtar dosyası gerektirmiyor.
Mevcut anahtarları listelemek ve eski anahtarları temizlemek için:
# Anahtarları listele
gcloud iam service-accounts keys list
--iam-account=github-actions-deploy@my-app-backend-2024.iam.gserviceaccount.com
# Eski anahtarı sil
gcloud iam service-accounts keys delete ANAHTAR_ID
--iam-account=github-actions-deploy@my-app-backend-2024.iam.gserviceaccount.comApplication Default Credentials Yönetimi
Yerel geliştirme ortamında çalışırken Application Default Credentials (ADC) kullanmak en pratik yaklaşım. Kod içinde kimlik bilgisi hardcode etmek yerine, SDK’nın kimliği otomatik yönetmesine izin veriyorsunuz.
ADC’yi ayarlamak için:
gcloud auth application-default loginBu komut tarayıcı açar ve Google hesabınızla giriş yapmanızı ister. Kimlik bilgileri ~/.config/gcloud/application_default_credentials.json dosyasına kaydedilir.
Belirli bir servis hesabıyla ADC kullanmak için:
gcloud auth application-default login
--impersonate-service-account=github-actions-deploy@my-app-backend-2024.iam.gserviceaccount.comMevcut kimlik doğrulama durumunu kontrol etmek:
gcloud auth listBelirli bir hesabı aktif yapmak:
gcloud config set account [email protected]Hesap çıkışı yapmak:
gcloud auth revoke [email protected]Gerçek Dünya Senaryosu: Çoklu Müşteri Yönetimi
Diyelim ki üç farklı müşterinin GCP altyapısını yönetiyorsunuz. Her birinin birden fazla projesi var (prod, staging, dev). İşte benim kullandığım yaklaşım:
# Her müşteri için konfigürasyon oluştur
gcloud config configurations create musteri-alfa-prod
gcloud config configurations activate musteri-alfa-prod
gcloud config set account [email protected]
gcloud config set project alfa-production-proj
gcloud config set compute/region us-central1
gcloud config configurations create musteri-beta-staging
gcloud config configurations activate musteri-beta-staging
gcloud config set account [email protected]
gcloud config set project beta-staging-proj
gcloud config set compute/region europe-west1
# Hangi konfigürasyonda olduğunuzu kontrol edin
gcloud config configurations listBu yaklaşımla işe başlarken hangi müşterinin projesine geçeceğinizi bir komutla hallediyorsunuz ve yanlış projeye komut çalıştırma riskini minimize ediyorsunuz.
Shell prompt’unuza aktif GCP projesini eklemek de faydalı. .bashrc veya .zshrc dosyanıza şunu ekleyin:
# .bashrc veya .zshrc
export PS1='[u@h W $(gcloud config get-value project 2>/dev/null)]$ 'Bu sayede terminal pencerenizde her zaman hangi GCP projesinde olduğunuzu görürsünüz. Yanlış projeye komut göndermenin önüne geçen basit ama etkili bir çözüm.
Proje Düzeyinde Politika ve Kota Yönetimi
Proje kotalarını görüntülemek özellikle kaynak limitleriyle karşılaştığınızda işe yarıyor:
gcloud compute project-info describe --project=my-app-backend-2024Etkin API’ları listeleme ve yönetme:
# Etkin servisleri listele
gcloud services list --enabled
# Servis etkinleştir
gcloud services enable container.googleapis.com
# Servis devre dışı bırak (dikkatli kullanın!)
gcloud services disable container.googleapis.comProje etiketlerini yönetmek, büyük organizasyonlarda maliyet takibi ve kaynak organizasyonu için kritik:
# Etiket ekle
gcloud projects update my-app-backend-2024
--update-labels=env=prod,cost-center=backend-team,owner=sysadmin-team
# Etiket kaldır
gcloud projects update my-app-backend-2024
--remove-labels=eski-etiketGüvenlik İpuçları ve En İyi Pratikler
Kimlik ve proje yönetiminde sıkça yapılan hataları ve bunlardan kaçınma yollarını özetleyelim:
En az ayrıcalık prensibi: Servis hesaplarına ve kullanıcılara sadece ihtiyaçları olan rolleri verin. roles/owner veya roles/editor vermek kolaydır ama güvenlik açısından tehlikelidir. Granüler roller kullanın.
Servis hesabı anahtarlarından kaçının: Mümkün olduğunda Workload Identity Federation veya instance service account kullanın. Anahtar dosyaları çalındığında veya sızdığında büyük risk oluşturur.
IAM politikalarını düzenli denetleyin: Kim hangi projeye erişebiliyor? Çıkan çalışanların erişimi kaldırıldı mı? Bu soruları düzenli sormak gerekiyor.
Organizasyon politikaları kullanın: Varsa GCP Organization’ınızda organizasyon düzeyinde politikalar belirleyin. Örneğin belirli bölgeler dışında kaynak oluşturulmasını engelleyebilirsiniz.
Audit log’ları aktif edin: Kim ne zaman neye erişti? Bu soruların cevabı Cloud Audit Logs’ta. Özellikle production projeleri için Data Access audit log’larını da açın.
# Audit log politikasını görüntüle
gcloud projects get-iam-policy my-app-backend-2024
--format=json | python3 -m json.tool | grep -A 5 "auditLogConfigs"Sık Kullanılan Yönetim Komutları Özeti
Günlük işlerde en çok kullandığım komutları bir araya getireyim:
gcloud config get-value project: Aktif projeyi öğrenmek için hızlı yol, script’lerde sık kullanılır.
gcloud config configurations activate: Konfigürasyon geçişi için temel komut.
gcloud auth list: Hangi hesapların login olduğunu görmek için.
gcloud projects list –filter: Büyük organizasyonlarda proje bulmak için.
gcloud iam service-accounts list: Projedeki tüm servis hesaplarını görmek için.
gcloud projects get-iam-policy: IAM politikasını dışa aktarmak için, backup olarak saklayın.
gcloud services list –enabled: Projedeki aktif API’ları kontrol etmek için, özellikle sorun gidermede.
Sonuç
GCP CLI ile proje ve kimlik yönetimi, başta karmaşık görünse de bir sisteme oturttuğunuzda günlük operasyonlarınızı ciddi ölçüde hızlandırıyor. Konfigürasyon profilleri sayesinde birden fazla proje ve hesap arasında güvenli geçişler yapabilir, servis hesapları ve IAM rolleriyle otomasyon altyapınızı güvenli şekilde kurabilirsiniz.
En önemli tavsiyem şu: Her şeyi script’leyin ve versiyon kontrolüne alın. IAM politikalarınızı, servis hesabı yapılandırmalarınızı, hatta konfigürasyon kurulum script’lerinizi Git’te tutun. Bir gün yeni bir ekip üyesi geldiğinde ya da bir ortamı sıfırdan kurmanız gerektiğinde bu alışkanlık sizi kurtaracak. GCP’de “infrastructure as code” yaklaşımının temeli CLI komutlarının iyi anlaşılmasından geçiyor ve bu yazıdaki komutlar o temelin önemli bir parçası.