Shopify, açık ingress’leri config yerine envanterden tarıyor

Shopify Overexposed, GKE üzerindeki Kubernetes ingress’lerini ve Cloud Run servislerini authentication olmadan internete açık olup olmadıklarına göre tarayan bir iç araç. Repository config dosyalarına dayanan ilk sürüm hatalı alarm ve kör nokta ürettiği için ekip aracı Cloud Asset Inventory ve anonim HTTP isteği üzerine yeniden kurdu. Birkaç haftalık ayarla belirsiz ingress kararları yaklaşık yüzde 80 azaldı.

Cloud Asset Inventory nedir, ne işe yarar?

Cloud Asset Inventory, Google Cloud’daki kaynakların ve IAM politikalarının envanterini tutan yönetilen bir hizmettir. Projeler ve organizasyon genelinde hangi kaynağın var olduğunu ve nasıl yapılandırıldığını sorgulamak için kullanılır. Güvenlik ve platform ekipleri bunu denetim, uyumluluk ve exposure analizinde başvuru kaynağı olarak kullanır. AWS tarafında AWS Config benzer bir rol üstlenir.

Repository niyeti gösterir, cluster uygulananı

Exposure kontrolünüz yalnızca CI’daki config taramasıysa, gerçekte neyin açık olduğunu bilmiyorsunuz. Shopify’ın ilk sürümü tam bu yüzden üç yerden kırıldı.

Proxy authentication annotation’larını doğrudan yazan ekipler false positive (yanlış pozitif) alarmlara düştü. Her cluster’da çalışmayan admission controller’lar, doğru görünen bir ayarı etkisiz bıraktı. Başka repository’lerden ya da platform araçlarından gelen ingress’ler hiç görünmedi. GKE kullanan ve tek bir altyapı repository’sine güvenen her ekipte aynı kör noktalar büyük ihtimalle var.

Shopify Overexposed nasıl çalışıyor?

• Zamanlanmış çalışıyor ve Cloud Asset Inventory’yi sorguluyor. Envanterde GKE’nin admission sonrası kabul ettiği ingress’ler, Cloud Run servisleri ve load balancer’lar var.
• Access policy’ler ikinci bir aramayla, cluster credential’ı olmadan çekiliyor.
• Her aday tek bir anonim istek alıyor: önce HEAD, olmazsa GET, en fazla üç redirect ve her birinde ayrı kontrol. Path kuralları büyük-küçük harfe duyarlı olabildiği için /ADMIN gibi varyasyonlar da deneniyor.
• Sonuç altı karardan birine düşüyor: exposed, expected, protected, not found, unreachable, inconclusive.

Envanter, ilk tarayıcının hiç bakmadığı projelerdeki Cloud Run servislerini de ortaya çıkarmış. Asıl kazanç da burada.

403 ve 404 koruma kanıtı değil

Yazının en çok iş gören kısmı status code yorumu. Ingress arkasında 404, proxy’nin cevap verdiğini ve path’in olmadığını gösteriyor. Cloud Run’da ise Google’ın front end’i uygulama çalışmadan 404 dönebiliyor. Bu yüzden Shopify Overexposed bunu inconclusive sayıyor. 403 de tek başına protected kararı vermiyor.

Cloud Run’da ingress ayarı ile IAM (Identity and Access Management) ayrı şeyler. Servis ancak allUsers invoker rolündeyse ya da invoker kontrolü kapalıysa public. Elle hızlı bir kontrol için:

gcloud run services get-iam-policy SERVIS_ADI --region=BOLGE
curl -sI -o /dev/null -w "%{http_code}\n" https://ornek-host/ADMIN

İlk çıktıda allUsers görüyorsanız servis herkese açık. İkinci komut dışarıdan ne döndüğünü gösterir ama karar için tek başına yetmez. Load balancer arkasındaki servislerde URL map’e bakın. Hangi path’in hangi backend’e gittiği ve Identity-Aware Proxy’nin nerede zorunlu olduğu orada görünür.

Belirsiz sonuç protected’a düşmüyor

Temmuzdaki bir çalıştırmada sonuçların kabaca dörtte üçü inconclusive çıkmış. Ekip sonuçları nedene göre gruplamış ve kanıt olan yerlerde yeni kararlar eklemiş. Kural değişikliklerini de yayına almadan önce kaydedilmiş tarama sonuçları üzerinde yeniden oynatmış.

Burada tasarım tercihi önemli. Alarm sayısını düşürmek için belirsizi “korumalı” saymak cazip gelir. Ama bu, false negative (yanlış negatif) üretmenin en sessiz yolu.

Allowlist de unutulup kalmıyor. Expected kararı tam host ve path eşleşmesi istiyor, listedeki girişler her çalıştırmada yeniden probe ediliyor. Artık korunan ya da kaybolan giriş stale olarak işaretleniyor. Araç karar, gerekçe ve ekip sahipliğini saklıyor, response body ve credential saklamıyor.

Tarayıcının kendisi bir SSRF hedefi

Keyfi hostname’lere istek atan bir araç, SSRF (Server-Side Request Forgery) için hazır kapı. Shopify’ın hardening (sıkılaştırma) adımları şunlar:

• DNS’ten dönen her IP doğrulanıyor, private ve loopback adresler reddediliyor.
• DNS rebinding’e karşı bağlantı doğrudan kontrol edilen IP’ye kuruluyor.
• Her redirect’te aynı kontroller tekrarlanıyor.

Yazarlar bunlara ek olarak tarayıcının network egress’ini kısıtlamayı öneriyor, cloud metadata endpoint’leri dahil. Kendi probe’unuzu yazacaksanız bu kontrolleri ilk commit’te koyun, sonraya bırakılınca tarayıcı iç ağa açılan bir proxy’ye dönüşür.

Kendi ortamınızda nereden başlanır?

Yazının önerdiği sıra mantıklı: envanter ana referans, config analizi CI’da erken sinyal, probe ise yalnızca envanter erişim kontrolünün çalıştığını gösteremediğinde. Trend Micro’nun Cloud Run kuralı gibi rule-based kontroller ucuz ve CI’a kolay giriyor ama niyeti raporluyor. Cartography envanterden başlıyor, fakat exposed_internet flag’ini yine config’den türettiği için dışarıdan görüneni doğrulayamıyor.

Pratik bir başlangıç sırası:

1. Tüm projelerde Cloud Run IAM politikalarında allUsers araması.
2. Envanterden tüm ingress ve load balancer listesini çıkarıp sahiplik eşleştirmesi.
3. Ancak bundan sonra, SSRF korumaları ve egress kısıtıyla anonim probe.

Shopify Overexposed aracını AI coding agent’larla ve AI code review ile yazmış. Yanlış şeyi test edip geçen testleri yakalamak için güvenlik kontrollerine mutation testing uyguluyor ve her karar için bir canary hedef tutuyor. Yapay zekâ ile güvenlik aracı yazan ekipler için kopyalanacak ilk pratik bu.