Docker’ın Çalıştığı Host Üzerinde Yapılması Gereken Sıkılaştırmalar

docker container nedir

Docker’ın Çalıştığı Host Üzerinde Yapılması Gereken Sıkılaştırmalar ve Docker’ı güncellemek; Docker güncellemelerini güncel tutarak, Docker yazılımındaki güvenlik açıkları kapatılabilir. Bir saldırgan erişim elde etmeye veya yetki yükseltmeye çalışırken bilinen güvenlik açıklarından yararlanabilir. Düzenli Docker güncellemelerini yüklememek sizi savunmasız Docker yazılımı ile çalıştırmanıza neden olabilir. Yetki yükseltmeye, yetkisiz erişime veya diğer güvenlik ihlallerine yol açabilir. Yeni sürümleri takip edin ve gerektiğinde güncelleyin.

Önlem: Aşağıdaki komutu çalıştırarak ve Docker sürümünün güncel olduğundan emin olun.

$ docker version

Docker processine sadece yetkili kullanıcıların erişmesi

Docker, konteynerlerin erişim haklarını sınırlamada ana bilgisayar(host) ve konteyner arasında dizin paylaşmanıza olanak tanır. Bu bir konteyneri /(kök) dizine bağlayarak başlatabileceğiniz anlamına gelmektedir. Konteyner daha sonra ana dosya sisteminizi herhangi bir kısıtlama olmaksızın değiştirebilir. Basit bir ifadeyle, sadece docker grubunun bir üyesi ayrıcalıklara haklara sahip olabildiği gibi daha sonra ana makinede(host) üzerinde kök dizini bir konteynere bağlayabileceği anlamına gelmektedir. Bu durumu kısıtlamak gerekmektedir.

Önlem: Docker ana bilgisayarında aşağıdaki komutu çalıştırın ve yalnızca güvenilen kullanıcıların docker grubunun üyeleri olduğundan emin olun.

$ getent group docker

Docker için Auditing Konfigurasyonunun Yapılması

Düzenli Linux dosya sisteminizi ve sistem çağrılarınızı denetlemenin(Auditing) yanı sıra Docker daemonunu denetlemek önemlidir. Docker daemon, root ayrıcalıklarıyla çalışır. Bu nedenle faaliyetlerini ve kullanımını denetlemek gereklidir.

Önlem: Docker daemon için bir Auditing kuralı olduğunu doğrulayın. Örneğin, aşağıdaki komutu çalıştırın:

$ auditctl -l | grep /usr/bin/docker

Bu kural size Docker ile alakalı bir auditing kuralı olup/olmadığını listeleyecektir. Docker daemon’u için kural yoksa; /etc/audit/audit.rules dosyası içerisine:

-w /usr/bin/docker -k docker

Yazdıktan sonra, Auditd servisini yeniden başlatabilirsiniz. Auditing oldukça büyük log dosyaları oluşturur. Periyodik olarak döndürüp arşivlediğinden emin olun. Ayrıca, kök dosya sistemini doldurmamak için ayrı bir auditing bölümü oluşturduğunuza dikkat edin.

Docker İçin Oluşturulması Gereken Auditing Kuralları:

-w /usr/bin/docker -k docker
-w /var/lib/docker -k docker
-w /etc/docker -k docker
-w /usr/lib/systemd/system/docker.service -k docker
-w /usr/lib/systemd/system/docker.socket -k docker
-w /etc/default/docker -k docker
-w /etc/docker/daemon.json -k docker
-w /usr/bin/docker-containerd -k docker
-w /usr/bin/docker-runc -k docker

Docker Daemon Sıkılaştırmaları

Konteynerler Arası Gereksiz İletişimi Engelleme

Varsayılan olarak, varsayılan ağ köprüsünde(network bridge) aynı ana bilgisayardaki(host) tüm konteynerler arasında sınırsız ağ trafiğini kullanabilmektedir. Böylelikle, her bir konteyner, aynı ana bilgisayar üzerindeki konteyner ağı boyunca tüm paketleri okuma potansiyeline sahiptir. Bu istenmeyen bir bilgi ifşasına yol açabilir. Bu nedenle, konteyner iletişimini network bridge üzerinde kısıtlayın.

Önlem: Aşağıdaki komutu çalıştırın ve varsayılan ağ köprüsünün(network bridge) konteyner içi iletişimi kısıtlayacak şekilde yapılandırıldığını doğrulayın.

$ docker network ls –quiet | xargs docker network inspect –format ‘{{ .Name }}: {{ .Options }}’

“Com.docker.network.bridge.enable_icc:false” şeklinde varsayılan olarak dönüş yapacaktır.

Bu durumu kısıtlamak için:

$ dockerd –icc=false

Kullanabilirsiniz, alternatif olarak Docker dokümanlarını takip edip özel bir ağ oluşturabilir ve yalnızca bu özel ağa iletişim kurması gereken konteynerleri birleştirebilirsiniz. –icc parametresi yalnızca varsayılan docker köprüsü için geçerlidir.

Loglama Seviyesinin “Info” Olarak Seçilmesi

Uygun bir log seviyesi ayarlamak, daha sonra gözden geçirmek isteyeceğiniz olayları kaydetmek için Docker daemonunu yapılandırır. Bir temel logo seviyesi ve üstü, hata ayıklama(debug) logları dışındaki tüm logları yakalayacaktır. Gerekli olana kadar, Docker daemon’unu debug seviyesi loglama ile çalıştırmamalısınız.

Önlem: Docker’ı info seviyesi loglama ile çalıştırdığınızdan emin olun.

$ dockerd –log-level=”info”

Docker Servisinin Iptables Kurallarını Otomatik Olarak Düzenlemesi

Iptables, Linux çekirdeğindeki IP paket filtre kurallarının tablolarını oluşturmak, sürdürmek ve denetlemek için kullanılır. Docker sunucusu, gerekli izinleri otomatik olarak konteynerler için (ağ seçeneklerinizi nasıl seçeceğinize bağlı olarak) iptables üzerinde gereken değişiklikleri yapar. Konteynerler ve dış dünya arasındaki iletişimi engelleyebilecek ağ yapılandırmasını önlemek için Docker sunucusunun iptables ayarlarında otomatik olarak değişiklik yapmasına izin verilmesi önerilir. Ek olarak bu ayar Iptables’ı her seferinde güncellemenin zorluklarından da kurtarır.

Önlem: Docker tanımlı olarak dockerd –iptables=true olarak başlamaktadır. Kontrol olarak aşağıdaki komutu kullanabilirsiniz.

$ ps -ef | grep dockerd

Güvenilmeyen Registry (kayıtların) Devre Dışı Bırakılması

Docker, özel bir kayıt defterini güvenli veya güvensiz olarak kabul etmektedir. Varsayılan olarak, kayıtlar güvenli kabul edilir. Güvenli bir kayıt birimi (registry) TLS kullanır. Kayıt defterinin CA sertifikasının bir kopyası Docket ana bilgisayarında (host) /etc/docker/certs.d// dizininde yerleştirilir.

Güvenli olmayan bir kayıt defteri(registry) geçerli kayıt sertifikasına sahip olmayan veya TLS kullanmayan bir kayıt defteridir. Production ortamında herhangi bir güvensiz kayıt(registry) kullanmamalısınız. Güvenli olmayan kayıtlar, production sisteminize olası bir bağlantı sağlanmasına sebep olabilir. Ayrıca, bir kayıt defteri güvensiz olarak işaretlendiyse, docker pull, docker push ve docker search komutları bir hata iletisine neden olmaz ve kullanıcı, potansiyel tehlike konusunda herhangi bir bildirim yapılmadan, bu kayıtlarla birlikte farketmeden süresiz olarak çalışabilir.

Önlem: Docker’ın –insecure-registry parametresi ile başlatılmadığından emin olun.

$ps -ef | grep dockerd

Örneğin, Docker’ı şu şekilde başlatmamalısınız:

$dockerd –insecure-registry 10.1.0.0/16

Aufs Dosya Sisteminin Devre Dışı Bırakılması

Aufs, dosyalama sistemi en eski dosya sistemi sürücüsüdür. Aufs sürücüsü(driver) de bazı ciddi kernel çökmelerine neden olduğu bilinmektedir. En önemlisi, aufs, en son Linux çekirdeğini kullanan birçok Linux dağıtımında desteklenen bir sürücü değildir.

Önlem:

$docker info | grep -e “^Storage Driver:\s*aufs\s*$”

Örneğin Docker’ın “dockerd –storage-driver aufs” ile başlatılmaması gerekmektedir.

Docker için TLS Authentication Konfigurasyonunun Yapılması

Docker daemonunu default(tanımlı) Unix socket dışında spesifik bir IP ve Port’u dinlenmesi sağlanabilmektedir. Docker sunucusuna IP ve port aracılığıyla erişimi kısıtlamak için TLS auhtentication (kimlik doğrulamasını) yapılandırılabilmektedir. Varsayılan olarak, Docker daemon ağa bağlı olmayan bir Unix soketine bağlanır ve kök (root) ayrıcalıklarıyla çalışır.

Varsayılan docker daemon’unu bir TCP portuna ya da başka bir Unix soketine bağlarsanız, bu port ya da sokete erişimi olan herkes Docker daemon’una ve daha sonra ana sisteme tam erişime sahip olabilir. Bu nedenle Docker daemonunu başka bir IP / port veya Unix soketine bağlamamalısınız.

Docker daemonunu bir ağ soketi üzerinden bağlamanız gerekiyorsa, Docker daemonunu Docker Swarm API’leri (kullanılıyorsa) için TLS kimlik doğrulamasını (auhtentication) yapılandırın. Bu, Docker daemon’unuzun ağ üzerindeki bağlantılarını TLS üzerinden başarıyla kimlik doğrulaması yapabilecek sınırlı sayıda istemciyle sınırlayacaktır.

$ps -ef | grep dockerd

–tlsverify
–tlscacert
–tlscert
–tlskey

Parametrelerinin aktif olduğundan emin olun. Varsayılan olarak TLS kimlik doğrulaması yapılandırılmamıştır.

Tanımlı Olan Ulimit Değerlerinin Düzenlenmesi

Ulimit, Shell için mevcut olan kaynaklar ve onun tarafından başlatılan processler üzerinde kontrol sağlar. Sistem kaynak limitlerini ayarlamak sizi fork bomb gibi birçok felaketten kurtarır. Bazen, normal kullanıcılar ve bilinen processler bile sistem kaynaklarını aşırı kullanabilir ve sistemi kullanılamaz hale getirebilir.

Docker daemon için varsayılan ulimit ayarı tüm konteyner için tek bir ulimit konfigÜrasyonu kullanır. Her bir konteyner için ulimit kurmanıza gerek kalmaz. Ancak, gerekliyse, varsayılan ulimit konfigÜrasyonu konteyner çalışırken düzenlenebilir. Bu nedenle, sistem kaynaklarını kontrol etmek için, ortamınızda gerektiği gibi varsayılan bir ulimit tanımlayın. Eğer ulimitler düzgün ayarlanmamışsa, istenen kaynak kontrolü sağlanamayabilir ve hatta sistemi kullanılamaz hale getirebilir.

Örneğin aşağıdaki gibi bir tanım yapılabilmektedir:

$ dockerd –default-ulimit nproc=1024:2048 –default-ulimit nofile=100:200

Kullanıcı Namespace’lerini Aktifleştirmek

Docker daemon’daki Linux çekirdeği user namespace desteği, Docker ana bilgisayar(host) sistemi için ek güvenlik sağlar. Bir konteynerin, ana sistem tarafından kullanılan geleneksel kullanıcı ve grup aralığının dışında olan bir dizi kullanıcı ve grup kimliğine sahip olmasını sağlar. Örneğin, kök kullanıcı konteynerin içinde beklenen yönetim ayrıcalığına sahip olacak, ancak ana bilgisayar sistemindeki ayrıcalıklı olmayan bir UID ile etkili bir şekilde eşleştirilebilecektir.

$ ps -p $(docker inspect –format='{{ .State.Pid }}’ ) -o pid,user

Yukarıdaki komut, konteynerin PID’sini bulur ve daha sonra konteyner işlemiyle ilişkili host kullanıcıları listeler. Konteyner kök olarak çalışıyorsa, bu öneri uyumlu değildir. Alternatif olarak, kullanıcıların Güvenlik Seçenekleri (Security Options) altında listelendiğinden emin olmak için docker info çalıştırabilirsiniz:

$docker info –format ‘{{ .SecurityOptions }}’

Tanımlı Cgroup Kullanımının Onaylanması

Sistem yöneticileri, genellikle, konteynerlerin çalışacağı varsayılan gruplarını tanımlar. Gruplar sistem yöneticileri tarafından açıkça tanımlanmasa bile, kapsayıcılar varsayılan olarak docker cgroup altında çalışır. Varsayılan olandan farklı bir cgroup eklemek mümkündür. Bu kullanım izlenmeli ve onaylanmalıdır. Varsayılan olandan farklı bir c grubu ekleyerek, kaynakları eşit olmayan şekilde paylaşarak ana bilgisayar(host) kaynak problemlerine neden olabilmektedir.

$ps -ef | grep dockerd

–cgroup-parent parametresinin aktif olmadığından emin olun. Varsayılan ayar yeterince iyidir ve olduğu gibi bırakılabilir. Özellikle varsayılan olmayan bir grup oluşturmak isterseniz, başlatırken docker daemonuna –cgroup-parent parametresi ile çalıştırın.

$ dockerd –cgroup-parent = / foobar

Docker Client Komutları İçin Yetkilendirme Etkinleştirilmesi

Docker’ın kullanıma hazır yetkilendirme modeli tam olarak yeterli olmamaktadır. Docker daemonuna erişim izni olan herhangi bir kullanıcı herhangi bir Docker client komutunu çalıştırabilir. Aynısı Docker’ın uzak API’sini kullanarak daemon ile iletişime geçmek isteyenler için de geçerlidir. Daha fazla erişim kontrolü gerekiyorsa, yetkilendirme eklentileri oluşturabilir ve Docker sunucu yapılandırmanıza ekleyebilirsiniz. Bir yetkilendirme eklentisi(plugin) kullanarak, Docker yöneticisi Docker uygulamasına erişimi yönetmek için ayrıntılı erişim ilkeleri yapılandırabilir.

1. Adım: Bir yetkilendirme eklentisi kurun / oluşturun.
2. Adım: Yetkilendirme politikasını istediğiniz gibi yapılandırın.
3. Adım: docker daemon programını aşağıdaki gibi başlatın:

$ dockerd –authorization-plugin =

Her bir docker komutu, özel olarak yetkilendirme eklenti mekanizmasından geçer. Bu, küçük bir performans düşüşü getirebilir.

Merkezi Ve Uzak Loglama Yapısının Yapılandırılması

Docker şimdi çeşitli loglama sürücülerini desteklemektedir. Logları depolamanın tercih edilen bir yolu, merkezi ve uzak oturumları destekleyen bir yöntemdir. Merkezileştirilmiş ve uzak loglama, tüm önemli kayıtların güvenle tutulmasını sağlar. Docker şu anda çeşitli loglama sürücülerini destekliyor. Ortamınıza en uygun olanı kullanın.

Docker info’yu çalıştırın ve Logging Driverproperty öğesinin uygun şekilde ayarlandığından emin olun.

$ docker info –format ‘{{.LoggingDriver}}’

Adım 1: Dokümanları takip ederek istenen log sürücüsünü kurun.
Adım 2: Docker daemonunu o loglama sürücüsüyle birlikte başlatın.

Örneğin,

$ dockerd –log-driver = syslog –log-opt syslog-address = tcp: //192.xxx.xxx.xxx

Live Restore Seçeneğinin Açılması

–live-restore, docker’daki daemonsuz konteynerlere tam destek sağlamaktadır. Docker’ın kapatma veya geri yükleme sırasında konteynerleri durdurmadığından ve yeniden başlatıldığında konteynerlere yeniden bağlanmasını sağlamaktadır. Docker daemonunda yer alan –live-restore parametresi, docker daemon mevcut olmadığında konteyner uygulamasının kesintiye uğramamasını sağlar. Bu aynı zamanda update veya patch sırasında downtime olmadan yapılabilmesini sağlar.

$docker info –format ‘{{ .LiveRestoreEnabled }}’

Aktifleştirmek için:

$ dockerd –live-restore

Userland Proxy’nin Kapatılması

Docker daemon, bir port her açıldığında (expose) port yönlendirme için bir userland proxy başlatır. NAT’ın mevcut olduğu yerlerde, bu servis genellikle gereksinimler için gereksizdir ve devre dışı bırakılabilir.

$ ps -ef | grep dockerd

Komutu ile –userland-proxy parametresini kontrol edebilirsiniz. Kapatmak için aşağıdaki şekilde başlatın.

$ dockerd –userland-proxy=false

Daemon Genelinde Özel Seccomp Profilinin Uygulanması

Gerekirse, özel seccomp profilinizi daemon geneli düzeyinde uygulayabilir ve Docker’ın varsayılan seccomp profili geçersiz kılınabilmektedir. Çok sayıda sistem çağrısı, her bir userland processine tutunur ve çoğu işlemin tüm ömrü boyunca kullanılmaz. Uygulamaların çoğu, tüm sistem çağrılarına ihtiyaç duymaz ve bu nedenle, daha az sayıda mevcut sistem çağrısına sahip olmakla faydalanır. Azaltılmış sistem çağrıları seti, uygulamanın kullandığını toplam çekirdek yüzeyini azaltır ve böylece uygulama güvenliğini geliştirir.

Docker’ın varsayılan seccomp profili yerine kendi özel seccomp profilinizi uygulayabilirsiniz. Alternatif olarak, Docker’in varsayılan profili ortamınız için uygunsa, bu öneriyi yok saymayı seçebilirsiniz. Aşağıdaki komutu çalıştırın ve Security Options bölümünde listelenen seccomp profilini gözden geçirin. Varsayılan ise, yani Docker’ın varsayılan seccomp profile uygulanır.

$ docker info –format ‘{{.SecurityOptions}}’

Varsayılan olarak, Docker’ın varsayılan seccomp profili uygulanır. Bu, ortamınız için iyi ise, hiçbir işlem gerekli değildir. Alternatif olarak, kendi seccomp profilinizi seçmeyi seçerseniz, daemon başlangıcında –seccomp-profile parametresini kullanın veya daemon runtime parametreleri dosyasına koyun.

$ dockerd –seccomp-profile </ path / to / seccomp / profile>

Yanlış yapılandırılmış bir seccomp profili konteyner ortamınızı bozabilir. Docker varsayılan engellenen çağrılar dikkatlice incelenmiştir. Bunlar, konteyner ortamlarındaki bazı kritik güvenlik açıklarını / sorunları ele alır. Yani, varsayılanları geçersiz kılarken çok dikkatli olmalısınız.

Konteynerlerin Yeni Ayrıcalıklar Edinmesinin Kısıtlanması

Bir process “no_new_priv” bitini kernel’da ayarlayabilir. “No_new_priv” biti, processlerin veya child processlerrin, “suid” veya “sgid” bitleri aracılığıyla herhangi bir ek ayrıcalık kazanmamasını engeller. Böylelikle birçok tehlikeli operasyon çok daha az tehlikeli hale gelmektedir çünkü binary dosyaları bozmasını engleler. Bunu daemon seviyesinde ayarlayarak tüm yeni konteynerlerin varsayılan olarak yeni ayrıcalıkların elde edilmesini kısıtlanmış olmaktadır.

Sağlamak için:

$ dockerd –no-new-privileges

Bir sonraki makalemizde, Docker Daemon Sıkılaştırmaları konusu ile karşınızda olacağız.

Yorum Yaz

E-posta hesabınız yayımlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir

*
*

5 × 1 =

Mail listemize üye olarak eğitim fırsatlarını kaçırmayın!
Eğitim ve ücretsiz etkinliklerizden haberdar olmak için e-posta listesimize üye olun!.