GCP - Basic Information
Kaynak hiyerarşisi
Google Cloud, kavramsal olarak geleneksel bir dosya sistemininkinden benzer olan bir Kaynak hiyerarşisi kullanır. Bu, belirli politika ve izinler için belirli ek noktalarla mantıksal bir ebeveyn/çocuk iş akışı sağlar.
Yüksek seviyede şöyle görünür:
Proje Göçleri
Herhangi bir organizasyon olmadan bir projeyi bir organizasyona göç etmek mümkündür. Bu işlem için roles/resourcemanager.projectCreator ve roles/resourcemanager.projectMover izinlerine sahip olmak gerekmektedir. Eğer proje başka bir organizasyonun içindeyse, önce onları organizasyondan çıkarmak için GCP destek ekibiyle iletişime geçmek gerekmektedir. Daha fazla bilgi için buraya bakabilirsiniz.
Organizasyon Politikaları
Organizasyonunuzun bulut kaynakları üzerinde merkezi kontrol sağlamaya olanak tanır:
Organizasyonunuzun kaynaklarının nasıl kullanılabileceğine dair kısıtlamaları yapılandırmak için merkezi kontrol sağlar.
Geliştirme ekiplerinin uyumluluk sınırları içinde kalmasını sağlamak için sınırlar tanımlar ve oluşturur.
Proje sahiplerinin ve ekiplerinin uyumluluğu bozmadan hızlı bir şekilde ilerlemelerine yardımcı olur.
Bu politikalar, tüm organizasyonu, klasör(ler)i veya proje(leri) etkileyebilir. Hedeflenen kaynak hiyerarşisi düğümünün alt kümeleri organizasyon politikasını devralır.
Bir organizasyon politikasını tanımlamak için, bir kısıtlama seçersiniz, bu belirli bir Google Cloud hizmetine veya bir grup Google Cloud hizmetine karşı bir tür kısıtlamadır. Ardından, bu kısıtlamayı istediğiniz kısıtlamalarla yapılandırırsınız.
Ortak kullanım durumları
Alan adına göre kaynak paylaşımını sınırlama.
Kimlik ve Erişim Yönetimi hizmet hesaplarının kullanımını sınırlama.
Yeni oluşturulan kaynakların fiziksel konumunu kısıtlama.
Hizmet hesabı oluşturmayı devre dışı bırakma
Varsayılan Organizasyon Politikaları
IAM Rolleri
Bu, her rolün bir dizi izni içerdiği AWS'deki IAM politikalarına benzerdir.
Ancak AWS'den farklı olarak, rollerin merkezi bir deposu yoktur. Bunun yerine, kaynaklar X erişim rollerini Y prensiplere verir, ve bir kaynağa kimin erişimi olduğunu öğrenmenin tek yolu, o kaynağın üzerinde get-iam-policy yöntemini kullanmaktır.
Bu bir sorun olabilir çünkü bu, bir prensibin hangi izinlere sahip olduğunu öğrenmenin tek yolunun, izin verdiği tüm kaynaklara sormak olduğu anlamına gelir ve bir kullanıcının tüm kaynaklardan izinleri almak için izni olmayabilir.
IAM'de üç tür rol vardır:
Temel/İlkel roller, IAM'in tanıtılmasından önce var olan Sahip, Editör ve Görüntüleyici rollerini içerir.
Önceden tanımlanmış roller, belirli bir hizmet için ayrıntılı erişim sağlar ve Google Cloud tarafından yönetilir. Birçok önceden tanımlanmış rol vardır, onların tümünü ve sahip oldukları ayrıcalıkları buradan görebilirsiniz.
Özel roller, kullanıcı tarafından belirtilen bir izin listesine göre ayrıntılı erişim sağlar.
GCP'de binlerce izin bulunmaktadır. Bir rolün bir izne sahip olup olmadığını kontrol etmek için buradan izni arayabilirsiniz ve hangi rollerin ona sahip olduğunu görebilirsiniz.
Ayrıca, her ürün tarafından sunulan önceden tanımlanmış rolleri buradan arayabilirsiniz. Bazı rollerin kullanıcılara bağlanamayacağını ve yalnızca Hizmet Hesaplarına bağlanabileceğini unutmayın çünkü içerdikleri bazı izinler. Ayrıca, izinlerin yalnızca ilgili hizmete bağlandığında etkili olacağını unutmayın.
Veya bir özel rolün burada belirli bir izni kullanıp kullanamayacağını kontrol edebilirsiniz.
Kullanıcılar
GCP konsolunda Kullanıcılar veya Gruplar yönetimi yapılmaz, bu Google Workspace'de gerçekleştirilir. Ancak Google Workspace'de farklı bir kimlik sağlayıcı senkronize edebilirsiniz.
Workspace kullanıcılarına ve gruplarına https://admin.google.com adresinden erişebilirsiniz.
MFA, Workspace kullanıcılarına zorunlu olabilir, ancak bir saldırgan MFA tarafından korunmayan GCP'ye erişmek için bir belirteç kullanabilir (kullanıcı giriş yaparak yalnızca MFA tarafından korunur: gcloud auth login).
Gruplar
Bir organizasyon oluşturulduğunda birkaç grubun kesinlikle oluşturulması önerilir. Bunlardan herhangi birini yönetiyorsanız, tüm organizasyonu veya önemli bir kısmını tehlikeye atabilirsiniz:
Grup | Fonksiyon |
| Organizasyona ait herhangi bir kaynağı yönetmek. Bu rolü dikkatlice atayın; org yöneticileri tüm Google Cloud kaynaklarına erişebilir. Alternatif olarak, bu fonksiyon çok ayrıcalıklı olduğundan, bir grup oluşturmak yerine bireysel hesapları kullanmayı düşünebilirsiniz. |
| Ağlar, alt ağlar, güvenlik duvarı kuralları ve Cloud Router, Cloud VPN ve bulut yük dengeleyicileri gibi ağ cihazları oluşturma. |
| Faturalandırma hesaplarını kurma ve kullanımlarını izleme. |
| Uygulamaları tasarlama, kodlama ve test etme. |
| Organizasyon genelinde güvenlik politikalarını oluşturma ve yönetme, erişim yönetimi ve organizasyon kısıtlama politikaları gibi. Google Cloud güvenlik altyapınızı planlarken daha fazla bilgi için Google Cloud güvenlik temelleri kılavuzuna bakın. |
| Sürekli entegrasyon ve dağıtımı destekleyen uçtan uca boru hatları oluşturma veya yönetme, izleme ve sistem sağlama. |
| |
| |
| |
| Projelerde harcamaları izleme. Tipik üyeler finans ekibinin bir parçasıdır. |
| Google Cloud organizasyonu genelinde kaynak bilgilerini inceleme. |
| Bulut güvenliğini inceleme. |
| Ağ yapılandırmalarını inceleme. |
| Denetim günlüklerini görüntüleme. |
| Güvenlik Komut Merkezi'ni yönetme. |
| Secret Manager'da sırları yönetme. |
Varsayılan Şifre Politikası
Güçlü şifreleri zorunlu kılma
8 ile 100 karakter arası
Tekrar kullanımı yok
Süresizlik yok
İnsanlar üçüncü taraf sağlayıcı aracılığıyla Workspace'e erişiyorsa, bu gereksinimler uygulanmaz.
Hizmet hesapları
Bunlar, kaynakların bağlı olabileceği ve GCP ile kolayca etkileşimde bulunabileceği temsilcilerdir. Örneğin, bir Hizmet Hesabının VM'ye bağlı kimlik doğrulama belirteçlerine erişmek mümkündür.
IAM ve erişim kapsamlarını birlikte kullanırken bazı çakışmalarla karşılaşabilirsiniz. Örneğin, hizmet hesabınızın compute.instanceAdmin IAM rolüne sahip olabilir ancak ele geçirdiğiniz örneğin https://www.googleapis.com/auth/compute.readonly kapsam kısıtlaması ile kısıtlanmış olabilir. Bu durum, örneğinize otomatik olarak atanan OAuth belirteci kullanarak herhangi bir değişiklik yapmanızı engeller.
Bu, AWS'den IAM rollerine benzer. Ancak AWS'den farklı olarak, herhangi bir hizmet hesabı herhangi bir hizmete bağlanabilir (bunu bir politika aracılığıyla izin vermesine gerek yoktur).
Karşılaşacağınız hizmet hesaplarının bir kısmı aslında GCP'yi kullanmaya başladığınızda otomatik olarak oluşturulur, örneğin:
Ancak, kaynaklara özel hizmet hesapları oluşturmak ve bunlara bağlamak da mümkündür, ki bu da şöyle görünecektir:
Erişim kapsamları
Erişim kapsamları, GCP API uç noktalarına erişmek için oluşturulan OAuth belgelerine eklenir. Bunlar OAuth belgesinin izinlerini kısıtlar. Bu, bir belgenin bir kaynağın Sahibi olmasına rağmen, belgeye o kaynağa erişim izni verilmediyse, belge o ayrıcalıkları (kötüye) kullanmak için kullanılamaz.
Google aslında öneriyor ki erişim kapsamları kullanılmasın ve tamamen IAM'a güvenilsin. Web yönetim portalı aslında bunu zorlar, ancak erişim kapsamları hala özel servis hesapları kullanılarak örneklerde uygulanabilir.
Kapsamların ne olduğunu sorgulayarak görebilirsiniz:
Önceki kapsamlar varsayılan olarak gcloud kullanılarak veriye erişmek için oluşturulanlardır. Bu, gcloud kullandığınızda önce bir OAuth belirteci oluşturmanız ve ardından uç noktalara başvurmanız gerektiği anlamına gelir.
Bu kapsamlar arasında en önemlisi muhtemelen cloud-platform'dur, bu da temelde GCP'deki herhangi bir hizmete erişilebileceği anlamına gelir.
Burada tüm olası kapsamların bir listesini bulabilirsiniz.
Eğer gcloud tarayıcı kimlik bilgilerine sahipseniz, başka kapsamlara sahip bir belirteç elde etmek mümkündür, şöyle bir şey yaparak:
Terraform IAM Politikaları, Bağlantılar ve Üyelikler
Terraform tarafından https://registry.terraform.io/providers/hashicorp/google/latest/docs/resources/google_project_iam tanımlandığı gibi GCP ile terraform kullanarak bir ilkeye erişim sağlamanın farklı yolları vardır:
Üyelikler: İlkelere kısıtlama olmaksızın rollerin üyeleri olarak ilkelere sahip olursunuz. Bir kullanıcıyı bir rolün üyesi olarak belirleyebilir ve ardından aynı rolün bir üyesi olarak bir grup belirleyebilir ve bu ilkelere (kullanıcı ve grup) diğer rollerin üyesi olarak da belirleyebilirsiniz.
Bağlantılar: Bir role çeşitli ilkelere bağlanabilir. Bu ilkelere hala bağlanabilir veya diğer rollerin üyeleri olabilir. Ancak, role bağlı olmayan bir ilke bir bağlı role üye olarak belirlenirse, bir sonraki bağlantı uygulandığında üyelik kaybolacaktır.
Politikalar: Bir politika yetkilidir, rolleri ve ilkelere gösterir ve sonra, bu ilkelere daha fazla rol ve bu rollerin daha fazla ilke sahip olamaz. Politika değiştirilene kadar (başka politikalarda, bağlantılarda veya üyeliklerde bile) rol veya ilke belirtildiğinde, tüm ayrıcalıkları o politika tarafından sınırlanır. Açıkçası, bu durum, ilkenin politikayı değiştirme veya ayrıcalık yükseltme izinleri verildiğinde atlanabilir (yeni bir ilke oluşturmak ve ona yeni bir rol bağlamak gibi).
Referanslar
Last updated
