Salah satu fitur baru Podman yang paling menarik adalah wadah tanpa akar. Rootless memungkinkan hampir semua container dijalankan sebagai pengguna biasa, tanpa hak istimewa yang lebih tinggi, dan manfaat keamanan utama. Namun, menjalankan container tanpa hak akses root memang memiliki keterbatasan.
Seorang pengguna mengajukan pertanyaan tentang salah satu dari ini:Mengapa mereka tidak dapat menarik gambar tertentu dengan Podman tanpa root?
Gambar mereka mengeluarkan kesalahan setelah mengunduh, seperti yang di bawah ini:
ERRO[0005] Error pulling image ref //testimg:latest: Error committing the finished image: error adding layer with blob "sha256:caed8f108bf6721dc2709407ecad964c83a31c8008a6a21826aa4ab995df5502": Error processing tar file(exit status 1): there might not be enough IDs available in the namespace (requested 4000000:4000000 for /testfile): lchown /testfile: invalid argument
Saya menjelaskan bahwa masalah mereka adalah gambar mereka memiliki file yang dimiliki oleh UID lebih dari 65536. Karena masalah itu, gambar tidak akan cocok dengan pemetaan UID default Podman tanpa akar, yang membatasi jumlah UID dan GID yang tersedia.
Pertanyaan lanjutannya tentu saja:
- Mengapa batasan itu ada?
- Mengapa Anda tidak dapat menggunakan gambar apa pun yang berfungsi pada Podman normal dalam mode tanpa root?
- Mengapa UID dan GID yang digunakan menjadi penting?
Saya akan mulai dengan menjelaskan mengapa kita perlu menggunakan UID dan GID yang berbeda dari host, lalu menjelaskan mengapa defaultnya adalah 65536—dan cara mengubah nomor ini.
Memetakan ruang nama pengguna
Wadah tanpa root berjalan di dalam ruang nama pengguna , yang merupakan cara memetakan pengguna dan grup host ke dalam penampung. Secara default, kami memetakan pengguna yang meluncurkan Podman sebagai UID/GID 0 dalam wadah tanpa akar.
Di sistem saya, pengguna saya (mheon ) adalah UID 1000. Saat saya meluncurkan wadah tanpa akar sebagai mheon dengan podman run -t -i --rm fedora bash , lalu jalankan top di dalam wadah, saya tampak seperti UID 0—root.
Namun, pada host, bash proses masih dimiliki oleh pengguna saya. Anda dapat melihat hasil ini ketika saya menjalankan podman top di sistem host saya:
mheon@Agincourt code/podman.io (release_blog_1.5.0)$ podman top -l user group huser hgroup
USER GROUP HUSER HGROUP
root root 1000 1000
USER dan GROUP pilihannya adalah pengguna dan grup seperti yang muncul di wadah , sedangkan HUSER dan HGROUP pilihannya adalah pengguna dan grup saat mereka muncul di host .
Mari kita tunjukkan contoh sederhana. Saya akan memasang /etc/ , yang penuh dengan file yang dimiliki oleh root, ke dalam wadah tanpa akar. Kemudian saya akan menunjukkan isinya dengan ls :
mheon@Agincourt code/libpod (master)$ podman run -t -i -v /etc/:/testdir --rm fedora sh -c 'ls -l /testdir 2> /dev/null | head -n 10'
total 1700
-rw-r--r--. 1 nobody nobody 4664 May 3 14:39 DIR_COLORS
-rw-r--r--. 1 nobody nobody 5342 May 3 14:39 DIR_COLORS.256color
Saya tidak memiliki izin untuk mengubah file-file ini, terlepas dari kenyataan bahwa saya melakukan root di wadah. Saya bahkan tidak dapat melihat banyak dari mereka:Perhatikan 2> /dev/null setelah ls untuk mengatasi kesalahan karena saya mendapatkan banyak kesalahan izin bahkan ketika mencoba membuat daftarnya.
Di host, file-file ini dimiliki oleh root, UID 0—tetapi di dalam container, file-file ini dimiliki oleh nobody . Itu adalah nama khusus yang digunakan kernel Linux untuk mengatakan bahwa pengguna yang sebenarnya memiliki file tidak ada di ruang nama pengguna. UID dan GID 0 di host tidak dipetakan ke penampung, jadi alih-alih file dimiliki oleh 0:0 , mereka dimiliki oleh nobody:nobody dari sudut pandang wadah.
Tidak peduli pengguna apa yang Anda lihat dalam wadah tanpa akar, Anda masih bertindak sebagai pengguna Anda sendiri, dan Anda hanya dapat mengakses file yang dapat diakses oleh pengguna Anda di host. Penyiapan ini merupakan bagian besar dari daya tarik keamanan container rootless—bahkan jika penyerang dapat keluar dari container, mereka masih terbatas pada akun pengguna non-root.
Mengalokasikan UID/GID tambahan
Saya katakan sebelumnya bahwa ruang nama pengguna memetakan pengguna di Host ke pengguna di wadah, dan menjelaskan sedikit tentang cara kerja proses itu untuk root di wadah. Namun container umumnya memiliki pengguna selain hanya root—artinya Podman perlu memetakan di UID tambahan untuk memungkinkan pengguna satu dan di atasnya ada dalam container.
Dengan kata lain, setiap pengguna yang diperlukan oleh wadah harus dipetakan. Masalah ini menyebabkan kesalahan asli di atas karena gambar menggunakan UID/GID yang tidak ditentukan di ruang nama penggunanya.
newuidmap dan newgidmap executable, biasanya disediakan oleh shadow-utils atau uidmap paket, digunakan untuk memetakan UID dan GID ini ke dalam ruang nama pengguna container. Alat ini membaca pemetaan yang didefinisikan dalam /etc/subuid dan /etc/subgid dan menggunakannya untuk membuat ruang nama pengguna dalam wadah. Ini setuid binari menggunakan hak istimewa tambahan untuk memberi wadah tanpa akar kami akses ke UID dan GID tambahan—sesuatu yang biasanya tidak kami izinkan. Setiap pengguna yang menjalankan Podman rootless harus memiliki entri dalam file-file ini jika mereka perlu menjalankan container dengan lebih dari satu UID. Setiap kontainer menggunakan semua UID yang tersedia secara default, meskipun pemetaan yang tepat dapat disesuaikan dengan --uidmap dan --gidmap .
Pengguna non-root normal di Linux biasanya hanya memiliki akses ke pengguna mereka sendiri—satu UID. Menggunakan UID dan GID ekstra dalam wadah tanpa akar memungkinkan Anda bertindak sebagai pengguna yang berbeda, sesuatu yang biasanya memerlukan hak akses root (atau masuk sebagai pengguna lain dengan kata sandi mereka). Pemetaan yang dapat dieksekusi newuidmap dan newgidmap gunakan hak istimewa mereka yang lebih tinggi untuk memberi kami akses ke UID dan GID tambahan sesuai dengan pemetaan yang dikonfigurasi di /etc/subuid dan /etc/subgid tanpa root atau memiliki izin untuk login sebagai pengguna.
Setiap pengguna yang menjalankan Podman rootless harus memiliki entri dalam file-file ini jika mereka perlu menjalankan container dengan lebih dari satu UID di dalamnya.
Mengubah nomor ID default
Sekarang, ke masalah nomor default UID dan GID yang tersedia dalam wadah:65536. Jumlah ini bukan batas yang pasti, dan dapat disesuaikan naik atau turun menggunakan /etc/subuid yang disebutkan di atas dan /etc/subgid file.
Misalnya, di sistem saya:
mheon@Agincourt code/libpod (master)$ cat /etc/subuid
mheon:100000:65536
File ini diformat sebagai <username>:<start_uid>:<size> , di mana start_uid adalah UID atau GID pertama yang tersedia untuk pengguna, dan size adalah jumlah UID/GID yang tersedia (dimulai dari start_uid , dan diakhiri dengan start_uid + size - 1 ).
Jika saya mengganti 65536 itu dengan, katakanlah, 123456, saya akan memiliki 123456 UID yang tersedia di dalam wadah rootless saya.
"Mengapa memilih 65536 sebagai default?" adalah pertanyaan untuk pengelola alat pembuatan pengguna Linux, useradd , karena default awal diisi saat pengguna dibuat, dan bukan oleh Podman. Namun, saya akan menebak bahwa pengaturan ini cukup untuk membuat sebagian besar aplikasi berfungsi tanpa perubahan (versi Linux yang sangat lama hanya memiliki UID/GID 16-bit, dan nilai yang lebih tinggi masih agak jarang).
Catatan: /etc/subuid dan /etc/subgid file untuk menyesuaikan pengguna yang sudah ada. Default untuk pengguna baru disesuaikan di tempat lain.
Default 65536 yang diterima pengguna baru tidak hard-coded. Namun, Ini tidak akan memengaruhi pengguna yang ada. Ini diatur dalam /etc/login.defs file, dengan SUB_UID_COUNT dan SUB_GID_COUNT pilihan. Kami sebenarnya telah berdiskusi tentang memindahkan default ke lebih rendah, karena rasanya sebagian besar penampung mungkin akan berfungsi dengan baik dengan sedikit lebih dari 1000 UID/GID, dan lebih banyak lagi setelah itu terbuang percuma.
Yang penting adalah bahwa nilai ini mewakili saluran UID/GID yang dialokasikan pada host yang tersedia untuk satu pengguna tertentu untuk menjalankan wadah tanpa akar. Jika saya menambahkan pengguna lain ke sistem ini, mereka akan mendapatkan saluran UID lain, mungkin mulai dari 165536, lagi-lagi dengan lebar 65536 secara default.
Root memiliki izin untuk mengubah batasan ini, tetapi pengguna biasa tidak. Jika tidak, saya dapat mengubah sedikit pemetaan menjadi mheon:0:65536 dan petakan pengguna root yang sebenarnya pada sistem ke dalam wadah rootless saya, yang kemudian dapat dengan mudah diputar ke dalam akses root di seluruh sistem.
Mencegah tumpang tindih UID dan GID
Sebagai aturan umum untuk keamanan, hindari membiarkan UID/GID sistem apa pun (biasanya diberi nomor di bawah 1000), dan idealnya semua UID/GID yang digunakan pada sistem host, ke dalam wadah. Praktik ini mencegah pengguna memiliki akses ke file sistem di host saat mereka membuat container tanpa root.
Kami juga ingin setiap pengguna memiliki rentang unik UID/GID relatif terhadap pengguna lain—saya dapat menambahkan pengguna alice ke /etc/subuid saya dengan pemetaan yang sama persis dengan pengguna saya (alice:100000:65536 ), tapi kemudian Alice akan memiliki akses ke wadah rootless saya, dan saya ke miliknya.
Dimungkinkan untuk meningkatkan ukuran alokasi pengguna Anda, seperti yang dibahas sebelumnya, tetapi Anda harus mengikuti aturan ini untuk keamanan. Saya akan daftar lagi:
- Tidak ada UID/GID di bawah 1000.
- Tidak ada UID atau GID yang masuk ke penampung jika sedang digunakan di host.
- Jangan tumpang tindih pemetaan antar pengguna.
Yang terakhir adalah alasan utama mengapa kami tidak ingin memetakan dalam alokasi UID dan GID yang lebih tinggi. Kami berpotensi memberikan rentang yang sangat besar kepada satu pengguna, termasuk semuanya dari 100.000 hingga UID_MAX , dan sediakan sedikit lebih dari 4,2 juta UID—tetapi kemudian tidak ada lagi yang tersisa untuk pengguna lain.
Menutup
Dengan Podman 1.5.0 dan yang lebih tinggi, kami telah menambahkan opsi eksperimental baru (--storage-opt ignore_chown_errors ) untuk menekan semua UID dan GID, sehingga menjalankan container sebagai pengguna tunggal (pengguna yang meluncurkan container). Setelan ini memecahkan masalah awal artikel, tetapi menetapkan serangkaian batasan tambahan pada penampung—detail tentang itu sebaiknya diserahkan ke artikel lain.
Pembatasan UID dan GID yang ditempatkan pada wadah tanpa root bisa merepotkan, tetapi Anda jarang mengalaminya. Sebagian besar gambar dan penampung menggunakan jauh lebih sedikit daripada 65536 UID dan GID yang tersedia. Keterbatasan ini adalah beberapa pengorbanan dari container rootless, di mana kami mengorbankan beberapa kenyamanan dan kegunaan untuk peningkatan besar dalam keamanan.