BerandaComputers and TechnologyPraktik Terbaik Keamanan Dockerfile

Praktik Terbaik Keamanan Dockerfile

Keamanan wadah adalah ruang masalah yang luas dan ada banyak buah yang tergantung rendah yang dapat dipanen untuk mengurangi risiko. Titik awal yang baik adalah mengikuti beberapa aturan saat menulis Dockerfiles.

Saya telah menyusun daftar masalah keamanan umum dan cara menghindarinya. Untuk setiap masalah, saya juga telah menulis aturan Open Policy Agent (OPA) siap untuk digunakan untuk menganalisis Dockerfiles Anda secara statis dengan conftest . Anda tidak dapat menggeser lebih banyak ke kiri dari ini!

Anda dapat menemukan . Rego aturan yang ditetapkan di repositori ini . Saya menghargai umpan balik dan kontribusi.

Jangan menyimpan rahasia dalam variabel lingkungan

Distribusi rahasia adalah masalah besar dan mudah dilakukan dengan cara yang salah. Untuk aplikasi dalam container, seseorang dapat memunculkannya baik dari sistem file dengan memasang volume atau lebih mudah melalui variabel lingkungan.

Menggunakan ENV untuk menyimpan rahasia adalah praktik yang buruk karena Dockerfiles biasanya didistribusikan dengan aplikasi, jadi tidak ada perbedaan dari rahasia pengkodean keras dalam kode.

Cara mendeteksinya:

  secret_env=[    "passwd",    "password",    "pass", #  "pwd", can't use this one       "secret",    "key",    "access",    "api_key",    "apikey",    "token",    "tkn"]  tolak [msg] {     masukan [i]. Cmd=="env"     val:=masukan [i]. Nilai     berisi (lebih rendah (val [_]), rahasia_env [_])     msg=sprintf ("Baris% d: Potensi rahasia dalam kunci ENV ditemukan:% s", [i, val]) }  

Hanya gunakan gambar dasar tepercaya

Serangan rantai pasokan untuk aplikasi dalam peti kemas juga akan datang dari hierarki lapisan yang digunakan untuk membangun penampung itu sendiri.

Pelaku utama jelas gambar dasar yang digunakan. Gambar dasar yang tidak tepercaya memiliki risiko tinggi dan jika memungkinkan harus dihindari.

Docker menyediakan set gambar dasar resmi untuk sistem operasi dan aplikasi yang paling sering digunakan. Dengan menggunakannya, kami meminimalkan risiko kompromi dengan memanfaatkan semacam tanggung jawab bersama dengan Docker itu sendiri.

Cara mendeteksinya:

  tolak [msg] {     masukan [i]. Cmd=="dari"     val:=split (masukan [i]. Nilai [0], "/")     hitung (val)> 1     msg=sprintf ("Baris% d: gunakan gambar dasar tepercaya", [i]) }  

Aturan ini disesuaikan dengan image resmi DockerHub. Ini sangat bodoh karena saya hanya mendeteksi tidak adanya namespace.

Definisi kepercayaan bergantung pada konteks Anda: ubah aturan ini sesuai dengan itu.

Jangan gunakan tag ‘terbaru’ untuk gambar dasar

Menyematkan versi gambar dasar Anda akan memberi Anda ketenangan pikiran sehubungan dengan prediktabilitas wadah yang Anda buat.

Jika Anda mengandalkan yang terbaru, Anda mungkin secara diam-diam mewarisi paket yang diperbarui yang dalam kasus terburuk terbaik dapat memengaruhi keandalan aplikasi Anda, dalam kasus terburuk mungkin menimbulkan kerentanan.

Cara mendeteksinya:

  tolak [msg] {     masukan [i]. Cmd=="dari"     val:=split (masukan [i]. Nilai [0], ":")     berisi (lebih rendah (val [1]), "terbaru"])     msg=sprintf ("Baris% d: jangan gunakan tag 'terbaru' untuk gambar dasar", [i]) }  

Hindari curl bashing

Menarik barang dari internet dan menyalurkannya ke shell seburuk mungkin. Sayangnya, ini adalah solusi yang tersebar luas untuk menyederhanakan penginstalan perangkat lunak.

  wget https: // cloudberry. engineering / absolute-trustworthy.sh | SH  

Risiko yang dibingkai sama untuk serangan rantai pasokan dan itu bermuara pada kepercayaan . Jika Anda benar-benar harus melakukan curl bash, lakukan dengan benar:

  • menggunakan sumber tepercaya
  • menggunakan koneksi aman
  • memverifikasi keaslian dan integritas apa yang Anda unduh

Bagaimana untuk mendeteksinya:

  tolak [msg] {     masukan [i]. Cmd=="jalankan"     val:=concat ("", masukan [i]. Nilai)     cocok:=regex.find_n ("(curl | wget) [^|^>] [|>]", lebih rendah (val), -1)     hitung (cocok)> 0     msg=sprintf ("Baris% d: Hindari curl bashing", [i]) }  

Jangan meningkatkan paket sistem Anda

Ini mungkin sedikit berlebihan tetapi alasannya adalah sebagai berikut: Anda ingin menyematkan versi dependensi perangkat lunak Anda, jika Anda melakukannya peningkatan apt-get Anda akan secara efektif meningkatkan semuanya ke versi terbaru.

Jika Anda melakukan peningkatan dan Anda menggunakan terbaru tag untuk gambar dasar, Anda memperkuat ketidakpastian pohon dependensi Anda.

Yang ingin Anda lakukan adalah menyematkan versi gambar dasar dan hanya apt / apk memperbarui.

Cara mendeteksinya:

  upgrade_commands=[    "apk upgrade",    "apt-get upgrade",    "dist-upgrade",]  tolak [msg] {     masukan [i]. Cmd=="jalankan"     val:=concat ("", masukan [i]. Nilai)     berisi (val, upgrade_commands [_])     msg=sprintf (“Baris:% d: Jangan tingkatkan paket sistem Anda", [i]) }  

Jangan gunakan ADD jika memungkinkan

Satu fitur kecil dari TAMBAH perintah adalah Anda dapat mengarahkannya ke url jarak jauh dan itu akan mengambil konten pada waktu pembuatan:

  TAMBAHKAN https: // cloudberry. engineering / absolute-trust-me.tar.gz  

Ironisnya, dokumen resmi menyarankan untuk menggunakan curl bashing sebagai gantinya.

Dari perspektif keamanan, saran yang sama berlaku: jangan. Dapatkan konten apa pun yang Anda butuhkan sebelumnya, verifikasi dan kemudian SALIN . Tetapi jika Anda benar-benar harus, gunakan sumber tepercaya melalui koneksi aman .

Catatan: jika Anda memiliki sistem build mewah yang secara dinamis menghasilkan Dockerfiles, maka TAMBAHKAN secara efektif merupakan wastafel yang meminta untuk dieksploitasi.

Cara mendeteksinya:

  tolak [msg] {     masukan [i]. Cmd=="tambahkan"     msg=sprintf ("Baris% d: Gunakan SALIN alih-alih TAMBAH", [i]) }  

Jangan root

Root dalam container adalah root yang sama seperti pada mesin host, tetapi dibatasi oleh konfigurasi daemon buruh pelabuhan. Terlepas dari batasannya, jika seorang aktor keluar dari wadah, dia masih dapat menemukan cara untuk mendapatkan akses penuh ke host.

Tentu saja ini tidak ideal dan model ancaman Anda tidak dapat mengabaikan risiko yang ditimbulkan dengan menjalankan sebagai root.

Karena itu, yang terbaik adalah selalu menentukan pengguna:

  PENGGUNA semoga tidak root  

Perhatikan bahwa secara eksplisit mengatur pengguna di Dockerfile hanyalah satu lapisan pertahanan dan tidak akan menyelesaikan keseluruhan berjalan sebagai akar masalah .

Sebagai gantinya, seseorang dapat – dan Sebaiknya – mengadopsi pendekatan mendalam pertahanan dan mengurangi lebih jauh di seluruh tumpukan: konfigurasikan secara ketat daemon buruh pelabuhan atau gunakan solusi kontainer tanpa root, batasi konfigurasi waktu proses (larang - diistimewakan jika memungkinkan, dll), dan seterusnya.

Cara mendeteksinya:

  any_user {     masukan [i]. Cmd=="pengguna"  }  tolak [msg] {     bukan any_user     msg="Jangan dijalankan sebagai root, gunakan USER sebagai gantinya" }  

Jangan sudo

Sebagai akibat dari jangan root , Anda juga tidak boleh sudo.

Meskipun Anda menjalankan sebagai pengguna, pastikan pengguna tersebut tidak berada di sudoers klub.

  tolak [msg] {     masukan [i]. Cmd=="jalankan"     val:=concat ("", masukan [i]. Nilai)     berisi (lebih rendah (val), "sudo")     msg=sprintf ("Baris% d: Jangan gunakan perintah 'sudo'", [i]) }  

Ucapan Terima Kasih

Karya ini telah terinspirasi dan merupakan iterasi seni sebelumnya dari Madhu Akula .

Read More

RELATED ARTICLES

LEAVE A REPLY

Please enter your comment!
Please enter your name here

Most Popular

Recent Comments