PowerShell Paketlerini Güvenli Yönetmek: PSResourceGet’te Yeni Dönem
Giriş: Paket işi, script işinden daha can alıcı hâle geldi
PowerShell tarafında yıllardır aynı şeyi görüyorum: herkes önce scripti konuşuyor, sonra bir yerde paket kaynağına dönüyor. Kısa cevap şu; otomasyon büyüdükçe asıl risk scriptin içinde değil, o scriptin neyi çektiğinde saklanıyor. Yanı paket deposu biraz binanın su hattı gibi, dışarıdan pek görünmüyor ama kirlenirse bütün yapı etkileniyor.
📋 İçindekiler
-
Küçük startup iseniz her şeyi özel registry’ye taşımanız şart değil; bazen kontrollü cache + sınırlı trust yeterli olur. Ama enterprise seviyedeyseniz “internet açılsın bitsin” yaklaşımı artık pek idare etmiyor. Hem denetim hem uyumluluk hem de olay müdahalesi açısından sizi yoruyor.
Microsoft Artifact Registry neden önemli?
Microsoft’un yayınladığı PowerShell içerikleri için MAR’ın öne çıkması bence doğru yönde atılmış adım.
Peki neden?Bak şimdi, Cevap basit aslında: first-party içeriğin nereden geldiğini tartışmak istemiyorsunuz; mümkünse belirsizlik sıfırlansın istiyorsunuz. Kurumsal müşteriyle çalışırken en çok zaman yediğimiz konulardan biri buydu zaten: “Bu modül gerçekten Microsoft’tan mı geldi?” sorusu gereksiz yere toplantı uzatıyordu.
Bunu 2025’in Şubat ayında İstanbul’daki bir bankacılık projesinde birebir gördük.
Evet.
Güvenlik ekibi PowerShellGallery’den gelen bazı modüller için ekstra inceleme istiyordu — haklılardı da — fakat operasyon ekibi her seferinde manuel doğrulama yapınca iş akışı yavaşlıyordu.
MAR mantığı burada güzel oturuyor çünkü sahiplik ve yayın hattı daha netleşiyor.Kurumsal dünyada güvenliği artırmanın yolu çoğu zaman daha fazla engel koymak değil; doğru kaynağı baştan seçip sonradan tartışmayı azaltmaktır.
Peki PowerShell Gallery bitti mi?
Hayır tabiî ki bitmedi ve bitmemeli de! Gallery hâlâ keşif ve topluluk katkısı için çok değerli bir yer.
Bunu markete benzetiyorum:
sizin ihtiyaç olan malzemenin nerede olduğunu görmeniz lazım ama eve getireceğiniz ürünü yine sız seçiyorsunuz.Şunu söyleyeyim, Buradaki denge önemli.
Eğer her şeyi tamamen kapatırsanız inovasyonu boğarsınız.
Ama hiç filtre koymazsanız prod ortamını açık büfe yapmış olursunuz.
İkisi de kötü.
Benim görüşüm net:
topluluk deposu keşif içindir,
kurumsal üretim işe onaylı kaynak ister.
Bu kadar basit aslında… ama uygulaması kolay değil.OCI desteğiyle oyun alanı genişliyor mu?
E tabi burada OCI desteği işin rengini değiştiriyor çünkü mevcut container altyapınızı reuse edebiliyorsunuz. Kimlik yönetimi zaten hazırsa yeniden tekerlek icat etmiyorsunuz; RBAC var mı? Var! Audit log var mı? Var! Ağ politikası var mı? Çoğunlukla var! Bu yüzden PowerShell paketlerini container registry mantığıyla taşımak bana oldukça mantıklı geliyor.
Bazı ekiplerde şöyle itiraz geliyor: “Ama biz modülü niye container registry’ye koyuyoruz ki?” Cevap şu olabilir — çünkü platform standardizasyonu sağlıyor sunuzdur (burada kasıt bilinçli). Yanı Docker image ile PowerShell package arasında kavramsal köprü kuruyorsunuz; farklı artefakt türleri olsa da yönetim dili ortaklaşıyor.
# Örnek düşünce modeli # 1) Keşif repo'su # 2) Onaylanan içerik mirror'a alınır # 3) Üretimde yalnızca mirror kullanılır Set-PSResourceRepository -Name "InternalApproved" -Trusted -Uri "https://registry.example.local/powershell" Install-PSResource -Name Az.Accounts -Repository InternalApprovedAma eksik kalan yerler de var
Bence henüz en zayıf halka birlikte çalışma senaryolarının kolaylığı.
Yanı teknoloji güzel,
ama süreç tasarımı kullanıcı dostu olmak zorunda.Kural koymak kolay;
kuralın sürdürülebilir olması zor.
Ben bazı projelerde tam burada takıldığını gördüm.
Mesela Şubat 2026’da İzmir’deki orta ölçekli bir üretim firmasına yaptığımız değerlendirmede teknik çözüm tamam gibiydi fakat operasyon ekibi günlük kullanımda fazla adım yüzünden geri çekildi.
Demek ki adoption kısmını hafife almamak gerekiyor…Sahada benim önerdiğim yol haritası
Şöyle ki, Lafı gevelemeden söyleyeyim:
düşünmeden önce tüm repository’leri sayın.
Peki sonra?
Zaten asıl iş orada başlıyor (en azından benim deneyimim böyle)- Paket tüketen sunucuları listeleyin. (bu kritik)
- Hangi repo’nun trusted olduğunu yazılı hâle getirin.
- Tedarik zinciri onay süreci belirleyin.
- Mümkünse private registry’ye mirror kurun. (bu kritik)
- Tüm değişiklikleri loglayın ve periyodik gözden geçirin. — bunu es geçmeyin
💡 Bilgi: Eğer bütçeniz kısıtlıysa önce tüm sistemi taşımaya kalkmayın; en hayatı modüllerden başlayıp sadece onları onaylı depoya alın.Küçük ekip vs enterprise farkı
}Küçük ekiplerde hız önemli.
Neyse uzatmayalım;
bazen üç kişilik grupta bile gereksiz approval zinciri işleri bozuyor.
Aynı zamanda uzun cümlelerle kafayı şişirmeye gerek yok,
bazen hafif trust modeli + basit kayıt tutma çoğu zaman yeterli,
bazen de yetmez — işte orada tekrar bakarsınız.
Enterprise tarafta işe durum değişir:
rol ayrımı,
audit,
change management,
hatta incident response bile işin içine girer.
Aynı teknoloji iki yerde bambaşka davranır yanı…
bu yüzden reçete tek değildir.
Ben buna hep “aynı anahtar her kapıyı açmaz” derim.”>Sıkça Sorulan Sorular
Zaten PowerShell Gallery varken PSResourceGet’e neden ihtiyaç duyuyoruz ki?
Aslında cevap oldukça basit: Gallery içerik bulmak için harika, yanı modül keşfi konusunda gerçekten iyi iş çıkarıyor. Ama kurumsal güven modeli kurmak için tek başına yeterli gelmiyor. PSResourceGet size repository trust, kaynak ayırma ve çok daha kontrollü bir tüketim modeli sunuyor. Bence özellikle kurumsal ortamlarda bu farkı er ya da geç hissediyorsunuz.
MARC kullanmak zorunlu mu?
Şöyle ki, Hayır, zorunlu değil! Ama açıkçası Microsoft yayınlı içerikte MAR ciddi avantaj sağlıyor; hani sahiplik çok daha net oluyor ve kurumsal karar vermek kolaylaşıyor (evet, doğru duydunuz). Tecrübeme göre önü atlamak çoğu zaman ilerleyen süreçte baş ağrısına dönüşüyor.
OCI registries her durumda uygun mu?
Şunu söyleyeyim, Her durumda değil tabiî. Mesela ekibiniz container registry operasyonuna zaten alışıksa çok mantıklı bir seçim. Değilse önce basit bir dahili mirror ile başlamak çok daha rahat olabilir. Yanı altyapı olgunluğuna göre karar vermek lazım (ki bu çoğu kişinin gözünden kaçıyor)
Kötü yapılandırılmış repo ne tür risk çıkarır?
Yanlış sürüm çekme, beklenmeyen davranışlar, gölge dependency’ler ve denetimde açıklanamayan trafik çıkarabiliyor. Kısacası masum görünen küçük hatalar büyük prod sorunlarına dönebiliyor. Bence bu konu hafife alınan ama aslında en kritik noktalardan biri.
Kaynaklar ve İleri Okuma
Şahsen, PowerShell Blog Ana Sayfa
Aslında, PSResourceGet Resmî Dokümantasyonu
Azure Container Registry Resmî Dokümantasyonu
Şahsen, NuGet Paket Budaması Daha Temiz.NET Bağımlılıkları
Eh, Azure DevOps Server Mayıs Yamaları Neyi Neden Nasıl Kontrol Etmeli? (bizzat test ettim)
Bu yazı yapay zeka (büyük dil modelleri) ile hazırlanmış, insan editör tarafından incelenmiştir. İçerik üretim sürecimiz.Aşkın KILIÇYazar20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
AZ-305AZ-104AZ-500AZ-400DP-203AI-102İlgili Yazılar
İlginizi Çekebilir
Burak S.
PSResourceGet’in güven mekanizması gerçekten kritik bir eksikliği kapatıyor, özellikle kurumsal ortamlarda hangi repository’nin onaylı olduğunu merkezi yönetmek büyük fark yaratıyor. Bu arada şu yazınız da güzeldi: Azure IaaS’te Savunma Katmanları: Güvenlik Nasıl Oturuyor? — https://www.askinkilic.com.tr/azure-iaaste-savunma-katmanlari-guvenlik-nasil-oturuyor/ İkisi birlikte okunca güvenlik katmanları daha net oturuyor zihinде.
Deniz R.
PSResourceGet’i duymuştum ama güven ve onay akışı kısmını bu kadar detaylı düşünmemiştim açıkçası. Özellikle kurumsal ortamlarda hangi repository’e güvenip güvenmeyeceğini yönetmek gerçekten kritik bir konu. Repository keşfini pratikte nasıl kısıtlayabildiğimize dair bir örnek görsek çok işe yarardı.
Koray M.
PSResourceGet ile repository güven mekanizmasını henüz test etmedim ama özellikle kurumsal ortamlarda onay akışı kısmı can kurtarır gibi görünüyor. Acaba mevcut PowerShellGet scriptlerini PSResourceGet’e geçirmek ne kadar sancılı oluyor, bunu da ele alsanız?
Ahmet Y.
PSResourceGet’e geçiş zorunlu mu yoksa eski PowerShellGet ile devam edilebilir mi? Kurumsal ortamlarda paket kaynaklarını kilitleyebilmek gerçekten kritik bir özellik, özellikle supply chain saldırıları bu kadar artmışken.
Yorumlar kapalı.
4 comments