Docker konteynerlerinde güvenlik güncellemeleri nasıl ele alınır?


117

Uygulamaları sunuculara dağıtırken, genellikle uygulamanın kendisiyle ne paketlediği ile platformdan ne beklediğini (işletim sistemi ve yüklü paketler) arasında bir ayrım vardır. Bunun bir noktası, platformun uygulamadan bağımsız olarak güncellenebilmesidir. Bu, örneğin, tüm uygulamayı yeniden oluşturmadan platform tarafından sağlanan paketlere acil olarak güvenlik güncelleştirmelerinin uygulanması gerektiğinde faydalıdır.

Geleneksel olarak güvenlik güncellemeleri, işletim sistemine paketlerin güncellenmiş sürümlerini yüklemek için bir paket yöneticisi komutu yürütülerek uygulanmıştır (örneğin, RHEL'de "yum update"). Ancak, konteyner görüntülerinin esas olarak hem uygulamayı hem de platformu bir araya getirdiği Docker gibi konteyner teknolojisinin ortaya çıkmasıyla, sistemi güncel bir konteynerle tutmanın kanonik yolu nedir? Hem ana bilgisayarın hem de kapsayıcıların kendi, bağımsız, ana bilgisayarda güncellenmesi ve güncelleştirilmesi gereken paket kümeleri vardır, kapların içindeki hiçbir paketi güncellemez. Docker konteynerlerinin özellikle öne çıktığı RHEL 7'nin piyasaya sürülmesi ile Redhat'ın konteynerlerin güvenlik güncellemelerini yapmanın tavsiye ettiği yolu duymak ilginç olurdu.

Seçeneklerden birkaçı üzerine düşünceler:

  • Paket yöneticisinin ana bilgisayardaki paketleri güncellemesine izin vermek, kapların içindeki paketleri güncellemez.
  • Güncellemeleri uygulamak için tüm konteyner görüntülerini yeniden oluşturmak zorunda kalmak, uygulama ile platform arasındaki mesafeyi bozuyor gibi görünüyor (platformu güncellemek Docker görüntülerini oluşturan uygulama oluşturma işlemine erişim gerektirir).
  • Çalışan konteynerlerin her birinin içinde el ile çalıştırma komutları zahmetli görünüyor ve bir sonraki uygulama kapsayıcılarının uygulama sürümünden güncelleştirilmesinden sonra değişikliklerin üzerine yazılma riski var.

Yani bu yaklaşımların hiçbiri tatmin edici görünmüyor.


1
Bunun için şimdiye kadar gördüğüm en iyi fikir Atomic Projesi . Ben öyle düşünmüyorum oldukça olsa prime time için hazır.
Michael Hampton

1
Valko, hangi işle karşılaştın? Uzun süreli kaplar çalıştırıyorum (örneğin php-cgi'yi barındırıyorum) ve şu ana kadar bulduğum şey: docker pull debian/jessiegörüntüyü güncellemek, daha sonra mevcut görüntü (ler )imi yeniden oluşturmak, kapları durdurmak ve yeniden çalıştırmak ( Yeni görüntü ile). Oluşturduğum görüntüler öncekilerle aynı isme sahip, bu yüzden başlangıç ​​script ile yapılıyor. Sonra "isimsiz" resimleri kaldırdım. Daha iyi bir iş akışını kesinlikle takdir ediyorum.
miha

1
miha: Yaptığım şeye benziyor. Temel olarak, tüm görüntüleri yeni sürümler çıkarmanın bir parçası olarak sürekli güncelleme ve yeniden oluşturma Ve yeni görüntüleri kullanarak kapları yeniden başlatmak.
Markus Hallmann

1
En iyi yanıt buraya Johannes Ziemke ne dediğini yapmak ana commandlines içeren bir komut olduğundan çok yardımcı olur:
Hudson Santos

İlginç soru. Bunu kendim merak ediyorum. Bir liman işçisi ana bilgisayarında çalışan 20 uygulamanız varsa, temel görüntüleri yükseltmeniz, yeniden oluşturmanız ve yeniden başlatmanız gerekir! 20 uygulama ve güvenlik güncelleştirmesinin hepsini etkileyip etkilemediğini veya yalnızca birini etkilediğini bile bilmiyorsunuz. Güvenlik güncellemesi örneğin sadece libpng'yi etkilediğinde Apache gibi bir resmi yeniden oluşturmalısınız. Bu yüzden gereksiz yeniden yapılanmalar ve yeniden başlatmalar ile
bitiyorsunuz

Yanıtlar:


47

Bir Docker resmi, uygulama ve "platform" paketlerini içerir; bu doğru. Ancak genellikle görüntü, temel görüntüden ve gerçek uygulamadan oluşur.

Dolayısıyla, güvenlik güncellemelerini almanın kurallı yolu temel resmi güncellemektir, ardından uygulama resminizi yeniden oluşturun.


3
Teşekkürler, bu kulağa mantıklı geliyor. Sadece hala platformun güncellenmesini diliyorum, böylece konuşmanın tüm uygulamanın yeniden paketlenmesini tetiklemesine gerek kalmayacak (örneğin, tek bir temel görüntünün güncellenmesi nedeniyle 100 farklı uygulama görüntüsünün yeniden oluşturulması gerektiğini düşünün). Fakat belki de bu, Docker’ın her şeyi tek bir görüntüde bir araya getirme felsefesiyle kaçınılmazdır.
Markus Hallmann

3
@ValkoSipuli İşlemi otomatikleştirmek için her zaman bir komut dosyası yazabilirsiniz.
dsljanus

Neden apt-get upgrade, dnf upgrade, pacman -syu, vb. Bunu yapan ve ardından uygulamayı çalıştıran bir kabuk betiği bile oluşturabilir , daha sonra kabı başlatıldığında / yeniden başlatıldığında tüm paketlerini yükseltmesi için bunu kabın giriş noktası olarak kullanabilirsiniz.
Arthur Kay

8
@ArthurKay İki nedeni: 1) Eski ebattaki paketi görüntüde tutarken, yükseltilen tüm paketler konteyner katmanına ekleneceğinden, konteyner boyutunu havaya uçurursunuz. 2) (container) resimlerin en büyük avantajını yitirir: Çalıştırdığınız resim oluşturduğunuz / test ettiğinizle aynı değildir çünkü çalışma zamanında paketleri değiştirirsiniz.
Johannes 'fish' Ziemke

7
Anlamadığım bir şey var: Docker konteyner olarak gönderilen bir yazılım parçası satın alan bir şirketseniz, bir güvenlik sorunu ortaya çıktığında uygulama üreticisinin uygulama paketini yeniden kurmasını beklemeniz gerekir. ? Hangi şirket açık güvenlik açıkları üzerindeki kontrolünü bu şekilde bırakacaktır?
Sentenza

7

Konteynırlar hafif ve değiştirilebilir olmalıdır. Kapsayıcınızın güvenlik sorunu varsa, yeni kapsayıcıyı yayan ve dağıtan bir kapsayıcı sürümünü yeniden oluşturursunuz. (birçok konteyner bağımlılıklarını kurmak için apt-get gibi standart paket yönetim araçlarını kullanan standart bir temel görüntü kullanır, yeniden inşa etmek güncellemeleri depolardan çeker)

Konteynerlerin içine yama yapabiliyorken, bu iyi bir şekilde ölçeklenmeyecek.



0

Öncelikle, geçmişte geleneksel olarak koştuğunuz güncellemelerinizin çoğu basitçe kabın içinde kalmayacak. Kap, geçmişte görmeye alıştığınız tam dosya sisteminin oldukça hafif ve küçük bir alt kümesi olmalıdır. Güncellemeniz gereken paketler, DockerFile'nizin bir parçası olan paketlerdir ve DockerFile'niz olduğundan, güncellemeleri gereken bu paketleri ve konteyner kimliklerini takip edebilmelisiniz. Yakında piyasaya sürülecek olan Cloudstein'ın kullanıcı arayüzü, bu DockerFile bileşenlerini sizin için takip ediyor, böylece bir tanesi konteynerleri için en uygun olan güncelleme şemasını oluşturabiliyor. Bu yardımcı olur umarım


-1

genellikle sağladığınız üç seçenekden bile daha kötü. Liman görüntülerinin çoğu paket yöneticileriyle oluşturulmaz, bu nedenle liman görüntülerine giremez ve güncelleme yapamazsınız. Liman işçisi görüntüsünü yeniden oluşturmanız veya yeniden oluşturmanız gerekecektir.

Güvenlik düzeltme ekleri için yeniden inşa etmeniz veya başkalarına bakmanız gerekmesi çoğu durumda mantıksız görünüyor.

Sonar ve radarrları liman işçisi konteynırlarına yerleştirmeyi düşünüyordum ama konteynırımın düzenli güvenlik güncellemelerini almayacaklarını bilmek bir kontrat kırıcı oldu. Konteynırım için güvenlik güncellemelerini yönetmek, her docker görüntüsüne ayrı ayrı güvenlik güncelleştirmeleri el ile uygulamak zorunda kalmadan uğraşmak zorunda kalmaz.


1
Sorunuza cevap vermediğiniz için gönderiniz bir cevap olarak değerlendirilmez. Lütfen soruyu yorum olarak ekleyin ve "cevabınızı" kaldırın. StackExchange bir forum değildir, ancak uzmanların yardım sağlayabilecekleri soruları yanıtladıkları bir soru ve cevap olarak düşünülmelidir.
Phillip -Zyan K Lee- Stockmann
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.