İmaj katmanları ve saldırı yüzeyi

Konteyner sızıntısı haberlerinin çoğunda karmaşık bir açık aramana gerek kalmaz. İmajın içinde unutulmuş bir belirteç, kök olarak çalışan bir süreç ya da gereğinden büyük bir taban imaj vardır. Bu derste imajın nasıl kurulduğunu, katmanların neden değişmez olduğunu ve saldırı yüzeyini imajın içeriğinin nasıl belirlediğini görürsün.

Önce konteyner ile sanal makineyi ayırırsın. Sonra bir imajın katmanlarını komut satırından okur, silinen bir dosyanın neden alt katmanda kaldığını çıkarırsın. En sonda taban seçimini ve malzeme listesini bir güvenlik kararı olarak ele alırsın.

Konteyner yeni bir sanal makine türü değildir. Sanal makine kendi çekirdeğini taşır ve donanımı taklit eden bir katmanın üstünde koşar. Konteyner ise ana makinenin çekirdeğini paylaşan tek bir süreçtir. Yalıtımı ad alanları (namespace) ve kontrol grupları (cgroup) kurar.

Ad alanları sürecin gördüğü kaynakları ayırır: kendi süreç listesi, kendi ağ arayüzü, kendi bağlama noktaları. Kontrol grupları ise sürecin ne kadar bellek ve işlemci kullanacağını sınırlar. Bu yapı konteyneri hızlı ve hafif yapar, ama yalıtımın sınırını da çizer.

Ortak çekirdek, risk profilini doğrudan belirler. Sanal makinede iki sistem farklı çekirdekler üstünde koşar; birinde bulunan çekirdek açığı ötekine geçmez. Konteynerde ise çekirdek tektir. Konteyner içinde tetiklenen bir çekirdek açığı ana makineyi de vurur, çünkü aynı çekirdektir.

Yalıtım donanım sınırı değil, bir yapılandırma sınırıdır. Bu sınır iyi kurulduğunda güçlüdür; gevşek bırakıldığında bir bayrak kadar incedir. Bu yüzden konteyner güvenliği hem imajın içeriğine hem çalışma zamanı ayarlarına bakar.

İmaj, o sürecin dosya sistemidir. Katman katman kurulur: taban imajın üstüne paket kurulumu, onun üstüne uygulama dosyaları biner. Her katman bir öncekinin farkını tutar. Dockerfile'daki her satır katman açmaz.

Yalnız dosya sistemini değiştiren yönergeler yeni katman ekler. FROM taban katmanlarını getirir, RUN ve COPY üstüne yeni katman kurar. CMD ise üstveridir; hangi komutun çalışacağını söyler ama katman oluşturmaz. Katmanların ayrı ayrı tutulması hem önbelleği hem paylaşımı mümkün kılar: aynı taban katmanı birçok imaj arasında ortak durur.

FROM python:3.12-slim        # taban katmanları
RUN apt-get update && apt-get install -y curl   # yeni katman
COPY . /app                  # yeni katman
RUN rm /app/ayarlar.gizli    # silme işareti, ama dosya alt katmanda durur
CMD ["python", "/app/main.py"]

Katmanların ikinci etkisi önbelleğe dayanır. Sık değişen dosyaları Dockerfile'ın sonuna koyarsan derleme hızlanır, çünkü değişmeyen üst katmanlar önbellekten gelir. Bağımlılık kurulumunu uygulama kodundan önce yazmak hem hızı hem yeniden üretilebilirliği artırır. Bu düzen güvenlik açısından da işe yarar.

Taban ve bağımlılık katmanları sabit kaldıkça, onları bir kez tarayıp imzalar, yalnız değişen üst katmanı yeniden denetlersin. Katman sayısını azaltmak için ilgili komutları tek bir RUN satırında birleştirirsin; böylece geçici dosyalar ayrı bir katmanda kalıp imajı şişirmez.

FROM alpine:3.20
RUN apk add --no-cache curl
COPY app /app
RUN chmod +x /app
CMD ["/app"]

Saldırı yüzeyi doğrudan imajın içeriğiyle ölçülür. İçinde kabuk, paket yöneticisi, derleyici ve ağ araçları olan bir imajda kod çalıştıran kişi hazır bir alet setine oturur.

Yeni indirmesine gerek kalmaz; ana makineye çıkış için ya da yayılma için ihtiyaç duyduğu araçları imaj ona vermiştir. Bu yüzden taban seçimi bir güvenlik kararıdır, kolaylık kararı değil. Bu ilişki sayılarla da görülür.

Tam bir dağıtım tabanıyla derlenen bir uygulamada tarama yüzlerce açık raporlarken, aynı uygulamanın distroless tabanlı sürümünde bu sayı çok azalır. Açıkların çoğu uygulamanın hiç kullanmadığı paketlerden gelir: bir kabuk, bir paket yöneticisi ya da eski bir kütüphane. Bunları imajdan çıkarmak hem tarama listesini hem saldırganın araç setini birden küçültür.

Tam bir dağıtım imajı yüzlerce paket taşır. slim türevleri bu paketlerin çoğunu atar. distroless taban yalnız çalışma ortamını ve kütüphaneleri taşır; kabuk bile yoktur, bugünkü türevleri Debian 13 üstüne kuruludur ve dil başına ayrı imaj sunar. scratch ise tek bir statik ikiliyle yetinir, içinde işletim sistemi katmanı bile bulunmaz.

İmaj küçüldükçe hem açık sayısı hem saldırganın eline geçen araç sayısı düşer. Sıralama nettir: tam dağıtım en geniş yüzeyi, scratch en darını verir.

İmaj yönetimini kurumsal ölçekte de düşünmek gerekir. Ekiplerin kendi taban imajlarını serbestçe seçmesi yerine, onaylı bir taban kataloğu tutulur. Katalogdaki imajlar düzenli yamalanır, taranır ve imzalanır. Ekipler kendi uygulamalarını o tabanın üstüne koyar.

Bir kütüphanede kritik açık duyurulduğunda tek bir taban güncellenir ve tüm uygulamalar bir sonraki derlemede düzelir. Katalog dışı bir taban gerekiyorsa ekip gerekçesini yazar ve güvenlik ekibi onu gözden geçirir. Böylece kurumdaki taban sayısı az kalır ve her biri bilinen bir sahibe bağlanır.

Katmanların değişmez olması önemli bir sonuç doğurur. Bir dosyayı sonraki katmanda silersen, üst katmana bir silme işareti yazılır ama alttaki içerik yerinde kalır. Bu işaretin adı whiteout'tur.

Dosya için üst katmana, adının başına .wh. eklenmiş boş bir giriş yazılır; bir dizinin tüm içeriğini gizlemek içinse .wh..wh..opq girişi kullanılır.

Kural nettir: whiteout yalnız alttaki katmanlara uygulanır, aynı katmandaki dosyayı silmez. Katmanın kendisi bir tar arşividir. Yani sildiğini sandığın dosya, onu ekleyen katmanın arşivinde olduğu gibi durur ve çıkarılıp okunabilir.

Bu davranış saldırı ile savunma arasındaki farkı da açıklar. Bir sırrı imaja ekleyip sonraki satırda silmek onu güvene almaz; belirteç, parola ya da özel anahtar onu ekleyen katmanda kalır. Doğru çözüm sırrı hiç katmana yazmamaktır.

Derleme sırasında sır gerekiyorsa bağlı bir sır olarak verilir, imaja gömülmez. Yeni devraldığın bir imajda bu yüzden ilk iş geçmişine bakmaktır. docker history her katmanı ve onu oluşturan komutu yazar.

Uzun komutlar varsayılan çıktıda kısaltılır, bu yüzden --no-trunc bayrağıyla tam metni açarsın. Aşağıdaki çıktı katmanları en yeniden en eskiye sıralar. İçinde derleme zamanı verilmiş bir değişken vardır ve bu değişken düz metin durur.

$ docker history --no-trunc uygulama:1.4
IMAGE      CREATED BY                                    SIZE
<missing>  COPY . /app                                   12MB
<missing>  RUN pip install -r gereksinim.txt             68MB
<missing>  ARG PIP_TOKEN=glpat-AbCdEf123456              0B
<missing>  FROM python:3.12-slim                         45MB

Çıktıyı satır satır oku. En üstteki COPY satırı uygulama dosyalarını taşıyan son katmandır. Bir altındaki RUN satırı bağımlılıkları kuran katmandır ve boyutun çoğu buradadır. Onun altındaki ARG satırı bir belirteci derleme değişkeni olarak vermiş; katman açmadığı için boyutu sıfırdır, ama değer imaj geçmişinde durur.

En alttaki FROM taban imajı gösterir. Bu üç bakış imajın olgunluk düzeyini birkaç dakikada verir: içinde sır var mı, boyutu şişkin mi, tabanı güncel mi. Katman içeriğini dosya dosya görmek istersen dive aracı her katmanı gezer, eklenen ve silinen dosyaları gösterir, bir de verimlilik puanı ile boşa giden alanı hesaplar. CI=true dive uygulama:1.4 komutu bu kontrolü boru hattına takar ve verimsiz imajda hattı durdurur.

İmajın içeriğini belgelemek için malzeme listesi üretilir. Bu listenin genel adı SBOM'dur ve imajdaki her paketi, sürümüyle birlikte yazar. syft aracı bir imajı okuyup bu listeyi standart biçimlerde çıkarır: syft uygulama:1.4 -o cyclonedx-json ya da -o spdx-json.

Yeni bir açık duyurulduğunda tüm imajları baştan taramak yerine bu listeleri sorgularsın; hangi imajın etkilendiğini dakikalar içinde çıkarırsın. Aynı listeyi bir tarayıcıya da verirsin: grype sbom:./sbom.json listeyi bilinen açıklarla karşılaştırır.

Malzeme listesi tedarik zinciri denetiminin de girdisidir. Müşteri kurumlar bunu istemeye başladı, çünkü kendi risk haritalarını senin bileşenlerin üstüne kuruyorlar. Denetimin ikinci ayağı yeniden üretilebilirliktir.

Taban imajı etiket yerine sha256 özet değeriyle sabitlersen, aynı Dockerfile altı ay sonra aynı imajı üretir. latest etiketi bu güvenceyi ortadan kaldırır, çünkü zamanla başka bir içeriğe işaret eder. Etiketleme düzeni de izlemeyi etkiler: sürüm numarası, derleme numarası ve kaynak commit kimliği etiketlerde göründüğünde, üretimdeki bir konteynerden kaynak koda kadar geri gidersin.

İmajları izlemek için basit bir envanter yeter. Hangi kayıt defterinde hangi imaj var, en son ne zaman üretildi ve hangi ortamda çalışıyor? Aylardır yeniden üretilmemiş bir imaj, yamasız bir imajdır. Envanteri boru hattından beslemek, elle tutulan bir tablodan daha güvenilir sonuç verir.

Denetimde katman incelemesi bir alışkanlığa dönüşür. Yeni devraldığın bir imajda önce geçmişine, sonra boyutuna, sonra içindeki kabuk varlığına bakarsın. Bu üç bakış imajı kimin, ne zaman ve hangi özenle ürettiğini birkaç dakikada anlatır. Sahibi ve veri sınıfı etiketi olmayan bir imaj, ilk gözden geçirmede listeye düşer ve gözden geçirilene kadar üretime çıkmaz.