npm Trusted Publishing ile dist-tag Yönetimi Token’sız
Trusted publishing yapılandırmalarına artık dist-tag yönetimi izni verilebiliyor. Yani bir sürümü latest‘a terfi ettirmek ya da next ve beta işaretçilerini güncellemek için kısa ömürlü OIDC kimlik bilgileri yetiyor. Değişiklik, npm paketlerini GitHub Actions üzerinden yayınlarken uzun ömürlü erişim token’larından kurtulmak isteyen bakımcıları ilgilendiriyor. İzin varsayılan olarak kapalı geliyor, devreye almak isteyen her yapılandırmada ayrıca seçilmesi gerekiyor.
Daha önce ne eksikti?
npm için trusted publishing yayınlama (publishing) ve staging işlemlerini kapsıyordu. Bu iki adım OIDC ile token’siz yürütülebiliyordu, dist-tag işlemleri ise kapsamın dışındaydı.
Dolayısıyla iş akışlarını tamamen token’siz hale getirmiş bakımcılar bile yalnızca etiket yönetimi için bir granular access token saklamak zorunda kalıyordu. Bu token yalnızca sürüm sonrası etiketlemede ya da bir geri alma (rollback) sırasında latest işaretçisini eski bir sürüme çevirmek için kullanılsa da, deponun veya CI ortamının bir yerinde uzun ömürlü bir sır olarak durmaya devam ediyordu.
Tedarik zinciri güvenliği açısından sorunun özeti şuydu. Yayınlama akışının yüzde doksanı kısa ömürlü kimlik bilgileriyle çalışırken, geriye kalan küçük bir işlem yüzünden ortamda kalıcı bir yayın yetkisi tutuluyordu. Böyle bir token sızdığında saldırgan latest işaretçisini kontrol eder, yani kurulum yapan kullanıcıların varsayılan olarak hangi sürümü çektiğini belirler.
Yeni izin nasıl çalışıyor?
Her trusted publishing yapılandırmasında artık Allow npm dist-tag adında, isteğe bağlı (opt-in) bir izin var. Davranışının önemli ayrıntıları şunlar:
- İzin hem yeni oluşturulan hem de mevcut yapılandırmalarda kapalı geliyor. Hiçbir yapılandırma otomatik olarak yeni bir yetki kazanmıyor, yükseltme sonrası sessizce genişleyen bir yetki alanı yok.
- İzin publish yetkisine bağlı değil. Yalnızca staging için kullanılan bir yapılandırmaya da dist-tag yönetimi izni verilebiliyor, bu da yayınlama ile etiketleme sorumluluklarını farklı iş akışlarına ayırmak isteyen ekiplere esneklik sağlıyor.
- Gelen OIDC token’ı, izni etkin olan herhangi bir yapılandırmayla eşleşiyorsa dist-tag işlemi yetkilendiriliyor. Birden fazla yapılandırma tanımlıysa etiket yönetimi için tek bir eşleşme yetiyor.
- Token ile yapılan dist-tag yönetimi hiçbir değişiklik olmadan çalışmaya devam ediyor. Geçişi hemen yapmak zorunda değilsiniz.
Devreye alma adımı
Kullanmak için paketinizin trusted publishing ayarlarını açıp etiket yönetimi yapabilmesi gereken yapılandırmalarda Allow npm dist-tag seçeneğini etkinleştirmek yeterli. Kaynakta bunun dışında ek bir yapılandırma adımı veya komut belirtilmiyor, iş akışı dosyalarınızda zorunlu bir değişiklik gerektiğine dair bir bilgi de geçmiyor.
Pratikte neyi değiştiriyor?
En somut kazanım, yayın sürecinde saklanan uzun ömürlü sır sayısının azalması. Etiketleme için ayrı bir granular access token tutma gerekçesi ortadan kalktığında:
- Rotasyon yükü düşer, süresi dolan ya da sahibi ekipten ayrılan token’ların takibi gereksizleşir.
- Sızıntı yüzeyi daralır. CI log’ları, fork’lanan depolar veya yanlış yapılandırılmış secret’lar üzerinden kaçabilecek kalıcı bir yayın yetkisi kalmaz.
- Yetkiler paket ve iş akışı düzeyinde daha net ifade edilir, hangi yapılandırmanın etiket değiştirebileceği ayarlar ekranında açıkça görülür.
İznin varsayılan olarak kapalı olması da bilinçli bir tercih gibi görünüyor. Etiket yönetimi, bir paketin kullanıcılarına ulaşan varsayılan sürümü belirlediği için düşük riskli bir işlem değil. İzni yalnızca gerçekten ihtiyaç duyan yapılandırmalarda açmak, en az ayrıcalık ilkesiyle uyumlu bir yaklaşım olur. Yayınlama ve etiketleme farklı iş akışlarına bölünmüşse izni yalnızca etiketlemeden sorumlu yapılandırmada etkinleştirmek mantıklı.
Dikkat edilmesi gereken noktalar
Eşleşme kuralının “herhangi bir yapılandırma” üzerinden çalıştığını unutmayın. Birden çok trusted publishing yapılandırması tanımlı bir pakette, izni açtığınız her yapılandırma dist-tag işlemleri için geçerli bir yetki kaynağı haline gelir. İzni toplu şekilde açmak yerine hangi iş akışının etiketleme yapması gerektiğini belirleyip yalnızca onu işaretlemek daha güvenli.
Mevcut token tabanlı akışınız bozulmayacağı için geçişi kademeli planlayabilirsiniz. Önce izni etkinleştirip OIDC üzerinden etiketlemeyi doğrulayın, beklendiği gibi çalıştığını gördükten sonra yalnızca bu iş için tutulan token’ı iptal edin. Kaynakta token iptali için zorunlu bir takvim ya da kullanımdan kaldırma duyurusu yer almıyor.
Kaynaklar ve İleri Okuma
- Opt-in dist-tag permissions for npm trusted publishing — GitHub Changelog
- npm Docs: Trusted publishers
- GitHub Community: Roadmap tartışması
- npm için birden fazla trusted publishing yapılandırması
- npm ve GitHub Actions üzerindeki tedarik zinciri saldırıları
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.
Yorum gönder