Google Cloud'da organizasyon, klasör, proje ve IAM yetkilendirme düzeni

Hiyerarşi: organizasyon, klasör, proje, kaynak

Google Cloud'da kaynaklar bir ağaç oluşturur. En üstte organizasyon, onun altında isteğe bağlı klasörler, klasörlerin altında projeler ve projelerin içinde sanal makineler, depolama kovaları gibi servis kaynakları bulunur. Hiyerarşinin en üstündeki dışında her kaynağın tam olarak bir üst öğesi vardır; bu kural, yetkinin ve politikanın nereden geldiğini izlemeyi kolaylaştırır.

Organizasyon düğümü için bir Google Workspace ya da Cloud Identity hesabı gerekir. Yönetilen kullanıcıların oluşturduğu projeler varsayılan olarak organizasyona bağlanır; böylece bir çalışan şirketten ayrıldığında proje şirkette kalır. Klasörler isteğe bağlıdır; departman, ekip ya da uygulama gibi gruplamalar için kullanılır, iç içe olabilir ve yönetim yetkisini devretmeye yarar. Proje ise Google Cloud'u kullanmak için gereken temel birimdir.

Proje kimlikleri: ad, ID ve numara

Bir projenin birkaç tanımlayıcısı vardır ve bunlar birbirine karıştırılır: • Proje adı: arayüzde görünen, sonradan değiştirilebilen görünen addır; benzersiz olmak zorunda değildir. • Proje kimliği (ID): oluştururken sizin seçtiğiniz benzersiz tanımlayıcıdır ve komutlarda, betiklerde, API çağrılarında kullanılır. • Proje numarası: sistem tarafından otomatik üretilir, salt okunurdur ve bazı isteklerde ID yerine kullanılabilir.

Google'ın belgesi, arayüzde görünen ad dizesinin proje kaynak kimliğiyle aynı olmadığını açıkça belirtir. Bu yüzden betik yazarken ve rol atarken görünen ada değil kimliğe dayanın. Kimlik bir kez seçilince anlamlı ve kalıcı olmalıdır; "deneme" ya da "yeni-proje" gibi adlar sonradan karmaşa yaratır.

IAM'in temel kavramları: kimlik, izin, rol ve allow policy

IAM (Identity and Access Management), kimin hangi kaynakta ne yapabileceğini belirler. Şu kavramları ayırmak yeterlidir: • Principal (kimlik): Google Cloud'a kimliğini doğrulamış varlık. Gruplara ayrılır: insanlar (Google hesapları, gruplar) ve iş yükleri (servis hesapları). • İzin (permission): servis.kaynak.eylem biçiminde yazılır. İzinleri doğrudan bir kimliğe veremezsiniz. • Rol: izinleri paketleyen yapı. İzinler rollerle verilir. • Allow policy: bir kaynağa eklenen YAML ya da JSON nesnesidir. İçinde, rolleri kimliklerle ilişkilendiren rol bağlamaları (role bindings) bulunur. Birisi kaynağa erişmeye çalıştığında IAM bu politikaya bakar.

Yetki vermek demek, doğru kimliği doğru rolle doğru kaynak seviyesinde bağlamaktır. Bu parçalardan biri yanlışsa ya erişim eksik kalır ya da gereğinden geniş olur.

Rol türleri: temel, önceden tanımlı ve özel

Roller sınıflara ayrılır. Temel roller çok geniş yetki verir; Google'ın belgesi bunların üretim ortamlarında kullanılmaması gerektiğini söyler. Önceden tanımlı roller, Google Cloud servislerinin yönettiği, belirli bir görev için kurgulanmış rollerdir (örneğin sanal makine yönetimi için Compute Instance Admin (v1)). Özel roller ise yalnızca sizin seçtiğiniz izinleri içeren, kendi oluşturduğunuz rollerdir.

Pratik kural: önce önceden tanımlı rollerle ihtiyacı karşılamayı deneyin, tam uymuyorsa özel rol oluşturun, temel rolleri yalnızca deneme projelerinde kullanın. İş görmeye yetecek en dar rolü vermek, olası hatanın ve istismarın etkisini küçültür.

Devralma: üstteki politika alttakini etkiler

Allow policy, deny policy ve organizasyon politikaları üstten alta doğru akar. Bir klasöre ya da organizasyona verdiğiniz rol, altındaki bütün projeleri ve kaynakları kapsar. Bir kaynağın geçerli yetkisi, kendisine doğrudan bağlananlarla atalarından devraldıklarının birleşimidir; Google bunu etkin allow policy olarak adlandırır.

Bu mantık hem fayda hem risk getirir. Olumlu tarafı, bir ekibe klasör seviyesinde bir rol vermek altındaki bütün projelere tek hamlede yetki dağıtmaktır. Riskli tarafı ise yanlış bir üst seviye atamanın geniş bir alana yayılmasıdır. Örneğin organizasyon seviyesinde bir geliştiriciye geniş rol vermek, bütün projelerde o rolün geçerli olması demektir. Bu yüzden rolü ihtiyaç duyulan en alt seviyede vermek temel prensiptir.

Adım adım kurulum akışı

Örnek bir şirket yapısını düşünün: ürünler, ortamlar ve ekipler var. Önerilen akış şöyledir: • Organizasyon düğümünü Workspace ya da Cloud Identity ile oluşturun ve yönetici grubunu tanımlayın. • Klasörleri iş yapınıza göre kurun: departman, ekip ya da uygulama bazında. Ortam ayrımı (geliştirme, test, üretim) gerekiyorsa projeleri ayrı tutun. • Her proje için anlamlı bir kimlik seçin ve projeyi doğru klasörün altında oluşturun. • Yetkileri tek tek kullanıcıya değil gruplara verin: kişi değiştiğinde yalnızca grup üyeliği güncellenir. • Rolü klasör ya da proje seviyesinde bağlayın.

Komut satırıyla bir proje seviyesi rol bağlaması şu biçimdedir (köşeli alanları değiştirin):

gcloud projects add-iam-policy-binding [proje-kimligi] --member="group:[grup-adresi]" --role="roles/[rol-adi]"

Bağlamadan sonra politikayı okuyup ekibin gerçekten istenen erişime sahip olduğunu doğrulayın.

Sık yapılan yetki hataları

• Temel rolleri (geniş yetki) üretim projelerinde bırakmak.
• Yetkiyi kişiye doğrudan vermek; ayrılan çalışandan yetkiyi toplamak güçleşir.
• Rolü gerektiğinden üst seviyede bağlamak; devralma nedeniyle istenmeyen kaynaklar kapsanır.
• Proje adı ile proje kimliğini karıştırmak; betikler yanlış projeye işlem yapar.
• Her şeyi tek bir projeye yığmak; yetki ve maliyet sınırları bulanıklaşır.
• Yetki incelemesini yapmamak; kişi değişimleri sonrası eski roller kalır.

Düzenli bir yetki incelemesi yapın: kimin hangi rolle hangi seviyede erişimi olduğunu listeleyin ve artık gerekmeyenleri kaldırın. Örneğin bir ekip projeden ayrıldığında grubun rolü hâlâ klasörde duruyorsa, o grubun yeni üyeleri istemeden eski projenin kaynaklarına erişebilir. İnceleme, bu tür unutulmuş atamaları ortaya çıkarır ve ayrıca denetim sırasında kanıt olarak kullanılabilir.

Bu beceriyi Mindset programlarında nerede çalışırsınız?

Google Cloud Platform Temelleri eğitimi, bulut ortamını yeni kuran ya da devralan yazılım ve altyapı ekiplerine uygundur; Kimlik ve Erişim Yönetimi modülü bu sayfadaki kavramları uygulamalı biçimde ele alır. GCP Associate Cloud Engineer Hazırlık eğitimi ise bulut altyapısını işletecek mühendisler içindir; IAM ve Güvenlik Yönetimi modülü, yetki verme ve güvenlik kararlarına odaklanır.

Kurumsal ekipler için özellikle önemli olan, yetkilendirme kuralının (grup bazlı, en az yetki, üst seviyede dar atama) ekip standardı olarak yazılı hale gelmesidir.