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
- Giriş: Paket işi, script işinden daha can alıcı hâle geldi
- PSResourceGet neden farklı hissettiriyor?
- Güven modeli: Repo sayısını azaltın, rolü netleştirin
- Microsoft Artifact Registry neden önemli?
- OCI desteğiyle oyun alanı genişliyor mu?
- Sahada benim önerdiğim yol haritası
- Sıkça Sorulan Sorular
- Kaynaklar ve İleri Okuma
PSResourceGet tam da bu yüzden önemli. Klasik “indir çalıştır” alışkanlığını biraz kırıyor. Size kaynakları ayırma, güven tanımlama, onay akışı kurma şansı veriyor. Ben bunu ilk kez 2024’te bir finans müşterisinde gündeme getirdiğimde ekip önce “paket deposu için bu kadar uğraşmaya değer mi?” diye sormuştu. İki hafta sonra aynı ekip, üretim sunucusuna yanlış modül gelmesinin nasıl küçük bir olaydan büyük bir operasyona dönebileceğini görünce fikrini değiştirdi.
Bakın şimdi, bu konu sadece PowerShell meraklılarının konusu değil. Azure yöneten ekipler, DevOps takımları, hatta güvenlik tarafı bile bunun içinde. Çünkü supply chain dediğimiz şey artık yalnızca kod bağımlılığı değil; modül bağımlılığı da var, registry bağımlılığı da var, izin modeli de var.
Hmm, bunu nasıl anlatsamdı…
PSResourceGet neden farklı hissettiriyor?
PSResourceGet’in bana göre en iyi tarafı, repository meselesine daha olgun yaklaşması (inanın bana). Eski modelde çoğu ekip tek bir kaynağa yaslanıyordu; oradan bulduğunu alıyor, prod’a koyuyordu. Kağıt üstünde hızlıydı ama pratikte biraz savruk kalıyordu. PSResourceGet işe keşif ile tüketimi birbirinden ayırmaya zorluyor. Bu ayrım küçük gibi dürüyor ama kurumsalda baya fark yaratıyor.
Vallahi, Bir de şu var: sadece PowerShell module değil, script ve DSC resource tarafını da kapsıyor. Yanı tek tek araçlarla uğraşmak yerine ortak bir düzen kurabiliyorsunuz. Geçen yıl Mart ayında Ankara’daki bir kamu kurumunda yaptığımız tasarım oturumunda bunu anlattığımda mimar arkadaşın cümlesi hâlâ aklımda: “Bizim derdimiz modül indirmek değil aslında, kimin neyi indirebildiğini bilmek.” Aynen öyle.
Durun, bir saniye.
Şunu açık söyleyeyim: PSResourceGet kusursuz değil. Bazı enterprise senaryolarda dokümantasyon hâlâ biraz ham hissettiriyor ve özellikle mirroring ile politika tasarımı kısmında herkesin eli rahat etmiyor (buna dikkat edin). Ama yön doğru. Baya doğru.
Güven modeli: Repo sayısını azaltın, rolü netleştirin
Kurumlarda en sık gördüğüm hata şu: beş tane repo açılıyor ama hiçbiri ne işe yaradığı belli olmadan yaşıyor. Bir tanesi test için denmiş oluyor, biri geçici olmuş oluyor, biri de eski ekipten kalmış oluyor… Sonra üretimde sürpriz başlıyor. O yüzden ben genelde küçük ama net bir model öneriyorum: keşif için ayrı kaynaklar, prod için ayrı kaynaklar.
Açık konuşayım; repository trust konusu bazen fazla basit anlatılıyor (ki bu çoğu kişinin gözünden kaçıyor). Sanki sadece “trusted = yes” demek yetiyormuş gibi davranılıyor ama yetmiyor tabiî. Trust ayarı tek başına güvenlik değildir; yalnızca kapının koludur. Asıl mesele kapının arkasındaki süreçtir: onay mekanizması var mı, imza kontrolü var mı, paket nereden geldiği izlenebiliyor mu?
2019’da kendi lab ortamımda benzer bir düzeni NuGet tarafında test ederken küçük bir ayrıntıyı kaçırmıştım (yanlış duymadınız). Yanlış feed önceliği yüzünden beklemediğim paket sürümü çekilmişti. Hata mesajı çok süslü değildi; hatta dürüst olayım biraz sınır bozucuydu çünkü sistem çalışıyormuş gibi görünüyordu ama yanlış şeyi çalıştırıyordu (ciddiyim). İşte tam o an anladım ki depo yönetimi biraz mutfak düzeni gibi — etiket yoksa güzel görünen dolap bile baş belası olur (ilk duyduğumda inanamadım)
Hmm, bunu nasıl anlatsamdı…
| Kullanım Alanı | Önerilen Repo Tipi | Neden? |
|---|---|---|
| Keşif / Deneme | PowerShell Gallery veya kontrollü mirror | Ekiplerin yeni modülleri görmesi için |
| Microsoft yayınlı içerik | MARC / Microsoft Artifact Registry | Daha net sahiplik ve provenance için |
| Üretim dağıtımı | Dahili onaylı repo veya OCI registry | Tutarlı politika ve erişim kontrolü için |
| Kritik altyapı | Kısıtlı private registry + approval gate | Saldırı yüzeyini azaltmak için |
Maliyet tarafını da boş geçmeyelim
Bunu Türkiye’deki şirketler açısından değerlendirirsek mesele sadece teknik güvenlik olmuyor; maliyet de devreye giriyor tabiî ki. Mesela TL bazında bütçe düşünen kurumlarda dış repo trafiği ufak ufak büyüyüp görünmez gider yaratabiliyor. ACR ya da başka özel registry kullanınca ağ çıkışı, depolama. Operasyon maliyeti konuşuluyor ama karşılığında kontrol kazanıyorsunuz. NuGet Paketlerini C++ Projelerinde Düzenlemek: PackageReference Dönemi yazımızda bu konuya da değinmiştik.
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. Bu konuyla ilgili Azure SDK for Rust GA: Beta’dan Stabil Üretime Geçiş yazımıza da göz atmanızı tavsiye ederim.
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. Bu konuyla ilgili Gemini 3.5 Flash Copilot’ta: Hız, Maliyet ve Gerçek Etki yazımıza da göz atmanızı tavsiye ederim.
# Ö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 InternalApproved
Ama 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… Daha fazla bilgi için Prompt Injection’ı Durdurmak: Agent Framework’te FIDES yazımıza bakabilirsiniz. Daha fazla bilgi için Kubernetes v1.36: CCM Route Sync Metriği Neyi Ele Veriyor? yazımıza bakabilirsiniz.
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
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)
20+ 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.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
4 comments