Staging ortamında test ettiğiniz container ile production’da çalışan container gerçekten aynı mı? İkisinin de aynı etiketi taşıması bu soruyu yanıtlamaz. Bir image tag’i yeniden kullanılabilir; bugün çekilen içerik yarın aynı adla farklı olabilir. Küçük SaaS ekiplerinde bu belirsizlik, “test geçti ama canlıda bozuldu” olaylarının fark edilmesi zor nedenlerinden biridir.

Container image digest kullanmak, yayınlanan içeriğin kimliğini sabitlemenin temel yoludur. Ancak digest tek başına güvenlik sertifikası değildir. Bu yazıda bir kez üretilen artifact’ın ortamlarda değiştirilmeden ilerlemesini, içerik kimliği ile kaynağa güven arasındaki farkı ve geri alma için registry saklama politikasını ele alıyoruz. Amaç yeni araç yığmak değil, mevcut CI/CD hattında doğrulanabilir bir yayın zinciri kurmaktır.

Container image digest neden tag’den farklıdır?

Tag, image’a ulaşmak için kullanılan değişebilir bir referanstır. “latest” gibi genel adlar kadar sürüm gibi görünen özel etiketler de registry izinleri ve politikaları uygunsa başka içeriğe taşınabilir. Digest ise içeriğin kriptografik kimliğidir. Beklenen digest’i kullanmak, farklı bir içerik çekildiğinde bunun aynı yayınmış gibi sessizce kabul edilmesini önlemeye yardımcı olur.

Yine de güvenilir digest’in hangi kanaldan geldiği önemlidir. Saldırgan yayın tanımını veya CI ayarını değiştirebiliyorsa referansı da kendi artifact’ına çevirebilir. Bu nedenle digest sabitlemeyi erişim kontrolü, değişiklik onayı ve üretim zinciri doğrulamasıyla birlikte düşünün. “Digest var, dolayısıyla image güvenlidir” sonucu teknik olarak doğru değildir; zararlı veya açık içeren içerik de sabit bir digest taşıyabilir.

Build bir kez, staging ve production’a aynı artifact

Yaygın hata, aynı kaynak kodundan her ortam için yeniden image üretmektir. Kaynak commit’i aynı olsa bile taban image, paket deposu, zaman bağımlı indirmeler ve build değişkenleri farklı sonuç çıkarabilir. Staging’de geçen test bu durumda production artifact’ını değil, ona benzeyen başka bir üretimi doğrulamış olur. Üretim başına commit, build kaydı ve registry digest ilişkisini saklayın.

Tercih edilen akışta bir build oluşturulur, registry’ye gönderilir ve kaydedilen digest staging’e dağıtılır. Test ve onay sonrasında aynı digest production tanımına geçirilir. Ortama özel sırlar image içine gömülmez; çalışma anında kontrollü olarak sağlanır. Her ortamda farklı image zorunluysa bunun nedeni ve hangi farklılıkların test kapsamı dışında kaldığı açıkça kayıt altına alınmalıdır.

Çok mimarili image’larda hangi digest’i karşılaştırıyorsunuz?

Çok mimarili yayınlarda üst düzey image index’i ile platforma özgü manifest aynı nesne değildir. Bir tag, birden fazla işlemci mimarisine ait image’ları içeren bir index’e işaret edebilir. Runtime bulunduğu platform için uygun alt manifest’i seçer. Bu nedenle CI kayıtlarındaki üst digest ile çalışan container’ın platform digest’ini bağlamı olmadan karşılaştırıp “içerik değişmiş” demeyin.

Kabul kaydında hedef platformu, sabitlenen index veya manifest digest’ini ve beklenen ilişkiyi belirtin. Test makineleri ile production farklı mimarideyse uygulamanın yerel bağımlılıkları ayrıca sınanmalıdır. Digest takibi bu farklılığı görünür kılar; farklı mimarilerde aynı davranışı kendiliğinden garanti etmez. Runtime’ın sunduğu image kimliği alanlarının anlamını kullandığınız container motoruna göre doğrulayın.

İçerik kimliği, imza ve zafiyet taraması ayrı kontrollerdir

Digest “hangi içerik?” sorusunu cevaplar. İmza doğrulama, doğru güven politikasıyla birlikte “bu içeriği hangi yetkili kimlik onayladı?” sorusuna yardımcı olur. Build provenance, artifact’ın hangi kaynak ve üretim sürecinden geldiğini kaydeder. Zafiyet taraması ise bilinen riskleri belirli bir anda değerlendirir. Bunları tek bir yeşil kontrol kutusuna indirmek yerine ayrı kanıt olarak saklayın.

İmzanın varlığı tek başına yeterli değildir; beklenen yayıncı, repository, iş akışı ve güven köküyle doğrulanması gerekir. Tarama sonucu da kalıcı bir güvenlik belgesi sayılmaz: yeni açıklanan bir açık, daha önce temiz görünen image’ı riskli hale getirebilir. Yeniden tarama sıklığı ve kritik bulguya yanıt sorumlusu tanımlanmalıdır. Politika ihlalinde yayını durduracak kişinin kim olduğu önceden belli olsun.

Registry izinlerini yayın zincirine göre daraltın

Build sisteminin image gönderme yetkisine ihtiyacı olabilir; production node’un genellikle yalnız çekme yetkisi yeterlidir. Her iki tarafı aynı geniş token ile yönetmek, bir çalışma ortamındaki sızıntının tüm yayın deposuna yayılmasını kolaylaştırır. Ortama özel kimlikler, kısa ömürlü erişim mümkünse bunun kullanılması ve sır yenileme prosedürü risk alanını daraltır.

Registry ayarlarını değiştirirken yalnız yeni deployment’ı değil, yeniden başlayan eski bir instance’ın image çekebilmesini de test edin. Geçerli pull yetkisi olmayan bir sistem mevcut cache sayesinde günlerce sağlıklı görünebilir. Yeni veya boş bir node üzerinde kontrollü çekme denemesi, gizlenen erişim sorununu ortaya çıkarır. Bu test üretim trafiğini bozmadan, yetkili bakım kapsamında yapılmalıdır.

Digest sabitleme güncellemeyi dondurmak değildir

Bir digest’e sonsuza kadar bağlı kalmak, eski taban image ve kütüphanelerin açıklarını da taşımak anlamına gelebilir. Sabitlemenin amacı kontrolsüz değişimi önlemektir; kontrollü güncellemeyi durdurmak değildir. Yeni taban veya bağımlılık sürümüyle ayrı artifact üretin, test edin ve onaylı digest’i değiştirin. Böylece hem tekrar üretilebilir yayın kaydı hem de düzenli güvenlik bakımı korunur.

Registry temizliğinde son başarılı production artifact’larını ve gerekli rollback sürümlerini koruyun. Etiketsiz image’ların tamamını silen bir kural, digest üzerinden çalışan deployment’ların sonraki çekmesini bozabilir. Saklama politikası yalnız disk maliyeti kararı değildir; geri dönüş kapasitesinin bir parçasıdır. Politikanın image manifest ve ilişkili blob’lara nasıl uygulandığı kullandığınız registry’de doğrulanmalıdır.

Yayın öncesi pratik kabul listesi

• Kaynak commit, build kaydı ve yayınlanan digest aynı değişiklik kaydında bulunuyor.
• Staging’de test edilen artifact production’a yeniden build edilmeden ilerliyor.
• Hedef mimari ve index/manifest ilişkisi açıklanmış durumda.
• Beklenen yayıncıya göre imza veya provenance kontrolü tanımlı; tarama sonuçları ayrı kayıtlı.
• Production pull yetkisi yeni node üzerinde kontrol edilmiş.
• Önceki artifact registry’de saklı ve geri çekme denemesi başarılı.
• Yeni image ile gelen veritabanı şema değişikliğinin geri alma uyumluluğu ayrıca değerlendirilmiş.

Son madde özellikle önemlidir: eski image’ı yeniden çalıştırabilmek, değişen veritabanıyla güvenli çalışacağını kanıtlamaz. Uygulama ve şema değişikliklerinin uyumluluk penceresi ayrı bir kabul konusudur. Rollback dosyasında yalnız önceki digest değil, yapılandırma ve veri bağımlılıkları da yer almalıdır. Aksi halde artifact kontrolü sağlam olsa bile iş akışı geri dönemeyebilir.

Narweb ile CI/CD yayın zincirinizi değerlendirin

Bir ekip için doğru başlangıç karmaşık bir platform değil, mevcut hattaki belirsizliği azaltmaktır. Narweb DevOps hizmeti kapsamında değerlendirme yaparken registry yapınızı, dağıtım ortamlarınızı ve mevcut yayın sürecinizi paylaşın. Altyapı ihtiyacı için cloud sunucu seçenekleri ayrıca incelenebilir. Artifact doğrulama ve güvenli yayın kapsamını görüşmek için iletişime geçin.

Resmî kaynak: Docker image digest ve çok platformlu manifest açıklaması. İmza, saklama ve yetkilendirme adımları seçilen registry ve CI sisteminin belgelerine göre uygulanmalıdır.