Birçok yazılım geliştirme ekibi, Docker Hub gibi resmi kayıtlardan kapsayıcılar kullanır. Bu görüntüler genellikle birçok bileşen içerir. Trivy veya Grype gibi tarayıcılar bu nedenle birçok CVE (bu serinin Bölüm 1'e bakınız), haklı olarak (gerçek pozitif) veya yanlış alarmlar (sahte pozitif) olarak bulurlar. Resmi görüntüler çoğunlukla ücretsiz olmasına rağmen, ekip gerçekten sömürülebilecek araştırmayı terk etme riskiyle karşı karşıya kalmadıkça, bildirilen CVE'nin sınavı (triyajı) içinde bir maliyet pilotu olabilir.
Marius Shekow, 10 yılı aşkın bir süredir Fraunhofer'da araştırmacı ve yazılım geliştiricisi olarak çalıştı. 2022'den itibaren Bonn'daki Sprintein'da Piombo DevOps & Bulut Mühendisiydi
Bu soruna bir çözüm sunmak için “dağıtım”, “sertleştirilmiş” veya “kesilmiş” olarak da bilinen minimum konteyner görüntüleri. “Daha az bileşen daha az zayıflık anlamına gelir” sloganı altında, normalde hedef alanı azaltmak için kullanılmayan tüm bileşenlerden (kabuk veya paket yöneticileri gibi) daha az yaparlar.
Avantajlar ve dezavantajlar arasında bir karşılaştırmaya ve ücretsiz minimum görüntülerin bir listesine dayanarak ve temel linux, php, python, java, c#/için ödenir. Net and Node.js, bu makale ekip takımlarını seçen bu makaleye yardımcı olmalıdır.
Minimal görüntüler nedir?
Minimum görüntüler yalnızca gerçek temel işlevleri gerçekleştirmek için kesinlikle gerekli bileşenleri içerir (Postgreesql sunucusu postgres görüntüsündeki temel bileşendir). Amaç, bilgisayar korsanları için saldırı alanını mümkün olduğunca azaltmak (bkz. Şekil 1) ve örneğin bileşenleri hariç tutmaktır:
- Distro için belirli paketler yöneticisi, ör. Debian/Ubuntu için APT, Alpin için APK veya Red Hat için DNF/Yum
- Linux Dystro için genellikle varsayılan olarak yüklenen ancak bir uygulamayı gerçekleştirmek için gerekli olmayan çeşitli spesifik paketler, ör. Perl, Greep veya GZIP için ikili dosyalar ve kitapçılar. Bu bileşenleri dışarıda bırakırsanız, renklendirme distribütörleri olmadan “dağıtım” görüntüsünüz vardır.
- Bir kabuk (örn. /Bin /Bash veya /bin /shal)
- Hata ayıklama araçları, örneğin bağlantı problemlerini teşhis etmek için kıvrılma
İnce görüntüler (örn. Python: 3.13-Slim) genellikle görüntülerin normal varyasyonlarından daha küçük olsa da (örn. Python: 3.13) hala bir kabuk ve bir paket yönetici içerir ve bu nedenle bir saldırganın bir sistemde daha derine nüfuz etmesini kolaylaştırır!
Bileşenleri karşılaştırın: minimum görüntüler ile minimum değil (Şekil 1)
|
Minimum görüntülerin avantajları ve dezavantajları |
|
|
Avantajlar |
Dezavantajlar |
|
✅ Azaltılmış başlangıç süresi |
❌ Hata ayıklanması daha zor |
|
✅ Daha az güvenlik ve triyaj iş boşlukları |
❌ Test masraflarında artış |
|
✅ Güvenlikte iyileşme |
❌ Araştırma çabalarında artış |
Minimum görüntüler mutlaka en iyi seçim olmadığı için tabloya karşı çıkan avantajların ve dezavantajların ayrıntılarına bir bakış.
Avantajlar:
- Başlangıç süresi azaltılmış: Minimum görüntüler çok küçük ve bu nedenle daha hızlı başlıyor çünkü indirme ve immalitasyon daha az zamana ihtiyaç duyuyor.
- Daha az güvenlik ve triyaj çalışması ve işinin çalışması: Trivy veya Grype gibi güvenlik açığı tarayıcıları, minimal görüntüler için (ortalama olarak) minimal olmayan görüntülere kıyasla önemli ölçüde daha az zayıf noktalar. Bu nedenle ekip, tarayıcının potansiyel yanlış pozitif bulgularını incelemek yerine yazılımın geliştirilmesine odaklanabilir (bu serinin 1. Bölümüne bakınız).
- Güvenliğin iyileştirilmesi: Bir saldırgan görüntüde çalışan görüntünün zayıf bir noktasını kullanmayı başarırsa (örneğin bir Postgresql görüntüsünde zayıf bir PostgreSQL noktası), kabuk komutlarını gerçekleştiremez. Çünkü minimum görüntüde kabuk yok. Bu nedenle, altyapıya (sanal) daha fazla sızmak için ek yazılım indiremez. Diğer bir avantaj, Trivy gibi güvenlik açığı tarayıcılarının, yanlış negatif şeylerden kaçınan en az görüntülerde mevcut tüm bileşenleri doğru bir şekilde tanımlamasıdır.
Dezavantajlar:
- Hata ayıklamayı gerçekleştirmek daha zor: Üretim işletme sorunları durumunda, geliştiriciler veya şirket ekipleri hata ayıklama kontrollerini gerçekleştirmek için genellikle kabuğa doğrudan konteynere erişir. Minimal görüntülerle, bu artık işe yaramıyor. Bununla birlikte, Kubectl hata ayıklama veya en iyi CDIBUG gibi alternatif çözümler vardır. Her ikisi de işlemlerin ve dosya sisteminin uzay adlarını gerçekleştirilecek kapsayıcı ile paylaşan kısa ömürlü bir sepet kap (geçici) başlar.
- Test masraflarında artış: Yetkiliyi minimum bir resimle değiştirirseniz, ekip uyumluluk sorunları olup olmadığını manuel olarak kontrol etmelidir. Özellikle, Python'un tam olarak görüntülenmesi gerektiği gibi çalışma zamanı için çok aşamalı yapılar. “Yap” gününde uygulamaya uyun ve ardından minimum temel görüntüyü kullanan “son” günlere kopyalayın. Bununla birlikte, yapım günlerinde resmi (minimal olmayan) görüntü kullanılırsa, iki faz arasındaki uygulamanın spesifik uyumsuzluğu genellikle meydana gelir. Örneğin, bazı kitapçılar (yerel) veya ikili dosyalar minimum son günlerde eksiktir. Veya çalışma zamanı için rota farklıdır, bu nedenle kabın başlangıcı başarısız olur. Python için spesifik bölüm somut bir örnek bağlar.
Ek olarak, eksik kabuk nedeniyle minimum bir görüntü kullanırken, kap başladığında birkaç komut (veya kabuk giriş noktası komut dosyaları) gerçekleştirmek mümkün değildir. - Araştırma çabalarında artış: Bu makale en iyi minimum görüntüyü bulmak için araştırma süresini azaltsa da, araştırma çabası her zaman azalır. Örneğin, uygun bir minimum görüntü olmadığını gösterebilir, bu nedenle ilgili taraflar, makale dizisinin 3 3. Bölümünün konusunu ve konusunu kendileri yaratmalıdır.
Minimum Görüntüler (Base) Mevcut
Şu anda, minimum görüntüler hala niş bir pazar. Resmi temel görüntülerin (örn. Python tercümanı) veya PostgreSQL gibi özerk yazılımların bakımı şimdiye kadar minimum görüntülerin oluşturulmasından kaçınmıştır.
Aşağıdaki bölüm, çeşitli temel zamanlar ve basit bir temel linux için temel görüntünün alternatiflerine çeşitli alternatiflere sahiptir. Bunlar tipik görüntüler, kullanıcılar FROM-üzerinde uygulamalarınızı oluşturmak için belirtilen Docker dosyasında çalıştı.
Alternatif arayışı sırasında, aşağıdaki seçim kriterlerini dikkate almanız tavsiye edilir:
- Görüntü koruyucu, minimum görüntüleri düzenli olarak yeniden yapılandırır, ör. Birkaç günde bir mi? Bunun böyle olmadığı görüntüler göz ardı edilmelidir. Docker Tag Monitor, belirli görüntü etiketlerinin rekonstrüksiyon frekansını belirlemeye yardımcı olur (daha fazla ayrıntı yazar tarafından bu blog gönderisinde bulunabilir).
- Görüntüler şifreli, ör. B. House ile? Aksi takdirde, görüntünün manipüle edilmesi doğrulanamaz.
- Zayıf tarayıcılar (trivy gibi) bileşenleri doğru bir şekilde tanımlayabilir ve bunları zayıf veritabanlarıyla karşılaştırabilir mi? Aksi takdirde, minimum görüntünün zayıf noktalar içerip içermediği açık değildir (bkz. Bu serinin 1. Bölümü).
Aşağıda sunulan tüm görüntüler kriterleri karşılamaktadır, aksi takdirde makale istisnaları açıkça gösterir. Aşağıdaki tablo, çeşitli kullanım durumları için piyasada bulunan üreticilere (Colonne 2-4) genel bir bakış sunmaktadır (sütun 1):
|
Karşılaştırılmış görüntülerin sağlayıcıları ve görüntüleri |
||||
|
Kullanım Örneği |
Google Droutless |
Wolfios / Chaound |
Ubuntu kesilmiş |
Dahası |
|
Temel linux |
✅ (4 varyant) |
✅ (2 ücretsiz varyant, ücretsiz olarak oluşturulabilen 1 ödeme varyantı))) |
⚠️ (sadece araba ile -Hthe) |
– |
|
PHP |
❌ |
✅ (en son sürüm yukarı akış) |
❌ |
– |
|
python |
✅ (v3.11, ctypes için destek yok) |
✅ (en son sürüm yukarı akış) |
✅ (v3.10, v3.12) |
– |
|
Java |
✅ (v17, v21) |
✅ (en son sürüm yukarı akış) |
✅ (v8, v11, v17, v21) |
şımarık |
|
C# / .net |
❌ |
✅ (en son sürüm yukarı akış) |
✅ (.NET V6-10, Microsoft tarafından) |
– |
|
Node.js |
✅ (v20, v22) |
✅ (en son sürüm yukarı akış) |
⚠️ (v18, iyi hayat |
– |
Bir yanıt yazın