Google Cloud, Wiz Runtime Sensor'ı önizlemede yönetilen bir GKE eklentisi haline getirdi

dev.to'da yayınlanan bir yazıya göre Google Cloud, Wiz'in çekirdek düzeyindeki runtime sensörünü Google Kubernetes Engine için yönetilen bir eklenti olarak kullanıma açtı. 17 Ekim 2026'da duyurulan ve halen önizleme aşamasında olan eklenti, hem Standard hem de Autopilot cluster'larında çalışıyor. Sensörün dağıtımını, kimlik bilgilerinin enjekte edilmesini ve güncellenmesini GKE üstleniyor; böylece geleneksel olarak güvenlik satıcısının lisansına sahip olan ekibin omuzuna binen operasyonel yükler ortadan kalkıyor.

Sensör neyi izliyor

Container güvenliği uzun süredir iki bölüme ayrılıyor: bir workload çalışmadan önce kontrol edebilecekleriniz — image taramaları ve admission politikaları — ile bir uygulama başlatıldıktan sonra olanlar. Wiz Runtime Sensor bu ikinci pencereyi kapsıyor. dev.to raporunun aktardığına göre her node üzerinde sistem çağrılarını, çalışan süreçleri, ağ bağlantılarını ve dosya erişimini izliyor; işleme bir eBPF programı üzerinden yapıldığı için uygulamanın kendisine hiçbir şey bağlanmak zorunda değil.

Belgelenen tespit senaryoları arasında reverse shell'ler, /tmp dizininden çalıştırılan binary'ler, image drift ve yetki yükseltme (privilege escalation) girişimleri yer alıyor. Kaynak tüketimi bilinçli olarak sınırlı: sensör node başına sabit bir bellek limiti altında çalışıyor ve duyuru, bu özelliği özellikle node yoğunluğunun gün boyunca dalgalandığı AI workload'ları ve web servisleri için öne çıkarıyor.

Kimlik bilgileri cluster dışında kalıyor

Sürümün işletim modelini değiştiren kısım kimlik bilgisi yolu. Alışılmış kestirme yol — satıcı API anahtarını bir namespace'e Kubernetes Secret olarak bırakmak — bir güvenlik ürününü, filto ölçeğinde döndürülmesi gereken sıradan bir secret'a dönüştürüyor. Burada kimlik bilgileri Secret Manager'da tutuluyor, yalnızca adanmış bir service account tarafından okunabiliyor ve GKE bunları çekip sensör pod'larına enjekte ediyor.

Secret Manager'daki bir anahtarı döndürmek Kubernetes Secret'ı otomatik olarak yeniden senkronize ediyor; ancak dev.to yazısı, güncellenmiş registry veya API kimlik bilgilerinin kullanılabilmesi için sensörün DaemonSet'inin manuel olarak yeniden başlatılmasının hâlâ gerektiğini belirtiyor. Eklentinin etkinleştirilmesi adanmış bir gke-managed-wiz namespace'i oluşturuyor ve image'ları Wiz'in private container registry'sinden çekiyor.

Etkinleştirme tek bir bayrakla yapılıyor

Etkinleştirme, bir platform yöneticisinin zaten aşina olduğu yolu izliyor. Yeni cluster'larda oluşturma komutuna tek bir bayrak ekleniyor: --addons=WizSensor=ENABLED, yanına da registry secret'ını ve API anahtarını belirten iki Secret Manager referansı konuyor. Var olan cluster'larda eşdeğer --update-addons formu kullanılıyor.

Ön koşullar açık ve dev.to yazısının da işaret ettiği gibi asıl eşik bunlar: GKE için Workload Identity Federation ve Secret Manager secret senkronizasyonu her ikisi de hazır olmalı, çünkü workload identity'si olmayan bir cluster, kasanın kontrol ettiği service account'ı sunamaz. Giden trafiği kısıtlayan ekipler için duyuru, telemetry'nin egress kuralları açılmadan Wiz'e ulaşabilmesi amacıyla standart HTTP ve mutual TLS proxy yapılandırmalarını belgeliyor.

Kapsam cluster oluşturulurken zorunlu kılınıyor

Runtime güvenlik programlarının genellikle başarısız olduğu nokta filto geneli zorunluluk: birinin agent olmadan ayağa kaldırdığı cluster'lar korumasız kalıyor. Eklenti bunu adanmış bir Organization Policy Service kısıtıyla ele alıyor — container.googleapis.com/Cluster kapsamında, CREATE ve UPDATE metotlarına uygulanan — ve sensörün etkinleştirilmesini zorunlu kılıyor. Organization, folder veya project düzeyinde uygulandığında, runtime koruması olmadan oluşturulan her cluster'ı reddediyor ve güncellemeleri de değerlendirdiği için sonradan eklentiyi kapatma girişimleri de denetleniyor.

Telemetry, Wiz Security Graph'a akıyor

Sensörün çıktısı Wiz Security Graph'a akıyor; runtime etkinliği image taramaları, cloud posture ve kimlik verileriyle ilişkilendiriliyor. Pratik kazanç önceliklendirme: image taraması bir image'da hangi güvenlik açıklı kütüphanelerin bulunduğunu söylerken, runtime kanıtı bunlardan hangilerinin gerçekten yüklendiğini ve çalıştığını gösteriyor. Bir tehdit tetiklendiğinde tanılama verisi toplanıyor, böylece bir inceleme elinde kanıtla başlıyor.

Yazıda atıf yapılan GKE dokümantasyonuna göre sensörün ve tespit kurallarının güncellemeleri, GKE yama sürümü yükseltmelerinden bağımsız olarak dağıtılıyor; yani kural değişiklikleri bir cluster bakım penceresini beklemiyor.

Önce neleri doğrulamalı

dev.to raporu, operatörlerin bu entegrasyona güvenmeden önce kontrol etmesi gereken üç noktaya işaret ediyor: önizleme statüsünün kendisi, kısıtlı ağlarda egress proxy yolu ve GKE tarafından yönetilen kurulum ile Helm ile yönetilen kurulum arasındaki davranış farkı.

Neden önemli

Runtime güvenlik agent'ları her zaman gizli bir maliyet taşıdı: birileri onları kurmak, kimlik bilgilerini saklamak, güncel tutmak ve her yeni cluster'ı kapsamayı hatırlamak zorundaydı. Agent'ı platform katmanına katmak bu yükün büyük kısmını ortadan kaldırıyor ve organization policy, kapsamı ekip bazlı bir alışkanlıktan cluster oluşturmanın API ile zorunlu kılınan bir koşuluna dönüştürüyor. Özellikle Autopilot kullanıcıları için yönetilen, çekirdek düzeyindeki bir sensör, daha önce karşılanması güç olan bir ihtiyaca yanıt verirken, Secret Manager entegrasyonu satıcı kimlik bilgilerini cluster'a bağlı secret'lardan tamamen uzak tutuyor.