‫Selanjutnya.
‫Ini yang besar.
‫Jangan menjalankan aplikasi Anda sebagai root di wadah jika Anda
‫bisa menghindarinya.
‫Jika saya melakukan ini sangat cepat, pada demo kecil
‫di sini.
‫Baiklah. Saya memiliki Docker berjalan, setidaknya
‫saya harus. Baiklah.
‫Dan jika saya hanya menjalankan ...
‫Jika saya menjalankan Nginx, benar, dan saya membuat
‫buruh pelabuhan di wadah
‫itu.
‫Apa yang kita lihat di sini?
‫Di dalam wadah, Nginx memulai proses di
‫root, dan kemudian menciptakan proses baru
‫sebagai pengguna non root.
‫Lihat bagaimana pengguna itu adalah 101.
‫Ini umum dari banyak program berbasis daemon seperti
‫MySQL, Postgres, Nginx.
‫Banyak dari mereka yang bukan bahasa pemrograman akan secara
‫otomatis melakukan ini. Jadi, ini aman.
‫Apa yang dilakukan adalah ini memungkinkan Nginx memunculkan
‫proses pekerja yang tidak berjalan sebagai root
‫untuk melakukan sebagian besar pekerjaan.
‫Jadi, mereka memiliki satu proses master yang berjalan sebagai root,
‫tetapi bukan itu yang menerima koneksi dan melakukan sebagian
‫besar pekerjaan. Sebagian besar
‫dari itu dalam proses pekerja ini. Mereka berjalan sebagai pengguna
‫normal, yang berarti jika ada kerentanan di Nginx, kemungkinannya
‫adalah ketika koneksi masuk masuk
‫dan seseorang mencoba untuk mengeksploitasi protokol HTTP Nginx,
‫itu akan dikunci, atau dipenjara, ke pengguna ini di
‫.. . sebagian besar waktu kecuali
‫ada kerentanan serius yang ada di sini.
‫Di sini, dan kemudian mereka terbatas pada apa yang bisa
‫mereka lakukan, benar. Bahkan jika mereka mengambil
‫alih proses itu, mereka masih terbatas sebagai pengguna.
‫Jadi, ini tidak masalah.
‫Ini masih belum berjalan sebagai root asli
‫di dalam wadah. Apa yang sebenarnya saya bicarakan
‫adalah jika Anda menjalankan
‫aplikasi Python, atau aplikasi Node, atau
‫sesuatu seperti itu di mana itu adalah bahasa pemrograman, maka
‫itu akan menjadi sesuatu yang default untuk
‫di-root karena bahasa pemrograman dalam wadah tidak t tahu cara
‫kerja program Anda. Tidak tahu apa yang ingin Anda lakukan.
‫Jadi, ini akan melakukan root secara default, dan
‫itu lebih lanjut tentang kompatibilitas aplikasi.
‫Kami mungkin mengatakan bahwa kami ingin ini aman
‫secara default, tetapi Docker memilih agar semua kontainer resmi ini benar-benar
‫berjalan sebagai root untuk bahasa pemrograman.
‫Mari kita periksa itu.
‫Ups. Bukan yang itu.
‫Firefox.
‫Jadi jika kita pergi, katakanlah, ke Hub.
‫Mari kita lakukan Node.
‫Ini biasa terjadi di sebagian besar bahasa.
‫Saya hanya akan memilih Node sebagai contoh.
‫Di dalam Node,
‫jika saya masuk ke salah satu Dockerfiles di sini.
‫Lalu saya mencari pengguna.
‫Anda akan melihat bahwa saya sebenarnya tidak menemukan apa pun.
‫Hanya pengguna ini yang menambahkan di sini.
‫Anda akan melihat bahwa ia melakukan ini, benar.
‫Secara teknis menambahkan grup yang disebut Node dan itu
‫menambahkan pengguna yang disebut Node.
‫Jika Anda mencari sisa file ini, Anda menyadari bahwa itu tidak pernah
‫berubah untuk pengguna itu dengan bait U S E
‫R, benar.
‫Anda harus melihat simpul pengguna di sana di suatu tempat sebagai garis.
‫Mereka tidak melakukan itu karena itu pekerjaan Anda.
‫Jadi, apa yang harus Anda lakukan di Dockerfile
‫tingkat bawah Anda. Jadi, Dockerfile apa
‫pun yang Anda buat dari gambar resmi
‫ini untuk bahasa pemrograman, Anda harus mengambil keuntungan dari pengguna
‫yang mereka buat untuk Anda. Jika mereka tidak menciptakan pengguna itu, Anda dapat membuatnya
‫sendiri dengan cara yang sama. Anda bisa mencuri
‫benda dua baris kecil ini dan mengubahnya menjadi apa
‫pun yang Anda inginkan. Jika itu untuk Python,
‫Anda bisa menyebutnya pengguna Python, apa pun.
‫Jika Anda melakukan itu, maka aplikasi yang
‫Anda jalankan tidak akan berjalan sebagai root di
‫wadah. Secara default,
‫jika Anda menjalankan aplikasi Node standar saja, ia akan menggunakan pengguna
‫root dalam sebuah wadah.
‫Mengapa ini sangat penting?
‫Nah, dua hal.
‫Pertama, jika seseorang dapat menerobos aplikasi Anda dan
‫meretas aplikasi Anda dan mendapatkan akses ke sistem
‫file, jika mereka ... jika aplikasi itu adalah root, maka
‫dalam wadah, mereka dapat melakukan apa pun yang mereka inginkan
‫dalam wadah, benar. Mereka dapat menulis
‫file ke sistem file. Mereka dapat menginstal lebih banyak program dalam
‫wadah yang dapat berjalan kapan saja mereka inginkan dalam wadah itu.
‫Jadi, kami benar-benar tidak ingin mereka melakukan itu.
‫Kami lebih suka mereka menjadi sangat terbatas.
‫Jadi, jika aplikasi Anda mendukungnya, Anda
‫tahu, lakukan ini. Anda pada dasarnya memastikan bahwa Anda
‫memiliki pengguna yang tersedia.
‫Lalu saya punya contoh dari DockerCon di sini.
‫Di DockerCon, saya berbicara tentang Node. js, dan salah
‫satu topik ada di pengguna.
‫Biarkan saya melihat apakah saya dapat menemukannya.
‫Lihat apa yang saya lakukan di sini? Ini adalah file yang cukup sederhana.
‫Saya akan menautkan ini dan memasukkannya ke dalam.
‫Di Dockerfile ini.
‫Jadi, di Dockerfile ini saya punya ...
‫Saya tidak membuat pengguna karena gambar Node
‫sudah membuatnya untuk saya. Saya hanya mengubah ke simpul pengguna.
‫Lalu saya menginstal paket saya dengan dua baris ini, dan kemudian,
‫saya akan menjalankannya.
‫Anda akan melihat bahwa saya harus
‫mulai menggunakan opsi chown dalam perintah salin saya untuk memastikan bahwa file
‫saya sekarang adalah pengguna yang sama dengan pengguna yang akan dijalankan
‫oleh program saya. Kalau tidak, mungkin ada masalah,
‫benar. Aplikasi saya mungkin ... jika
‫tidak bisa membaca file, maka tidak bisa menjalankannya, benar.
‫Jadi, saya perlu perubahan izin itu.
‫Saya dapat melakukannya dengan satu liner pada perintah salin.
‫Anda juga akan melihat di sini bahwa saya membuat
‫direktori dan mengunyahnya juga sehingga setiap kali aplikasi disalin,
‫saya hanya ingin memastikan, lebih yakin, bahwa izin
‫ada di sana sehingga bisa menulis.
‫Karena begitu saya mengubah pengguna ini, maka perintah
‫salin ini, atau secara khusus perintah jalankan ini, akan berjalan sebagai
‫pengguna itu. Jika tidak memiliki izin
‫untuk menulis ke direktori, maka itu juga akan gagal.
‫Jadi, alasan Docker tidak melakukan ini untuk Anda adalah karena mereka
‫tahu bahwa barang-barang Anda mungkin akan rusak.
‫Jadi, Anda perlu mengambil langkah-langkah tambahan ini.
‫Tapi, itu tidak sulit. Benar-benar tidak.
‫Anda mungkin dapat melakukan semua pengujian ini dalam sehari, dan
‫kemudian Anda akan ingin menjalankan sistem Anda melalui CI penuh
‫dan pengujian penuh pada server Anda karena kadang-kadang, dan PHP adalah salah
‫satu yang buruk dalam hal ini.
‫PHP suka menjalankan banyak file log dan melakukan
‫banyak penulisan ke disk.
‫Sungguh, apa pun yang memungkinkan unggahan pengguna akan menulis
‫ke disk. Jadi, Anda harus
‫memastikan izin itu benar sehingga ketika orang menulis file, seperti
‫katakanlah mereka menjalankan blog WordPress.
‫Blog WordPress itu akan ditulis ke disk ketika pengguna
‫mengunggah gambar ke blog mereka.
‫Anda ingin memastikan izin itu akan berfungsi.
‫Jadi, Anda harus melakukan beberapa pengujian.
‫Setelah Anda selesai melakukannya, sekarang aplikasi Anda tidak
‫akan berjalan sebagai root. Jadi, itu tidak dapat memiliki
‫kontrol penuh dalam wadah. Alasan lain yang
‫ingin Anda lakukan adalah jika ada kerentanan di
‫Linux, yang jarang, atau Docker, yang juga sangat jarang,
‫maka ada kemungkinan lebih kecil bahwa mereka akan
‫keluar dari wadah ini. Itu hanya terjadi, yah, satu
‫kali yang saya sangat sadari, dan saya benar-benar mendokumentasikannya
‫di sini.
‫SAPI Kotor. COW kotor adalah
‫kerentanan di Linux yang memungkinkan Anda untuk
‫keluar
‫dari wadah, kan. Perubahan pengguna Anda di sini,
‫tidak akan serta
‫merta menyelesaikan seluruh masalah, tetapi tentu
‫saja itu tidak melukai masalah itu.
‫Kerentanan lain, itu mungkin akan melindungi.
‫Tapi ini praktik terbaik.
‫Saya pikir jika Anda memiliki tim keamanan,
‫mereka akan bersikeras bahwa Anda tidak menjalankan hal-hal sebagai root.
‫Jadi, Anda akan
‫melakukannya.