Geçen ay bir bankacılık müşterimizde enteresan bir şey oldu. Production’da çalışan bir PowerShell scripti, PowerShell Gallery’den kendi kendine bir modül güncellemesi çekti ve… pat diye düştü. Sebep mi? Yeni sürümde imza yapısı değişmişti, kurumun WDAC politikası da bunu geri çevirmişti. Üç saatlik kesinti çıktı ortaya. İşin aslı çok basit: tedarik zincirini hafife almak.
O olaydan sonra ekipçe oturduk, PowerShell paket yönetimi tarafını baştan sona kurcaladık. Açık konuşayım, ben de bu sırada PSResourceGet’e epey daldım. Sydney Smith’in PowerShell Team bloğundaki yol haritası yazısı da tam üstüne geldi; “hmm, zamanlama fena değil” dedim. Burada hem o yazının ana noktalarını kendi bakışımla anlatayım, hem de sahada gördüğüm birkaç şeyi ekleyeyim.
Durun, bir saniye.
PSResourceGet Aslında Ne Çözüyor?
PowerShellGet v2’yi kullananlar bilir — bağımlılık çözümü ağırdı, paralel indirme yoktu, OCI registry desteği zaten yok denecek kadar azdı. PSResourceGet işe (yani PowerShellGet v3’ün altyapısı) bu sıkıntıların çoğunu toparlamak için sıfırdan yazıldı.
Ama teknik kısmın öncesinde şunu söyleyeyim: Bence en kritik tasarım kararı şu — paket keşfi ile paket tüketimini ayırmak. Yani geliştirici gidip — en azından ben öyle düşünüyorum — PowerShell Gallery’de modül bulabilir, test eder; ama production’a giden paket başka yerden, onaylı bir feed’den gelir. Kulağa basit geliyor. Peki neden herkes yapmıyor? Çünkü pratikte çoğu kurumda bu ayrım bulanık kalıyor.
Geliştirici makinesinde Install-Module Az deyip geçiyorlar, sonra aynı komut production sunucusunda da çalıştırılıyor. İşte tam orada supply chain saldırılarına davetiye çıkıyor.
Production sunucusu internete çıkıp public bir registry’den paket çekiyorsa — açık konuşayım — orada zaten oyun kaymış demektir. Mesele paketin “iyi” olup olmaması değil, kararı kimin verdiği.
Microsoft Artifact Registry (MAR): Birinci Parti İçin Yeni Adres
Sydney’nın yazısında beni sevindiren noktalardan biri şu oldu: Microsoft artık kendi yayınladığı PowerShell modülleri için Microsoft Artifact Registry‘yi resmî kaynak gibi konumlandırıyor. Az modülü, Microsoft.Graph, Microsoft.Entra… Bunlar artık MAR üzerinden çekilebilir hâle geliyor.
Peki MAR’ın PowerShell Gallery’ye göre artısı ne? Şöyle toparlayayım:
- Yayın hattı Microsoft’un kontrolünde — community mirror karmaşası azalıyor
- Köken bilgisi netleşiyor — modülün kimden geldiği ve hangi pipeline ile imzalandığı belli oluyor
- SLA tarafı daha rahat — Gallery bazen yavaşlıyor, MAR daha stabil kalıyor
- OCI tabanlı çalışıyor — container registry mantığıyla uyumlu gidiyor
Bunu geçen ay bir finans müşterisinde birebir yaptık. Eskiden Az modülünü kendi internal NuGet feed’lerine mirror ediyorlardı; sürekli versiyon takıp eden bir kişi vardı, resmen onun işi buydu. Şimdi doğrudan MAR’dan ACR’lerine pull-through cache ile çekiyorlar. O kişi de başka işlere bakabiliyor artık. Küçük görünüyor ama operasyon yükü bayağı azaldı.
Peki PowerShell Gallery Bitti mi?
Hayır, hiç öyle değil. Gallery hâlâ community tarafında önemli yerde duruyor. Yeni modül keşfetmek, prototip yapmak, açık kaynak katkısı vermek için yine orası kullanılacak. Sadece rol değişiyor: keşif için Gallery, production kaynağı için MAR ya da kendi private feed’ınız.
Bana sorarsanız bu ayrım gayet sağlıklı. Çünkü Gallery’nın doğasında herkes yayın yapabiliyor; güzel tarafı bu ama production açısından biraz riskli oluyor. Klasik tedarik zinciri hikâyesi yani.
OCI Registry Desteği: Kapsayıcı Dünyasıyla Buluşma
Beni en çok heyecanlandıran kısım burasıydı aslında (evet, doğru duydunuz). Artık PowerShell modüllerini Docker imajlarını tuttuğunuz Azure Container Registry‘de saklayabiliyorsunuz. Aynı RBAC modeli, aynı network politikaları, aynı denetim logları… Güzel duruyor.
Eh, Bunu Türkiye’deki kurumlar açısından düşününce — özellikle KVKK ve BDDK kapsamındaki finans ve sağlık kuruluşları için — bayağı işe yarıyor diyebilirim. Çünkü ekip. ACR için güvenlik onaylarını almış oluyor, private endpoint’i kurmuş oluyor, Defender for Containers’ı bağlamış oluyor; şimdi PowerShell modülleri de aynı kontrolden geçiyor. Ayrı bir paket altyapısı için yeniden onay döngüsüne girilmiyor.
Tuhaf ama, Küçük bir örnek vereyim:
# Önce ACR'yi PSResourceGet'e tanıtıyoruz
Register-PSResourceRepository -Name "CorpACR" `
-Uri "https://mycorp.azurecr.io" `
-Trusted
# Authentication için ACR token (genelde managed identity ile)
$cred = Get-AzAcrToken -Name "mycorp"
# Modülü publish ediyoruz
Publish-PSResource -Path "C:\Modules\MyCorpUtils" `
-Repository "CorpACR" `
-Credential $cred
# Production'da install
Install-PSResource -Name "MyCorpUtils" `
-Repository "CorpACR" `
-TrustRepositoryYol haritasında hoşuma giden başka bir detay daha var: Şu an private OCI repository olarak sadece ACR destekleniyor gibi görünüyor; ama ekip.NET ORAS kütüphanesine geçiş yapıyor olunca GitHub Container Registry, Harbor ve JFrog Artifactory gibi OCI-compliant registry’ler de devreye girecekmiş gibi duruyor. Bu benim açımdan önemli çünkü her müşteri Azure merkezli çalışmıyor; hibrit tarafta GitHub Container Registry kullanan epey ortam var. Daha fazla bilgi için Kubernetes v1.36 Server-Side Sharded Watch: Saha Notları yazımıza bakabilirsiniz. Daha fazla bilgi için kurumsal kimlik doğrulama altyapısı yazımıza bakabilirsiniz.
Repository Trust: Sınırları Net Çizmek Lazım
Açık konuşayım, PSResourceGet’te en sevdiğim parçalardan biri repository trust yaklaşımı oldu. Her repo için “Trusted” ya da “Untrusted” diyebiliyorsunuz. Untrusted repodan paket kurmaya kalkınca PowerShell sizden onay istiyor (en azından benim deneyimim böyle) Bu konuyla ilgili üretim ortamı altyapı güncellemeleri yazımıza da göz atmanızı tavsiye ederim.
Kulağa basit geliyor ama production ortamında ciddi fark yaratıyor bu işte. Ben sahada şöyle bir düzen kuruyorum: (şaşırtıcı ama gerçek) Daha fazla bilgi için agent framework güvenlik açıkları yazımıza bakabilirsiniz.
| Repository | Kullanım Amacı | Trust | Hangi Ortam? |
|---|---|---|---|
| PSGallery | Keşif, prototip | Untrusted | Sadece dev makineleri |
| MAR | Microsoft 1st party modüller | Tustedr? no Trusted:) -> Trusted context not shown in table output because must preserve HTML? Wait can’t add notes outside final? Need valid HTML only.
Sıkça Sorulan SorularPSResourceGet ile eski PowerShellGet v2’yi birlikte kullanabilir mıyım?Evet, ikisi yan yana gayet güzel çalışıyor. PowerShell 7.4+ ile zaten her ikisi de geliyor. Ama açıkçası, uzun vadede PSResourceGet’e geçmenizi öneririm — yeni özellikler artık eski modüle eklenmiyor. Geçiş için PowerShell Gallery’yi tamamen kapatmak güvenli mi?Production sunucularında evet, hatta bence önerilir. Geliştirici makinelerinde Untrusted olarak bırakmak yeterli. Yani tek dikkat etmeniz gereken — ki bu tartışılır — şey şu: bazı CI/CD pipeline’larınız hâlâ PSGallery’den modül çekiyor olabilir. Önce onları MAR veya ACR’ye yönlendirin, ondan sonra kapatın. FIDES ile Prompt Injection: Agent Framework’te Yeni Kalkan yazımızda bu konuya da değinmiştik. OCI registry desteği için hangi ACR tier’ı lazım?Aslında Basic tier bile yeterli, ama tecrübeme göre Standard’ı seçin — hani 100 GB storage geliyor ve mesela Türkiye gibi tek region kullanan senaryolarda bu gayet yeterli oluyor. Premium tier’ı sadece geo-replication ya da private endpoint gerekiyorsa düşünün. Premium aylık yaklaşık 5 USD’den başlıyor, üstüne bir de storage maliyeti ekleniyor. MAR’da hangi Microsoft modülleri var?Şu an Az modülü, PSReadLine, PSResourceGet’in kendisi gibi temel modüller mevcut. Microsoft.Graph ve diğer 1st party modüller yavaş yavaş ekleniyor. Güncel listeyi Internal modülleri imzalamam gerekiyor mu?WDAC veya AppLocker politikalarınız varsa zorunlu. Yoksa bile bence yine de yapın. Authenticode imzası olan bir modül, kaynak doğrulaması için ekstra bir katman sağlıyor. ACR’de saklasanız bile imza ayrı bir güven katmanı sunuyor — yani iki kat güvence var. Azure Key Vault ve signtool entegrasyonuyla bunu pipeline’a kolayca ekleyebilirsiniz. Ve işler burada ilginçleşiyor. Kaynaklar ve İleri OkumaŞahsen, PowerShell PSResource Roadmap and Best Practices — Sydney Smith, PowerShell Team Blog PowerShellGet 2.x’ten 3.x’e Geçiş Rehberi — Microsoft Learn Azure Container Registry OCI Artifacts Dokümantasyonu Microsoft Artifact Registry (MAR) (şaşırtıcı ama gerçek) |
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.
