‫Sıradaki.
‫Bu büyük bir şey.
‫Eğer kaçınabiliyorsanız uygulamalarınızı konteyner içinde root olarak
‫çalıştırmayın.
‫Bunu çok hızlı bir şekilde, küçük bir demo üzerinde
‫yaparsam.
‫Tamam. Docker'ı çalıştırıyorum, en azından
‫çalıştırmalıyım. Tamam.
‫Ve eğer sadece koşarsam.
‫Eğer sadece Nginx'i çalıştırırsam, doğru,
‫ve bu konteyner üzerinde bir docker top yaparsam.
‫Burada ne görüyoruz?
‫Konteynerin içinde, Nginx root olarak bir süreç başlattı
‫ve ardından root olmayan bir kullanıcı olarak yeni
‫bir süreç oluşturdu.
‫Kullanıcının nasıl 101 olduğunu görün.
‫Bu MySQL, Postgres, Nginx gibi birçok daemon tabanlı
‫programda yaygındır.
‫Programlama dili olmayan birçoğu bunu otomatik olarak
‫yapacaktır. Yani, bu güvenli.
‫Bunun yaptığı şey, Nginx'in işin çoğunu yapmak
‫için root olarak çalışmayan işçi süreçlerini
‫ortaya çıkarmasına izin vermektir.
‫Yani, root olarak çalışan bir ana süreçleri var, ancak
‫bağlantıları kabul eden ve işin çoğunu yapan
‫bu değil. Bunların çoğu
‫bu işçi süreçlerinde. Normal bir kullanıcı olarak çalışırlar,
‫bu da Nginx'te bir güvenlik açığı varsa, gelen bağlantılar geldiğinde
‫ve birisi Nginx HTTP protokolünden yararlanmaya
‫çalıştığında, bu kullanıcıya kilitleneceği veya hapsedileceği
‫anlamına gelir...
‫Burada
‫ciddi bir güvenlik açığı olmadığı sürece çoğu zaman.
‫Burada, ve sonra yapabilecekleri sınırlıdır,
‫doğru. Bu süreci bir şekilde devralsalar
‫bile, kullanıcı olarak hala sınırlıdırlar.
‫Yani, sorun yok.
‫Bu hala konteyner içinde gerçek kök
‫olarak çalışmıyor. Gerçekten bahsettiğim şey, bir
‫Python uygulaması veya bir Node
‫uygulaması ya da bunun gibi bir programlama
‫dili çalıştırırsanız, bu varsayılan olarak root'a atanan bir şey
‫olacaktır çünkü konteynerdeki programlama dili
‫programınızın nasıl çalıştığını bilmez.
‫Ne yapmasını istediğinizi bilmiyor.
‫Yani, varsayılan olarak root yapacaktır ve bu daha
‫çok uygulama uyumluluğu ile ilgilidir.
‫Bunun varsayılan olarak güvenli olmasını istediğimizi söyleyebiliriz,
‫ancak Docker tüm bu resmi konteynerlerin programlama dilleri için gerçekten
‫kök olarak çalışmasını seçti.
‫Gidip kontrol edelim.
‫Oops. O değil.
‫Firefox.
‫Diyelim ki Hub'a gidiyoruz.
‫Sadece Node yapalım.
‫Bu durum çoğu dilde yaygındır.
‫Örnek olarak sadece Node'u seçeceğim.
‫Node'un içinde, buradaki
‫Docker dosyalarından birine girersem.
‫Sonra kullanıcıyı arıyorum.
‫Aslında bir şey bulamadığımı fark edeceksiniz.
‫Sadece bu kullanıcı buraya ekliyor.
‫Bunu yaptığını fark edeceksiniz, değil mi?
‫Teknik olarak Node adında bir grup ve Node adında
‫bir kullanıcı ekliyor.
‫Bu dosyanın geri kalanını araştırırsanız, U S E R dörtlüğüyle
‫o kullanıcıya asla değişmediğini fark edersiniz,
‫doğru.
‫Kullanıcı düğümünü orada bir yerde bir satır olarak görmelisiniz.
‫Bunu yapmazlar çünkü bu sizin işiniz.
‫Peki, alt seviye Docker dosyanızda
‫ne yapmalısınız? Dolayısıyla, programlama dilleri
‫için bu resmi imajlardan oluşturduğunuz herhangi
‫bir Docker dosyasında, sizin için oluşturdukları kullanıcılardan
‫yararlanmanız gerekir. Bu kullanıcıları oluşturmuyorlarsa, aynı şekilde kendiniz
‫de bir kullanıcı oluşturabilirsiniz. Bu küçük iki satırlık şeyi çalabilir
‫ve kullanıcı ne olmasını istiyorsa ona dönüştürebilirsiniz.
‫Python
‫içinse, sadece Python kullanıcısı diyebilirsiniz, her neyse.
‫Eğer bunu yapıyorsanız, çalıştırdığınız uygulamalar
‫konteynerde root olarak çalışmayacaktır.
‫Varsayılan
‫olarak, herhangi bir standart Node uygulamasını çalıştırırsanız, bir kapsayıcıda root kullanıcısını
‫kullanacaktır.
‫Bu neden bu kadar önemli?
‫İki şey var.
‫Birincisi, eğer birisi uygulamanızı kırabilir
‫ve uygulamanıza girebilir ve dosya sistemine erişim
‫sağlayabilirse, eğer... eğer bu uygulama root ise, o zaman
‫konteynerde istedikleri her şeyi yapabilirler,
‫değil mi? Dosya sistemine
‫dosya yazabilirler. Bu konteynere istedikleri zaman çalışabilecek
‫daha fazla program yükleyebilirler.
‫Bu yüzden, bunu yapmalarını gerçekten istemiyoruz.
‫Çok sınırlı olmalarını tercih ederiz.
‫Yani, uygulamalarınız destekliyorsa,
‫bunu yapın. Temel olarak kullanıcının müsait olduğundan
‫emin olursunuz.
‫O zaman şurada DockerCon'dan bir örnek var.
‫DockerCon'da Node üzerine bir konuşma yaptım. js ve konulardan biri
‫de kullanıcı üzerineydi.
‫Bakalım bulabilecek miyim?
‫Ne yaptığımı gördün mü? Oldukça basit bir dosya.
‫Bunu bağlayıp koyacağım.
‫Bu Docker dosyasında.
‫Yani, bu Docker dosyasında...
‫Bir kullanıcı oluşturmadım çünkü Node görüntüsü
‫zaten benim için oluşturdu. Sadece kullanıcı düğümüne geçiyorum.
‫Sonra bu iki satırla paketlerimi yüklüyorum ve daha sonra
‫çalıştıracağım.
‫Dosyalarımın artık programımın çalışacağı kullanıcı
‫ile aynı kullanıcı olduğundan emin olmak için kopyalama komutlarımda chown seçeneğini
‫kullanmaya başlamam gerektiğini fark edeceksiniz.
‫Aksi
‫takdirde sorunlar çıkabilir, değil mi? Benim başvurum muhtemelen... Dosyaları
‫okuyamazsa, çalıştıramaz, değil mi?
‫Bu yüzden, bu izinleri değiştirmem gerekiyor.
‫Bunu kopyalama komutunda tek bir satırla yapabilirim.
‫Ayrıca burada dizini oluşturduğumu ve chowning yaptığımı
‫da göreceksiniz, böylece uygulama her kopyalandığında,
‫yazabilmesi için izinlerin orada olduğundan
‫emin olmak istiyorum.
‫Çünkü bu kullanıcıyı değiştirdiğim anda, bu kopyalama komutu veya
‫özellikle bu çalıştırma komutu o kullanıcı olarak çalışacaktır.
‫Eğer
‫dizinlere yazma izni yoksa, o zaman da başarısız olacaktır.
‫Docker'ın bunu sizin için yapmamasının nedeni, işlerinizin
‫muhtemelen bozulacağını bilmeleridir.
‫Dolayısıyla, bu ekstra adımları atmanız gerekir.
‫Ama o kadar da zor değil. Gerçekten değil.
‫Muhtemelen tüm bu testleri bir günde yapabilirsiniz
‫ve daha sonra sistemlerinizi tam CI ve sunucularınızda
‫tam testten geçirmek isteyeceksiniz çünkü bazen PHP bu konuda
‫kötü olanlardan biridir.
‫PHP bir sürü günlük dosyası çalıştırmayı ve diske bir sürü
‫yazma işlemi yapmayı sever.
‫Gerçekten, kullanıcı yüklemelerine izin veren her şey
‫diske yazacaktır. Dolayısıyla, bu izinlerin doğru
‫olduğundan emin olmalısınız, böylece insanlar dosya yazarken, diyelim ki bir WordPress
‫blogu çalıştırıyorlar.
‫Bu WordPress blogu, kullanıcılar bloglarına resim
‫yüklediğinde diske yazacaktır.
‫Bu izinlerin işe yarayacağından emin olmak istersiniz.
‫Bu yüzden, kesinlikle bazı testler yapmanız gerekecek.
‫Bunu yaptıktan sonra, artık uygulamanız root olarak
‫çalışmayacaktır. Dolayısıyla, konteynerde tam
‫kontrole sahip olamaz. Bunu yapmak istemenizin
‫diğer bir nedeni de, Linux'ta veya Docker'da
‫bir güvenlik açığı varsa, ki bu nadirdir, o zaman
‫bu konteynerden çıkma olasılıkları daha
‫azdır. Bu sadece bir kez oldu,
‫çok iyi biliyorum ve aslında burada biraz
‫belgeledim.
‫Pis inek. Dirty COW, Linux'ta
‫bir konteynırdan çıkmanıza izin veren bir
‫güvenlik açığıydı,
‫değil mi? Kullanıcınızın burada değiştirilmesi,
‫sorunun tamamını
‫çözmez, ancak kesinlikle bu soruna
‫zarar vermez.
‫Diğer güvenlik açıklarına karşı muhtemelen koruma sağlayacaktır.
‫Ancak bu en iyi uygulamadır.
‫Bence bir güvenlik ekibiniz varsa, işleri root
‫olarak yürütmemeniz konusunda ısrarcı olacaklardır.
‫Yani, bunu yaparsınız.