Argo CD 3.5 dahili mTLS, Git commit doğrulaması ve bir ApplicationSet arayüzü getiriyor

Argo CD 3.5 güvenlik odaklı geliyor

Kubernetes cluster'larının neredeyse yüzde 60'ında kullanıldığı bir dev.to genel bakışında belirtilen GitOps controller'ı Argo CD, Ağustos 2026'da 3.5 sürümünü yayınladı. dev.to'ya göre bu sürüm, iki köklü güvenlik açığını kapatıyor — kimlik doğrulaması olmayan dahili trafik ve bir branch üzerinde bulunan her şeye körü körüne güvenme — ve bunlara ApplicationSet'ler için yerel bir arayüz ekliyor. Sürüm 3.6 için bir release candidate Eylül 2026'da geldi; makale bunu geliştirme hızının arttığının bir işareti olarak yorumluyor.

Dahili mTLS bileşen trafiğini şifreliyor

Şimdiye kadar repo-server ile control plane'in geri kalanı — API server, Application Controller ve ApplicationSet Controller — arasındaki iletişim şifreleme veya kimlik doğrulaması olmadan yürüyordu. dev.to'nun aktardığına göre bu, Temmuz 2026'da somut bir soruna dönüştü: yayınlanan bir exploit, kimliği doğrulanmamış bir saldırganın repo-server'a erişebildiğini, bir Kustomize seçeneğini istismar ederek keyfi komutlar çalıştırabildiğini, bir ortam değişkeninden Redis şifresini okuyabildiğini ve önbelleğe alınmış deployment verilerini manipüle edebildiğini gösterdi. Makale, altta yatan hatanın ifşa edilmeden 18 ay önce maintainer'lara bildirildiğini belirtiyor.

Sürüm 3.5 ile birlikte repo-server, bağlanan her bileşenden geçerli bir client certificate talep ediyor. Operator'lar kendi sertifikalarını verebiliyor; vermezlerse repo-server bellekte self-signed sertifikalar üretiyor, böylece filesystem erişimi gerekmiyor. Bu özellik eklemeli nitelikte; yani mevcut kurulumlar yeniden yapılandırma olmadan otomatik sertifikalara geri düşüyor. dev.to, mTLS'nin NetworkPolicy'lerin yerini almadığını, bunları ikinci bir savunma katmanı olarak tamamladığını vurguluyor; bu da ağ izolasyonunun eksik olduğu veya saldırganın zaten aynı namespace'e yatay geçiş yaptığı durumları kapsıyor.

İmzalı commit'ler deployment kapısı olarak

Source Integrity adındaki ikinci ana özellik, senkronizasyon öncesinde Git commit imzalarını doğruluyor. Daha önce Argo CD, yapılandırılmış branch üzerinde bulunan her commit'i, kimin gönderdiğine veya sonradan değiştirilip değiştirilmediğine bakılmaksızın deploy edilebilir kabul ediyordu. Operator'lar artık bir Application spec içinde sourceIntegrity.required: true ayarlayabiliyor veya argocd app set --source-integrity-required CLI bayrağını kullanabiliyor; geçerli imzası olmayan commit'ler senkronizasyona dahil edilmiyor.

dev.to'ya göre bu, sızan bir GitHub personal access token'ı, ele geçirilmiş bir geliştirici dizüstü bilgisayarı veya bir olay sırasında yapılan force push gibi gerçekçi hata senaryolarını hedefliyor — bunlar, commit'in branch üzerinde meşru göründüğü durumlar. Özellik, deployment kararını tek bir soru etrafında yeniden çerçevelendiriyor: bu spesifik commit, production değişikliklerini onaylamaya yetkili bir anahtarla imzalanmış mı? Eski GPG doğrulama yolu artık deprecated ve bir sonraki ana sürümde kaldırılacak.

ApplicationSet'ler için yerel bir arayüz

ApplicationSet'ler, ekiplerin aynı uygulamayı birden fazla cluster veya ortamda şablonlamasını sağlıyor; ancak bunlar daha önce web arayüzünde hiçbir temsile sahip değildi; yöneticiler, bir şablonun hangi somut uygulamaları üreteceğini görmek için YAML okumak veya kubectl kullanmak zorundaydı. Sürüm 3.5, dev.to'ya göre Intuit, Red Hat, GoTo ve Octopus Deploy mühendislerinin katkılarıyla oluşturulan bir ApplicationSet arayüzü getiriyor; liste görünümü, filtreleme ve detay görünümlerinin yanı sıra, bir şablonun herhangi bir şey deploy edilmeden önce hangi uygulamaları üreteceğini gösteren bir Preview Apps sekmesi sunuyor. Önizleme özellikle, daha fazla cluster'a ölçeklenirken yanlış yapılandırma riskini azaltıyor.

Bu sürümdeki diğer değişiklikler

Sürüm ayrıca daha küçük bir dizi öğe de içeriyor: Argo CD'nin sunucu tarafı görevler için belirli bir kullanıcı kimliği üstlenmesini sağlayan ve multi-tenant cluster'larda audit trail'leri iyileştiren beta durumundaki impersonation; dry kaynak şablonlarını farklı repository'lerdeki render edilmiş manifest'lardan ayıran ve beta aşamasına ulaşan Source Hydrator; Helm 3 uyumluluğuyla birlikte Helm 4 desteği; ApplicationSet'leri yalnızca Argo CD namespace'inde değil herhangi bir namespace'te deploy edebilme; aynı anda işlenen uygulama sayısını sınırlayarak cluster aşırı yüklenmesine karşı koruyan eşzamanlılık kontrolleri; ve Microsoft Graph API üzerinden group-claims taşması ile Azure DevOps için service principal kimlik doğrulamasını kapsayan Azure Active Directory iyileştirmeleri.

Neden önemli

Argo CD'nin Kubernetes ekosistemindeki konumu göz önüne alındığında, dahili güven modelindeki zayıflıklar yerel değil sistemseldir; Temmuz 2026 exploit'i de bir saldırganın komut çalıştırma ve veri manipülasyonuna ulaşmak için ne kadar az şeye ihtiyaç duyduğunu gösterdi. Dahili mTLS, bu çıtayı minimal geçiş çabasıyla yükseltiyor; commit imzalama ise GitOps'un temel vaadini — production'ın tam olarak onaylanan şeyi yansıttığını — branch durumundan kriptografik kimliğe genişletiyor. Her iki özellik de uygulama başına veya bileşen bileşen kademeli olarak benimsenebiliyor, bu da çalışan bir pipeline'ı sıkılaştırmanın maliyetini düşürüyor. Yeni ApplicationSet arayüzü ise, çok cluster'lı GitOps'u derin YAML uzmanlığı olmayan ekipler için anlaşılır kılıyor; bu da benimseme platform uzmanlarının ötesine yayıldıkça önem taşıyor.