Katakan saja tidak untuk root (dalam wadah)

Saya selalu ditanya tentang langkah-langkah keamanan yang berbeda yang digunakan untuk mengontrol apa yang dapat dilakukan oleh proses kontainer pada suatu sistem. Sebagian besar dari ini saya bahas dalam artikel sebelumnya di Opensource.com:

• Apakah container Docker benar-benar aman?
• Membawa fitur keamanan baru ke Docker
• Keamanan buruh pelabuhan di masa mendatang

Hampir semua artikel di atas adalah tentang mengontrol apa yang dapat dilakukan oleh proses yang diistimewakan pada suatu sistem dalam sebuah wadah. Misalnya:Bagaimana cara menjalankan root dalam wadah dan tidak membiarkannya pecah?

Wadah Linux

• Apa itu container Linux?
• Pengantar terminologi wadah
• Unduh:Containers Primer
• Operator Kubernetes:Mengotomatiskan platform orkestrasi container
• eBook:Pola Kubernetes untuk mendesain aplikasi cloud-native
• Apa itu Kubernetes?

Ruang nama pengguna adalah tentang menjalankan proses istimewa dalam wadah, sehingga jika mereka keluar, mereka tidak akan lagi memiliki hak istimewa di luar wadah. Misalnya, dalam wadah UID saya adalah 0 (nol), tetapi di luar wadah UID saya adalah 5000. Karena masalah dengan kurangnya dukungan sistem file, namespace pengguna belum menjadi obat mujarab untuk memecahkannya. Sampai sekarang.

OpenShift adalah platform container Red Hat, dibangun di atas container Kubernetes, Red Hat Enterprise Linux, dan OCI, dan memiliki fitur keamanan yang hebat:Secara default, tidak ada container yang diizinkan untuk dijalankan sebagai root. Seorang admin dapat menimpa ini, jika tidak semua wadah pengguna berjalan tanpa pernah menjadi root. Ini sangat penting dalam cluster OpenShift Kubernetes multi-tenant, di mana satu cluster dapat melayani beberapa aplikasi dan beberapa tim pengembangan. Tidak selalu praktis atau bahkan disarankan bagi administrator untuk menjalankan cluster terpisah untuk masing-masing cluster. Sayangnya salah satu keluhan terbesar tentang OpenShift adalah bahwa pengguna tidak dapat dengan mudah menjalankan semua image container komunitas yang tersedia di docker.io. Ini karena sebagian besar gambar kontainer di dunia saat ini memerlukan root.

Mengapa semua gambar ini memerlukan root?

Jika Anda benar-benar memeriksa alasan untuk menjadi root, pada suatu sistem, alasannya sangat terbatas.

Ubah sistem host:

• Salah satu alasan utama untuk menjadi root pada sistem adalah untuk mengubah pengaturan default pada sistem, seperti memodifikasi konfigurasi kernel.
• Di Fedora, CentOS, dan Red Hat Enterprise Linux, kami memiliki konsep wadah sistem , yang merupakan wadah istimewa yang dapat diinstal pada sistem menggunakan atomic memerintah. Mereka dapat berjalan dengan hak istimewa penuh dan diizinkan untuk memodifikasi sistem serta kernel. Dalam kasus wadah sistem kami menggunakan gambar kontainer sebagai sistem pengiriman konten, tidak benar-benar mencari pemisahan kontainer. Kontainer sistem lebih untuk layanan host sistem operasi inti dibandingkan dengan layanan aplikasi pengguna yang dijalankan sebagian besar penampung.
• Dalam wadah aplikasi, kita hampir tidak pernah ingin proses di dalam wadah memodifikasi kernel. Ini jelas tidak diperlukan secara default.

Tradisi Unix/Linux:

• Vendor dan pengembang perangkat lunak sistem operasi telah lama mengetahui bahwa menjalankan proses sebagai root berbahaya, sehingga kernel menambahkan banyak kemampuan Linux untuk memungkinkan proses dimulai sebagai root dan kemudian menghapus hak istimewa secepat mungkin. Sebagian besar kemampuan UID/GID memungkinkan proses seperti layanan web dimulai sebagai root, kemudian menjadi non-root. Ini dilakukan untuk mengikat ke port di bawah 1024 (lebih lanjut tentang ini nanti).
• Waktu proses container dapat memulai aplikasi sebagai non-root untuk memulai. Sejujurnya, begitu juga systemd, tetapi sebagian besar perangkat lunak yang telah dibangun selama 20 tahun terakhir menganggapnya dimulai sebagai root dan menjatuhkan hak istimewa.

Ikat ke port <1024

• Pada tahun 1960-an dan 1970-an ketika hanya ada sedikit komputer, ketidakmampuan pengguna yang tidak memiliki hak untuk mengikat ke port jaringan <1024 dianggap sebagai fitur keamanan. Karena hanya admin yang dapat melakukan ini, Anda dapat mempercayai aplikasi yang mendengarkan pada port ini. Port> 1024 dapat diikat oleh pengguna mana pun di sistem sehingga tidak dapat dipercaya. Manfaat keamanan dari ini sebagian besar hilang, tetapi kita masih hidup dengan pembatasan ini.
• Masalah terbesar dengan pembatasan ini adalah layanan web di mana orang senang server web mereka mendengarkan pada port 80. Ini berarti alasan utama apache atau nginx mulai berjalan sebagai root adalah agar mereka dapat mengikat ke port 80 dan kemudian menjadi non-root.
• Waktu proses penampung, menggunakan penerusan porta, dapat mengatasi masalah ini. Anda dapat menyiapkan container untuk mendengarkan di port jaringan mana pun, lalu membuat container runtime memetakan port tersebut ke port 80 di host.

Dalam perintah ini, podman runtime akan menjalankan apache_unpriv container di mesin Anda mendengarkan pada port 80 di host, sedangkan proses Apache di dalam container tidak pernah di-root, dimulai sebagai apache pengguna, dan disuruh mendengarkan pada port 8080.

podman run -d -p 80:8080 -u apache apache_unpriv

Atau:

docker run -d -p 80:8080 -u apache apache_unpriv

Menginstal perangkat lunak ke dalam gambar kontainer

• Saat Docker memperkenalkan container bangunan dengan docker build , konten dalam wadah hanyalah perangkat lunak paket standar untuk distribusi. Perangkat lunak biasanya datang melalui paket rpm atau paket Debian. Nah, software paket distribusi harus diinstal dengan root. Sebuah paket diharapkan dapat melakukan hal-hal seperti memanipulasi /etc/passwd file dengan menambahkan pengguna, dan untuk meletakkan konten pada sistem file dengan UID/GID yang berbeda. Banyak perangkat lunak juga mengharapkan untuk dimulai melalui sistem init (systemd) dan mulai sebagai root dan kemudian menghapus hak istimewa setelah dimulai.
• Sayangnya, lima tahun dalam revolusi kontainer, ini masih status quo. Beberapa tahun yang lalu, saya mencoba untuk mendapatkan paket httpd untuk mengetahui ketika sedang diinstal oleh pengguna non-root dan memiliki konfigurasi yang berbeda. Tapi saya menjatuhkan bola ini. Kita perlu memiliki pembuat paket dan sistem manajemen paket yang mulai memahami perbedaannya, dan kemudian kita dapat membuat container bagus yang berjalan tanpa memerlukan root.
• Satu hal yang dapat kami lakukan sekarang untuk memperbaiki masalah ini adalah memisahkan sistem pembangunan dari sistem penginstalan. Salah satu masalah saya dengan #nobigfatdaemons adalah bahwa daemon Docker menyebabkan container berjalan dengan privs yang sama untuk menjalankan container seperti yang dilakukan untuk membangun image container.
• Jika kita mengubah sistem atau menggunakan alat yang berbeda, misalnya Buildah, untuk membuat container dengan batasan yang lebih longgar dan CRI-O/Kubernetes/OpenShift untuk menjalankan container dalam produksi, maka kita dapat membangun dengan hak istimewa yang lebih tinggi, tetapi kemudian menjalankan wadah dengan batasan yang lebih ketat, atau semoga sebagai non-root pengguna.

Intinya

Hampir semua perangkat lunak yang Anda jalankan di wadah Anda tidak membutuhkan akar. Aplikasi web Anda, database, load balancer, pengolah angka, dll. tidak perlu dijalankan sebagai root. Saat kami membuat orang mulai membuat image container yang tidak memerlukan root sama sekali, dan orang lain mendasarkan gambar mereka dari image container yang tidak memiliki hak istimewa, kami akan melihat lompatan besar dalam keamanan container.

Masih banyak pendidikan yang perlu dilakukan seputar menjalankan root di dalam wadah. Tanpa pendidikan, administrator yang cerdas dapat membuat keputusan yang buruk.