Google, Kritik Güvenlik Açığı İçin 'Güzel Yakalama' Dedi Ama Ödül Vermedi, Hâlâ Düzeltmedi

Config Connector Nasıl Çalışır ve Sorun Nerede?

Config Connector, kuruluşların GCP kaynaklarını (bulut depolama, veritabanları, IAM politikaları gibi) Kubernetes komutları aracılığıyla yönetmesini sağlayan bir Kubernetes operatörüdür . Temel amacı, araçları birleştirmektir: Bulut kaynaklarını tanıdık Kubernetes komut satırı aracı kubectl ile oluşturabilir, güncelleyebilir ve silebilirsiniz .

O'Leary, bu birleşik yaklaşımın tehlikeli bir yan etkisi olduğunu keşfetti. Açık, herhangi bir Kubernetes namespace kullanıcısının Google Cloud Platform'un Kimlik ve Erişim Yönetimi (IAM) kontrollerini atlamasına olanak tanıyor. Tek bir Kubernetes namespace'ine temel erişimi olan bir geliştirici, bu açığı kullanarak tüm bir kuruluşun GCP ortamının tam yönetici kontrolünü ele geçirebiliyor, yani tüm bulut hesabının sahibi olabiliyor . O'Leary, The Register'a verdiği demeçte, açığın yaklaşık beş saniyede kullanılabileceğini ve arkada hiçbir denetim izi (audit trail) bırakmadığını söyledi .

Teknik Mekanizma: Namespace'ler Arası Yetki Yükseltme

Google sorunun ayrıntılı bir teknik açıklamasını yayınlamamış olsa da, birden fazla kaynak ve O'Leary'nin raporu, güvenlik açığının Config Connector'ın IAM izinlerini farklı Kubernetes namespace'leri arasında nasıl ele aldığıyla ilgili olduğunu gösteriyor .

Düzgün yapılandırılmış çok kiracılı (multi-tenant) bir GKE kümesinde, farklı namespace'lerin birbirinden izole olması gerekir. A namespace'indeki bir kullanıcı, B namespace'indeki kaynakları yönetememeli veya kendisine yükseltilmiş GCP rolleri atayamamalıdır. O'Leary'nin keşfi, Config Connector'ın IAM kaynak türlerinin bu namespace sınırlarını zorunlu kılmadığını gösteriyor . Tek bir namespace içinden Config Connector aracılığıyla bir IAM politikası kaynağı oluşturarak veya değiştirerek, minimum Kubernetes iznine sahip bir kullanıcı kendisine GCP projesinde (hatta tüm kuruluşta) roles/owner rolünü atayabiliyor .

Bu, en az ayrıcalık (principle of least privilege) ilkesinin ihlalidir ve GCP'nin IAM yetkilendirme katmanının doğrudan bir atlatılmasıdır. Bu, bir yöneticinin düzeltebileceği bir yanlış yapılandırma değil, Config Connector'ın IAM yetkisini nasıl devrettiğine dair bir tasarım düzeyi hatasıdır .

Zaman Çizelgesi: 'Güzel Yakalama'dan 'Amaçlandığı Gibi Çalışıyor'a

The Register'ın 18 Haziran 2026 tarihli özel haberine ve doğrulayıcı kaynaklara göre, olaylar şu şekilde gelişti:

• Mart sonu / Nisan başı 2026 (yaklaşık): O'Leary açığı keşfeder ve ayrıntılı bir raporu Google'ın Cloud Güvenlik Açığı Ödül Programı'na (Cloud VRP) sunar. Rapor, bir saldırganın namespace kullanıcısından GCP kuruluş sahibine nasıl yükselebileceğini gösteren bir kanıt (proof of concept) içerir .
• İlk değerlendirme: Google'ın hata ödülü ekibi başvuruyu inceler, yüksek öncelikli ve yüksek şiddetli bir güvenlik açığı olarak kategorize eder ve bir Google temsilcisi kişisel olarak 'Güzel yakalama!' yanıtını verir .
• ~Mayıs/Haziran 2026: Google, herhangi bir düzeltme yayınlamadan kararını tersine çevirir. Şirket raporu kapatır ve davranışın 'amaçlandığı gibi çalıştığını' belirterek Cloud VRP kuralları kapsamında bir güvenlik açığı olarak nitelendirilmediğini söyler. Herhangi bir ödül verilmez .
• 18 Haziran 2026 itibarıyla: Açık hâlâ düzeltilmemiştir. Ancak O'Leary'nin hata raporu, Google'ın takip sisteminde hâlâ 'yüksek öncelikli' ve 'kabul edildi' olarak işaretlidir ki bu bariz bir çelişkidir . Vaka neredeyse üç aydır açık durumdadır .

Google Neden Ödülü Reddetmiş Olabilir?

Google, kararını kamuoyu önünde açıklamadı ancak Cloud VRP kuralları ve Google'ın 2026 program değişikliklerinin genel bağlamı göz önüne alındığında birkaç faktör etkili olmuş olabilir.

Resmi Cloud VRP kuralları şunu belirtiyor: "Müşteriye ait kaynakların test edildiği Google Cloud güvenlik açığı raporları ödüllere uygun değildir." Program kapsamı, açıkça Google'a ait altyapı ve hizmetlerdeki güvenlik açıklarıyla sınırlıdır, müşteri tarafından yapılandırılabilir bileşenlerle değil . Google, Config Connector'ın davranışını müşteri yapılandırmasıyla ilgili bir mesele olarak kabul ederse, bu ifadeye dayanarak ödülü reddetmesi teknik olarak mümkündür.

Ayrı bir olasılık: Cloud VRP kuralları, programın kapsamdaki öğeler için "kimlik doğrulama veya yetkilendirme kusurlarını" kapsadığını belirtir . Bu, O'Leary'nin bulgusunu kapsamalıdır. Ancak Google, geçmişte belirli izinler gerektiren yetki yükseltmelerinin hata olmadığını savunmuş ve bu durum araştırmacılar tarafından eleştirilmişti . O'Leary'nin durumunda, gerekli olan ilk izin (Config Connector kaynaklarına namespace düzeyinde erişim) minimum düzeydedir ve geliştiricilere yaygın olarak verilir, bu da yetki yükseltmesini hem gerçek hem de tehlikeli kılar .

Üçüncü bir faktör, Google'ın 2026 Güvenlik Açığı Ödül Programı elden geçirmesiyle ilgilidir. Nisan sonu ve Mayıs 2026 başında Google, yapay zeka kaynaklı düşük kaliteli başvurulardaki artışı gerekçe göstererek Chrome ödemelerini kestiğini ve ödülleri yeniden yapılandırdığını duyurdu . Şirket, "kaliteye ve gerçek dünyadaki etkiye yalnızca hacimden daha fazla odaklanmak için Android ve Chrome genelinde bazı ödül miktarlarını ve bonusları azalttığını" belirtti . O'Leary'nin davası ayrı bir program olan Cloud VRP kapsamında olsa da, şirketin ödemeleri sıkılaştırma yönündeki kamuya açık tutumu, özellikle Google Config Connector sorununu bir hata yerine bir tasarım tercihi olarak gördüyse, bu kararı etkilemiş olabilir .

Büyüyen Araştırmacı Tepkisi

Olay, güvenlik araştırmacıları topluluğunda eleştirilere yol açtı. Bazıları Google'ın, yapay zeka başvuruları anlatısını, meşru ve manuel olarak keşfedilen güvenlik açıklarını reddetmek için bir bahane olarak kullandığını öne sürüyor . PC Perspective'in yorumu, kararı "hata ödüllerinde cimrileşmek" olarak nitelendirdi ve Google'ın ilk övgüsü ile nihai reddi arasındaki tutarsızlığa dikkat çekti . Cyber News Live, açığın arkasında hiçbir kayıt bırakmadan beş saniyelik bir ele geçirmeye izin verebileceğini vurguladı .

Bu dava, Google'ın aynı anda belirli Android hataları için en yüksek ödülleri artırdığı (kalıcı Titan M sıfır tıklamalı istismarlar için 1,5 milyon dolara kadar) bir döneme denk geliyor . Derin donanım açıklarını cömertçe ödüllendirirken, ciddi bir bulut IAM atlatması için takdiri bile reddetmek, Google'ın hata ödülü programlarının riski dürüstçe değerlendirmek yerine stratejik olarak bütçe ayırdığı algısını güçlendiriyor .

Bu, Config Connector Kullanan Kuruluşlar İçin Ne Anlama Geliyor?

Çok kiracılı veya paylaşımlı GKE kümelerinde Config Connector çalıştıran kuruluşlar, bunu acil ve düzeltilmemiş bir risk olarak ele almalıdır. Google'dan resmi bir yama gelene kadar aşağıdaki önlemler riski azaltabilir:

• Kubernetes RBAC politikaları kullanarak iam* kaynak oluşturmayı namespace düzeyinde kısıtlayın. Güvenilmeyen namespace'lere IAMPolicy, IAMPolicyMember veya IAMPartialPolicy özel kaynakları üzerinde create, update veya Delete izinleri vermeyin.
• Namespace modu (namespace-mode) Config Connector kullanın ve her namespace için ayrı, düşük ayrıcalıklı servis hesapları atayın. Google'ın dokümantasyonu bu yapılandırmayı desteklemektedir ve patlama yarıçapını (blast radius) sınırlar .
• Config Connector kaynaklı GCP IAM değişikliklerini izleyin. Denetim günlüklerini etkinleştirin ve GKE kümenizden gelen setIamPolicy çağrıları için uyarılar kurun.
• Çok kiracılı izolasyonun gerekli olduğu ortamlarda, Google sorunu çözene kadar Config Connector'ı devre dışı bırakmayı düşünün.

Google'ın kaynaklara IAM ile erişimi güvence altına almaya ilişkin resmi dokümantasyonu önerilen yapılandırmaları açıklasa da, O'Leary'nin raporunun merkezindeki namespace'ler arası atlatma vektörünü ele almamaktadır . Kuruluşlar, Config Connector dağıtımlarının savunmasız olabileceğini varsaymalıdır.

Önemli Çıkarımlar

• Google'ın Config Connector'ındaki bir yetki yükseltme açığı (CVSS 10.0), herhangi bir Kubernetes namespace kullanıcısının GCP projesinin tam sahipliğini elde etmesine olanak tanır.
• Google'ın hata ödülü ekibi raporu başta yüksek öncelikli olarak kabul etti, ardından kararını tersine çevirerek 'amaçlandığı gibi çalıştığını' beyan etti ve ödülü reddetti.
• İlk rapordan neredeyse üç ay sonra, güvenlik açığı hâlâ düzeltilmemiş durumda ve Google'dan bir düzeltme zaman çizelgesi bulunmuyor.
• Olay, Google'ın 2026 program değişiklikleriyle (Chrome ödemelerini keserken Android ödüllerini artırması) aynı döneme denk geliyor ve bu da şirketin güvenlik araştırmacılarıyla olan ilişkisini zorlaştırıyor.