Docker'ı görünür bir sorun yaşamadan aylarca üretimde çalıştırabilirsiniz. Kapsayıcılar başlıyor, uygulamalar yanıt veriyor, hiçbir şey bozulmuyor. Daha sonra açığa çıkan bir bağlantı noktası veya yanlış yapılandırılmış bir izin, saldırganın kazanmak zorunda olmadığı bir dayanak noktası oluşturur. Çoğu Docker güvenlik hatası, bir şeyler ters gidene kadar hata gibi görünmez.
Bu makale, konteyner ortamlarını riske sokan belirli yapılandırmaları, her birinin bir saldırgan için neleri mümkün kıldığını kapsar ve bugün kendi kurulumunuz üzerinde çalıştırabileceğiniz bir kontrol listesiyle sonlanır.
Docker Güvenliği Neden Göründüğünden Daha Zor?
Konteynerler izole edilmiş hissediyor. Birini başlatırsınız, kendi işlem alanını çalıştırır ve onun içinde bir sonraki konteyner mevcut değildir. İzolasyon elde edersiniz, ancak bu yalnızca kısmidir. Konteynerler ana bilgisayarın çekirdeğini paylaşır; bu, bir konteyner içindeki bir işlemin belirli koşullar altında ana bilgisayar sistemine tamamen ulaşabileceği anlamına gelir.
Docker gemileri, üretimin güçlendirilmesi için değil, geliştiricilerin rahatlığı için yapılandırılmıştır. Kök erişimi açık. Tüm bağlantı noktaları tüm arayüzlere bağlanabilir. Çalışma zamanı izleme yok. Çoğu geliştirici bu ayarları kabul eder, kapsayıcıyı gönderir ve yoluna devam eder. Bu, başlamak için makul bir yaklaşım; bu bitmiş bir güvenlik duruşu değil.
Buna göre Red Hat'in 2024 Kubernetes Güvenliği Durumu raporuKuruluşların %67'si, konteyner veya Kubernetes güvenliği endişeleri nedeniyle uygulama dağıtımını geciktirdi veya yavaşlattı. Bu sürtünme genellikle saldırılardan kaynaklanmaz. Bu, kendilerinde kurmadıkları konteyner kurulumlarının sağlamlaştırılması gerektiğini keşfeden ekiplerden geliyor.
Genellikle geliştiricinin yerel makinesindekiyle aynı yapılandırmayla üretimde çalışan konteynerler görüyoruz. Docker'ın güvenlik hatalarının, bir şey denetlenene veya başarısız olana kadar hiçbir görünür belirti olmadan, sessizce bir araya gelme eğiliminde olduğu yer burasıdır.
Bu boşlukları yaratan hatalar, yapılandırma düzeyinden başlayarak spesifik, öngörülebilir ve çoğunlukla önlenebilir niteliktedir.
Yaygın Docker Yapılandırma Hataları
Çoğu konteyner ihlali sıfır günlük bir istismarla başlamaz. Ağın kullanıma sunulması veya ayrıcalık kapsamı hakkında fazla düşünmeden, ilk günkü bir yapılandırma seti ile başlarlar.
Varsayılan Docker ayarları çalışacak şekilde tasarlanmıştır. İşlevsel ve güvenli arasındaki boşluk, özellikle dağıtılan ve asla yeniden ziyaret edilmeyen, kendi kendine barındırılan kurulumlarda Docker konteyner güvenliği risklerinin biriktiği yerdir.
Bu modeli sıklıkla görüyoruz: genel IP sunucularındaki, bağlantı noktası bağlamaları, kullanıcı ayarları ve ağ yapılandırmaları tam olarak ilk dağıtımda olduğu gibi olan kaplar.
Container'ları Kök Olarak Çalıştırma
Bir Docker konteynerini kullanıcı belirtmeden başlattığınızda root olarak çalışır. Bu, uygulamanız da dahil olmak üzere kapsayıcı içindeki herhangi bir işlemin, kapsayıcının ad alanı içinde kök düzeyinde ayrıcalıklara sahip olduğu anlamına gelir.
Bir kabın içindeki kök, ana bilgisayardaki kök ile aynı değildir ancak ayrım mutlak değildir. İyi belgelenmiş runc CVE-2019-5736 ve benzer çalışma zamanı kusurları gibi çalışma zamanını hedef alan ayrıcalık yükseltme istismarları, başarılı olmak için sıklıkla bir kök konteyner işlemi gerektirir.
Kök olmayan kapsayıcılar, bu güvenlik açığı sınıfı için saldırı yüzeyini önemli ölçüde daraltarak bu istismarların bağlı olduğu kök süreç gereksinimini ortadan kaldırır, ancak kapsayıcıdan kaçış riskini tamamen ortadan kaldırmaz.
Dockerfile'ınıza bir USER yönergesi eklemek bu sorunu giderir. Bazı resmi görseller, USER direktifiyle etkinleştirebileceğiniz ayrıcalıksız bir kullanıcıyla birlikte gönderilir, ancak çoğu, hazır bir uygulama kullanıcısı olmadan varsayılan olarak root'u kullanır. Bu durumlarda kullanıcıyı Dockerfile'a geçmeden önce oluşturursunuz. Kendi kendine barındırılan kurulumların çoğu için bu tek değişiklik, üst kademeye iletme riski kategorisinin tamamını ortadan kaldırır.
Çok Fazla Bağlantı Noktasını Genel İnternete Açığa Çıkarma
Docker ile bir bağlantı noktası yayınladığınızda Docker kendi iptables kurallarını doğrudan yazar. Bu kurallar, ana bilgisayar düzeyindeki güvenlik duvarı kurallarından önce çalışır. Bu bir topluluk tarafından bildirilen iyi bilinen davranış Ve Docker'ın paket filtreleme kılavuzunda belgelenmiştir, yanlış bir yapılandırma değildir ve bu, UFW ve benzeri araçların Docker'ın zaten açtığı şeyleri engellemediği anlamına gelir.
Docker, birçok Linux ana bilgisayarında UFW ve güvenlik duvarı varsayılanlarını atlayarak doğrudan iptables'a yazar. Bu, güvenlik duvarınız yapılandırılmış görünse bile 0.0.0.0'a bağlı bir bağlantı noktasının herkese açık olarak erişilebilir olabileceği anlamına gelir. Bulut güvenlik grupları ve DOCKER-USER zincir kuralları bu trafiği yine de engelleyebilir; dolayısıyla gerçek risk, özel ağ kurulumunuza bağlıdır.
Mümkün olduğunda hizmetleri 127.0.0.1'e bağlayın, halka açık trafiği ters proxy üzerinden yönlendirin ve yalnızca gerçekten harici erişim gerektiren şeyleri yayınlayın. Ters proxy, ana bilgisayarın dışından açığa çıkanları kontrol etmenin en güvenilir yoludur.
Konteynerler Arasındaki Ağ İzolasyonunun Yoksayılması
Bu ağdaki herhangi bir konteyner, kısıtlama olmaksızın üzerindeki diğer konteynerlere erişebilir. Varsayılan köprü, onu paylaşan kapsayıcılar arasında hiçbir trafik filtrelemesi uygulamaz ve çoğu kurulum bu yapılandırmayı asla değiştirmez.
Bir konteynerin güvenliği ihlal edilirse bu açık iletişim, yanal bir hareket yoluna dönüşür. Bir ön uç kapsayıcısı, bir veritabanına, dahili bir API'ye veya aynı varsayılan köprü ağındaki herhangi bir şeye, bu erişim hiçbir zaman amaçlanmamış olsa bile erişebilir.
Kullanıcı tanımlı ağlar, hangi kapsayıcıların iletişim kurabileceği konusunda size açık kontrol sağlar, ancak tüm hizmetleriniz tarafından paylaşılan tek bir özel ağ, yine de kapsayıcılar arası ücretsiz trafiğe izin verir. Gerçek izolasyon, birbiriyle konuşmaması gereken hizmetlerin ayrı ağlara yerleştirilmesini gerektirir. Varsayılan köprüyü kapatmak bitiş çizgisi değil başlangıç noktasıdır.
Docker Soketine Bakış
/var/run/docker.sock adresindeki Docker soketi, tüm Docker motorunun kontrol arayüzüdür. Bunu bir konteynere monte etmek, konteynerin ana makinede çalışan arka plan programına doğrudan API erişimi sağlar.
Bu erişimle, bir konteyner yeni konteynerler başlatabilir, ana bilgisayar dizinlerini bağlayabilir, çalışan konteynerleri inceleyebilir ve değiştirebilir ve ana makineyi etkili bir şekilde kontrol edebilir. Saldırı yüzeyi, ana bilgisayardaki root işlemine eşdeğerdir; bu nedenle soket erişimi gerektiren herhangi bir araç, dikkatli bir değerlendirmeyi hak eder.
Çoğu kullanım durumunda daha güvenli alternatifler vardır: Kapsamlı API'ler veya Docker yönetim araçları Soket erişimi gerektirmeyen. Docker-in-Docker kendi güvenlik ve operasyonel ödünleşimlerini taşır ve doğrudan bir alternatif değildir.
Yapılandırma hataları ilk maruz kalmayı yaratır. İmaj ve bağımlılık seçimleri, bu maruziyetin zaman içinde nasıl birleşeceğini belirler.
Konteynerden Daha Uzun Ömürlü İmaj ve Sırlar Hataları
Bir konteyneri durdurduğunuzda içindeki konfigürasyon hataları da onunla birlikte durur. Bir güvenlik açığı veya sabit kodlanmış bir kimlik bilgisi taşıyan bir görüntüden yeniden oluşturduğunuzda sorun kapsayıcıda yeniden başlar. Görüntü düzeyindeki hatalar dağıtımlar arasında sıfırlanmaz.
Görüntüyü çeken her ortama, onu saklayan her kayıt defterine ve onu çalıştıran her ekip üyesine görüntüyle birlikte giderler. Bu ısrar, görüntü ve sır yönetimini, yapılandırmadan ayrı olarak denetlenmeye değer, ayrı bir risk kategorisi haline getirir.
Bu modeli sıklıkla görüyoruz: Proje başlangıcında dikkatlice seçilen ve o zamandan beri asla yeniden oluşturulmayan, başlangıçta temsil ettiği güvenlik temel çizgisinden yavaş yavaş sapan bir görüntü.
Güvenilmeyen veya Güncel Olmayan Görsellerin Kullanılması
Kamu kayıtları herkese açıktır. Kötü amaçlı görüntüler, konteyner yeniden başlatıldığında varlığını sürdüren katman geçmişine gömülü kripto madencilerini ve arka kapıları taşıyan Docker Hub aracılığıyla dağıtıldı. Özellikle resmi olmayan veya bilinmeyen yayıncılardan gelen görseller için çekmeden önce doğrulama önemlidir.
Ayrı bir sorun bayatlıktır. Altı ay önce çektiğiniz ve o zamandan beri yeniden oluşturmadığınız resmi bir görüntü, paketlerinde açıklanan her CVE ile yama yapılmamış Docker güvenlik açıklarını biriktiriyor. Görüntü bozuk değil. Artık güncel değil.
Sonatype'ın 2024 Yazılım Tedarik Zincirinin Durumu raporu güvenlik açığı bulunan bir bileşenin %95 oranında tüketildiğini, sabit bir sürümün zaten mevcut olduğunu ve uygulama bağımlılıklarının %80'inin bir yıldan fazla bir süre boyunca yükseltilmeden kaldığını buldu. Bu model, aynı açık kaynak paketlerine dayandıkları için Docker temel görüntüleri için de geçerlidir.
Doğrulanmış yayıncıların resmi görsellerini kullanın ve "en son"a güvenmek yerine belirli sürüm etiketlerini sabitleyin. Resimlerinizi güncel tutmak için düzenli bir yeniden oluşturma temposu oluşturun.
Dockerfiles ve Compose Dosyalarında Sabit Kodlama Sırları
Dockerfile ENV veya ARG talimatına yazılan, Compose ortam bloğuna sabit kodlanan, derleme bağımsız değişkenleri olarak iletilen veya sürüm kontrolüne ayrılmış bir .env dosyasında saklanan kimlik bilgileri, kapsayıcıyı durdurduğunuzda kaybolmaz. Görüntü katmanı geçmişinde veya kaynak kontrolünde kalırlar ve erişebilen herkesin erişimine açıktırlar.
Bu, geliştirme sırasında gözle görülür sorunlara neden olmadığı için en çok gözden kaçan Docker güvenlik hatalarından biridir. ENV talimatındaki bir API anahtarı düzgün çalışıyor. Aynı zamanda deponuzdadır, görselinize eklenir ve görselin gittiği her yere dağıtılır.
Modern Docker Compose, kimlik bilgilerini çalışma zamanında görüntüye eklemeden bağlayan yerel bir sır mekanizmasını destekler. Docker'ın gizli dizi API'si ve harici gizli dizi yöneticileri aynı prensibi izler. Bunlar, kimlik bilgilerini derleme yapıtlarının ve taahhüt edilen dosyaların tamamen dışında tutan seçeneklerdir.
Çalışma zamanı ortam değişkenleri, sabit kodlanmış kimlik bilgilerine göre bir gelişmedir, ancak yine de Docker inceleme çıktıları, günlükleri ve kilitlenme dökümleri aracılığıyla açığa çıkarlar. Bunlar bitmiş bir çözüm değil, pişmiş sırlardan bir adım öndedir.
Konteyner Görüntülerini Düzenli Olarak Güncellememek
Aylarca aynı görseli yayınlamak yaygın bir alışkanlıktır. Her geçen gün yeni bir güvenlik açığı açığa çıkar, ancak yeniden yapılandırmadan önce, konteynerleriniz gözle görülür bir değişiklik olmadan büyüyen bir maruz kalma penceresi taşır.
Tutarlı bir yeniden inşa programı oluşturun. Mümkün olduğunda bu süreci otomatikleştirin ve mevcut resimlerinizde düzenli aralıklarla bir güvenlik açığı tarayıcısı çalıştırın. Amaç mükemmellik değil. Bir yamanın yayınlanmasıyla dağıtılması arasındaki süreyi daraltıyor.
Hızlı dağıtımlarda erişim kontrolü ve izlemenin önceliği ortadan kalkabilir. Aynı zamanda olayların en uzun süre fark edilemediği kategorilerdir.
Erişim Kontrolü ve Görünürlük Boşlukları
Bir kapsayıcı sağlam bir yapılandırmayla ve geçerli görüntülerle çalıştırıldıktan sonra iki hata kategorisi kalır. Her ikisi de doğası gereği görünmezdir: Birisi kullanana kadar zayıf bir erişim kontrolü sorununu fark etmeyeceksiniz ve hiç günlüğe kaydedilmemiş bir etkinliği araştırmanız gerekinceye kadar bir izleme açığını fark etmeyeceksiniz.
Aynısı Red Hat 2024 araştırması Ekiplerin %42'sinin konteyner güvenliği ve ilgili tehditleri ele almak için yeterli yeteneklere sahip olmadığını buldu.
İzleme boşluklarının genellikle daha önce değil, olay soruşturmaları sırasında ortaya çıktığını görüyoruz. Görünürlük bir öncelik haline geldiğinde, çoğu zaman bir şeyi engellemek yerine ona tepki verir hale gelir.
Zayıf Kimlik Doğrulama ve Açıkta Kalan Yönetim Kontrol Panelleri
Kimlik doğrulaması olmayan bir genel IP üzerindeki konteyner yönetimi kontrol paneli, gelişmiş bir saldırgan gerektirmez. Adresi bilmelerini gerektirir. Bu, çoğu takımın düşündüğünden daha düşük bir çıta.
Kendi kendine barındırılan izleme ve yönetim araçları genellikle tüm ağ arayüzlerinden erişilebilen bir web arayüzüyle birlikte gelir. Bunları önlerinde kimlik doğrulaması olmadan genel bir IP'de bırakmak, bir yönetici panelinin kilidini açık bırakmanın kapsayıcı eşdeğeridir.
Kimlik doğrulama, ters proxy ve özel ağ yerleşimi temeldir. Erişim kontrolü, etkin olarak gönderilen bir şey değil, herhangi bir yönetim arayüzüne eklediğiniz bir yapılandırma adımıdır.
Aynı prensip aşağıdakiler için de geçerlidir: Docker CLI ve GUI yönetimi; Arka plan programına yönetici düzeyinde erişim, arayüzden bağımsız olarak aynı riski taşır.
Konteynerlerinizin Ne Yaptığını Takip Etmemek
Bir kapsayıcının güvenliği ihlal edilirse, saldırganın etkinliği bir iz oluşturur: işlem davranışı değişiklikleri, olağandışı ağ bağlantıları ve beklenmeyen dosya değişiklikleri. Günlük toplama işlemi yapılmadığında, bu iz üzerinde işlem yapabileceğiniz bir biçimde mevcut değildir.
Merkezi günlük toplama, konteyner denetim günlüğü tutma ve çalışma zamanı izleme araçları, anormal etkinlikleri daha ortaya çıkmadan önce tespit etmenizi sağlayacak verileri sağlar. Amaç her satırı analiz etmek değil. Araştırmanız gerektiğinde verilerin mevcut olmasını sağlar.
Üretimde hiçbir günlük ardışık düzeni ve uyarı olmadan sessizce çalışan konteyner kurulumları az bakım gerektirmez. Denetlenmiyorlar. Bunlar iki farklı çalışma durumudur.
Altyapı Ortamı Neden Önemlidir?
Konteyner güvenliği yapılandırmayla başlar ancak yapılandırma altyapının üzerinde çalışır. Yanlış yapılandırılmış ağ bağlantısına, paylaşılan kaynaklara veya ağ düzeyinde filtrelemeye sahip olmayan bir ana bilgisayar, üzerindeki her kapsayıcıyı etkileyen koşullar oluşturur. Konteyner kurulumunu doğru yapmak ve sunucu konfigürasyonunu doğru yapmak iki ayrı görevdir.
Docker güvenlik açıklarının çoğu, konteynerlerin devraldığı koşullar nedeniyle daha da artıyor:
- Kiracılar arasında donanım yalıtımı olmayan, paylaşılan kiracılı bir sunucu
- Yamasız çalışan bir ana bilgisayar çekirdeği
- Yerleşik ağ düzeyinde filtrelemeye sahip olmayan bir ana bilgisayar
Uygun konteyner sağlamlaştırmanın altyapı katmanından bağımsız olarak önemli olması nedeniyle bu, yukarıdaki yapılandırma adımlarına olan ihtiyacı ortadan kaldırmaz. Yalıtılmış altyapıyla başlamak denklemdeki bir endişe katmanını ortadan kaldırır.
Cloudzy'de kurulumunuzun gerektirdiğine bağlı olarak iki yol sunuyoruz:
- Linux VPS'si: Docker'ı kendiniz dağıtabileceğiniz ve bu makaledeki sağlamlaştırma adımlarını uygulayabileceğiniz temiz bir ortam
- Portainer VPS'si: Portainer'ın önceden yüklenmiş olduğu tek tıklama seçeneği; sunucu önyükleniyor ve siz zaten kontrol panelindesiniz
Her iki seçenek de aynı altyapı üzerinde çalışır: KVM sanallaştırma, 5,7 GHz'e kadar hızlandırılmış saat hızına sahip AMD Ryzen 9 CPU'lar, DDR5 bellek, NVMe SSD depolama, 40 Gbps'ye kadar ağ ve %99,95 çalışma süresi HDS'si ile 12 küresel lokasyonda BuyVM filtreleme yoluyla ücretsiz DDoS koruması.
Portainer'ı bir VPS'de çalıştırmaya daha derinlemesine bakmak için bunu özel bir makalede ele alıyoruz.
Docker Dağıtımları için Pratik Bir Güvenlik Kontrol Listesi
Yukarıdaki Docker güvenlik hataları çoğunlukla bir kez alınan ve bir daha asla gözden geçirilmeyen tek yapılandırma kararlarından kaynaklanmaktadır. Bu kontrol listesini mevcut bir kuruluma göre çalıştırmak bu boşlukları yakalar. Bir dağıtım kılavuzu olarak değil, bir denetim olarak çalışır.
Bu Docker güvenliği en iyi uygulamaları, Docker kapsayıcılarının yukarıda açıklanan en yaygın yapılandırma hatalarına karşı nasıl korunacağını kapsar.
Hızlı Başvuru: 9 Hatanın Tamamı
| Hata | Kategori | Tek Hat Düzeltme |
| Kök olarak çalıştırma | Yapılandırma | Eklemek KULLANICI Dockerfile'ınıza direktif |
| 0.0.0.0'a bağlı bağlantı noktaları | Yapılandırma | 127.0.0.1'e bağlanın ve ters proxy üzerinden yönlendirin |
| Ağ izolasyonu yok | Yapılandırma | Erişim ihtiyaçlarına göre hizmetleri kullanıcı tanımlı ayrı ağlara bölün. |
| Docker soketi monte edildi | Yapılandırma | Montajı çıkarın; Kapsamlı API'leri veya alternatifleri kullanın |
| Güvenilmeyen veya güncel olmayan resimler | Resim | Sabitlenmiş sürüm etiketleriyle resmi görselleri kullanın |
| Sabit kodlanmış sırlar | Resim | Kimlik bilgilerini çalışma zamanı env değişkenlerine veya bir gizli dizi yöneticisine taşıyın |
| Görüntü yeniden oluşturma programı yok | Resim | Aylık bir yeniden oluşturma temposu belirleyin; mümkün olduğunda otomatikleştirin |
| Kimliği doğrulanmamış kontrol panelleri | Erişim | Kimlik doğrulama ekleyin ve yönetim kullanıcı arayüzlerini özel ağlara taşıyın |
| Konteyner günlüğü koleksiyonu yok | Erişim | Merkezi günlük kaydını ve çalışma zamanı izlemeyi ayarlayın |
Boşlukların zaten mevcut olma ihtimalinin en yüksek olduğu yer olduğundan, öncelikle mevcut kurulumlara karşı çalıştırmanızı öneririz.
Root dışı olarak çalışan kapsayıcılar: USER yönergesi için Docker dosyalarınızı kontrol edin. Hiçbiri yoksa kapsayıcı kök olarak çalışır.
Bağlantı noktası bağlamaları localhost veya proxy ile sınırlıdır: Docker ps'yi çalıştırın ve bağlantı noktası bağlamalarını gözden geçirin. Bir 0.0.0.0:PORT girişi, hiçbir yukarı akış güvenlik grubunun, harici güvenlik duvarının veya DOCKER-USER zincir kuralının engellemediği ana bilgisayarlarda herkese açık olarak erişilebilir.
Kullanılan özel köprü ağları: Docker'ın varsayılan köprüsündeki konteynerler birbirlerine serbestçe ulaşabilir. Aynı kullanıcı tanımlı köprüdeki konteynerler birbirleriyle iletişim kurmaya devam edebilir; bu nedenle, gerçek izolasyon için hizmetleri güven sınırına göre ayrı ağlara bölün.
Docker soketi konteynerlere monte edilmemiş: Dosyaları oluştur ve bağımsız değişkenleri çalıştır seçeneğini işaretleyin. Bir birim olarak /var/run/docker.sock görünüyorsa bunun gerekli ve kasıtlı olduğunu onaylayın.
Doğrulanmış yayıncılardan sabitlenmiş sürümlere sahip temel görseller: FROM ubuntu:latest belirtilmemiş, potansiyel olarak güncel olmayan bir sürümü çeker. Belirli bir sürüme sabitleyin.
Docker dosyalarında, Dosya oluşturmada veya bağımsız değişken oluşturmada sır yoktur: Görüntü katmanı geçmişi, kapsayıcı silindikten sonra kimlik bilgilerini korur. Compose gizli dizilerini, Swarm gizli dizilerini kullanın, gizli montajlar oluşturun veya harici bir gizli dizi yöneticisini kullanın. Çalışma zamanı ortam değişkenleri sabit kodlanmış değerlerden daha iyidir ancak yine de inceleme çıktısında ve günlüklerinde görünür.
Görüntü yeniden oluşturma planı tanımlandı: Eski görüntüler güvenlik açıklarını biriktirir. Aylık yeniden oluşturma temposu, çoğu kurulum için pozlama aralığının yönetilebilir olmasını sağlar.
Kimlik doğrulamanın arkasındaki yönetim arayüzleri: Kimlik doğrulaması olmayan genel IP'deki herhangi bir kontrol paneli açık bir giriş noktasıdır. Mümkün olduğunda özel ağ yerleşimi tercih edilir.
Toplanan konteyner günlükleri: Günlük hattı olmadan olay tespiti, görünür sistem etkisine bağlıdır. Bu harekete geçmek için geç bir sinyal.
Çözüm
Docker'ın varsayılan yapılandırması güvenlik için değil kolaylık sağlamak için oluşturulmuştur. Bu makalede ele alınan hataların çoğu, karmaşık saldırılardan değil, ilk dağıtımdan sonra hiçbir zaman değiştirilmeyen ayarlara dayanmaktadır.
Düzeltmeler çoğunlukla tek seferlik yapılandırma kararlarıdır: USER yönergesi, bağlantı noktası bağlama değişikliği, özel ağ, yeniden oluşturma planı. Hiçbiri çoğu kurulum için yeni araçlar gerektirmez.
Konteyner konfigürasyonunu doğru yapmak ilk görevdir. Üzerinde çalıştığı altyapı ise ikincisidir. Her ikisi de önemlidir ve hiçbiri diğerinin yerini tutmaz.
