Menjaga kerahasiaan data dan kode dalam gambar container
Selama beberapa tahun terakhir, industri cloud telah melihat perubahan besar dari penerapan aplikasi monolitik pada mesin virtual menjadi memecah aplikasi menjadi komponen yang lebih kecil (layanan mikro) dan mengemasnya ke dalam wadah. Popularitas containerization saat ini sebagian besar didorong oleh cara kerja Docker. Docker adalah perusahaan yang telah menjadi kekuatan pendorong utama di balik kontainer: ia telah menyediakan alat yang mudah digunakan untuk membangun dan menjalankan kontainer Docker dan registri kontainer Docker untuk tantangan distribusi.
Keberhasilan teknologi containerization terutama bergantung pada keamanan container di berbagai tahap siklus hidupnya. Salah satu masalah keamanan adalah adanya kerentanan di dalam container individu. Untuk mengidentifikasinya, pipeline DevOps yang digunakan untuk membuat container dilengkapi dengan pemindai yang mencari paket dengan kemungkinan kerentanan dalam container dan memberi tahu pemilik atau teknisi jika ditemukan. Vulnerability Advisor di IBM Cloud adalah contoh dari utilitas semacam itu.
Aspek keamanan lainnya adalah memastikan bahwa penampung yang diluncurkan adalah yang Anda inginkan dan belum dimodifikasi. Masalah ini diatasi dengan menggunakan tanda tangan digital yang disimpan di Notaris, yang akan melindungi wadah dari modifikasi apa pun.Docker Notary adalah contoh repositori publik yang menyimpan tanda tangan gambar. Dengan menggunakan Notaris, pelanggan dapat memverifikasi tanda tangan gambar kontainer untuk memastikan bahwa gambar kontainer belum diubah sejak ditandatangani dengan pemilik atau teknisi servis key.
Masalah keamanan potensial lainnya adalah isolasi kontainer. Teknologi keamanan runtime Linux seperti namespace, cgroup, kapabilitas Linux, dan profil SELinux, AppArmor, dan Seccomp membantu membatasi proses container dan mengisolasi container satu sama lain pada waktu proses.
Artikel ini membahas masalah keamanan perusahaan yang masih hangat terkait privasi data dan kode di gambar kontainer. Tujuan keamanan utama saat bekerja dengan gambar kontainer adalah untuk memungkinkan pembuatan dan distribusi gambar kontainer terenkripsi sehingga hanya tersedia untuk kumpulan penerima tertentu. Dalam kasus ini, orang lain mungkin memiliki akses ke gambar-gambar ini, tetapi mereka tidak akan dapat menjalankannya atau melihat data sensitif di dalamnya. Enkripsi container didasarkan pada kriptografi yang ada seperti teknologi enkripsi Rivest-Shamir-Adleman (RSA), kurva eliptik, dan Advanced Encryption Standard (AES), juga dikenal sebagai Rijndael, algoritma penyandian blok simetris.
Pengantar
Untuk mendapatkan hasil maksimal dari artikel ini, Anda harus sudah familiar dengan container Linux dan image container, dan memiliki pemahaman tentang dasar-dasar keamanan.
Pekerjaan terkait tentang enkripsi dan kontainer
Sejauh yang kami tahu, tidak ada pekerjaan di bidang mengenkripsi gambar container. Namun, ada banyak implementasi dan produk yang mendukung kerahasiaan data dan enkripsi anti-pencurian melalui sistem file, perangkat blok, atau enkripsi perangkat keras. Yang terakhir diimplementasikan menggunakan disk yang mengenkripsi sendiri. Ada juga gambar mesin virtual terenkripsi.
Sistem file terenkripsi ada di banyak sistem operasi di perusahaan dan dapat mendukung pemasangan partisi dan direktori terenkripsi. Sistem file terenkripsi bahkan dapat mendukung booting dari drive boot terenkripsi. Linux mendukung enkripsi perangkat blok menggunakan dm-encrypt driver; ecryptfs adalah salah satu contoh sistem file terenkripsi. Solusi enkripsi file lain tersedia untuk Linuxopen source. Di Windows, enkripsi didukung oleh sistem file NTFS v3.0. Selain itu, banyak pabrikan membuat disk pengenkripsi sendiri. Untuk image mesin virtual, ada solusi yang mirip dengan disk terenkripsi. Produk open source QEMU Machine (PC) Emulator dan VMware mendukung image mesin virtual terenkripsi.
Enkripsi data biasanya ditujukan untuk melindungi dari pencurian data saat sistem sedang offline. Teknologi terkait menandatangani image container dengan kunci yang disediakan oleh klien dan server Notaris Docker. Server Docker Notary bekerja di dekat registri gambar kontainer. Pengguna alat klien Docker memiliki opsi untuk menandatangani image container dan mengunggah tanda tangan ke akun mereka melalui Docker Notary. Selama proses ini, tanda tangan terikat ke gambar container melalui nama jalur ke gambar dan versinya. Tanda tangan dibuat menggunakan fungsi hash yang dihitung berdasarkan deskripsi seluruh konten gambar. Deskripsi ini disebut manifes gambar kontainer.Teknologi penandatanganan gambar kontainer memecahkan masalah dalam melindungi gambar kontainer dari akses yang tidak sah dan membantu menentukan asal gambar kontainer.
Struktur
Ekosistem Docker berevolusi untuk menstandarisasi format gambar kontainer menggunakan kelompok standar Open Container Initiative (OCI), yang sekarang mengontrol format runtime kontainer (runtime-spec) dan format gambar kontainer (image-spec). Karena pekerjaan tim memerlukan ekstensi dari format gambar kontainer yang ada, kami mengidentifikasi ekstensi ke standar untuk mendukung gambar terenkripsi. Bagian berikut menjelaskan gambar container dan format ekstensi yang ada.
Di tingkat atas, penampung dapat terdiri dari dokumen JavaScript Object Notation (JSON), yang merupakan daftar manifes gambar. Misalnya, Anda dapat menggunakan daftar manifes ini saat beberapa arsitektur atau platform digunakan untuk gambar container. Daftar manifes berisi tautan ke manifes penampung, satu tautan untuk setiap kombinasi arsitektur dan sistem operasi. Misalnya, arsitektur yang didukung mencakup amd64, arm, dan ppc64le, dan sistem operasi yang didukung mencakup Linux atau Windows. Contoh daftar manifes ditunjukkan pada tangkapan layar di bawah ini:
Bidang mediaType menjelaskan format yang tepat dari dokumen yang ditentukan. Daftar manifes ini memungkinkan perluasan dan pemilihan parser yang sesuai di masa mendatang untuk dokumen yang terlibat.
Tingkat di bawah daftar manifes adalah manifes. Manifes juga merupakan dokumen JSON dan berisi daftar referensi yang diurutkan ke lapisan gambar. Tautan ini berisi mediaType yang menjelaskan format lapisan. Format tersebut dapat menjelaskan apakah lapisan dikompresi, dan jika ya, bagaimana caranya. Misalnya, setiap level dapat disimpan sebagai file .tar yang berisi file yang ditambahkan pada tahapan tertentu dalam build saat menjalankan build docker di Dockerfile. Lapisan sering kali dikemas menggunakan file .gzip terkompresi untuk meningkatkan efisiensi penyimpanan. Contoh dokumen manifes ditunjukkan pada tangkapan layar berikut:
Seperti yang ditunjukkan, manifes dan lapisan direferensikan melalui "intisari", yang biasanya merupakan fungsi hash sha256 dalam dokumen JSON. Manifes dan lapisan biasanya disimpan sebagai file di sistem file. Seringkali, nama file adalah fungsi hash di atas konten, membuatnya lebih mudah untuk ditemukan dan dimuat. Konsekuensi dari metode hash ini adalah bahwa perubahan kecil pada dokumen yang direferensikan menyebabkan perubahan pada semua dokumen yang mereferensikannya, sampai ke daftar manifes.
Sebagai bagian dari proyek tim kami, kami membuat enkripsi gambar berdasarkan skema enkripsi hybrid menggunakan kunci publik dan simetris. Kunci simetris digunakan untuk enkripsi data massal (digunakan untuk enkripsi multilevel), dan kunci publik digunakan untuk mengemas kunci simetris. Kami menggunakan tiga teknologi enkripsi kunci publik yang berbeda: OpenPGP, JSON Web Encryption (JWE), dan PKCS # 7.
OpenPGP
OpenPGP adalah teknologi enkripsi dan tanda tangan yang biasa digunakan untuk mengenkripsi dan menandatangani pesan email. Komunitas open source juga sering menggunakannya untuk menandatangani komit (tag) dari kode sumber di repositori git. Ini adalah standar Internet yang ditentukan oleh IETF di RFC480 dan dapat dilihat sebagai versi terbuka dari teknologi PGP milik sebelumnya.
OpenPGP memiliki formatnya sendiri untuk kunci RSA. Kunci biasanya disimpan dalam file keyring dan dapat diimpor dari file kunci OpenPGP biasa. Aspek paling nyaman dari keyring OpenPGP adalah bahwa kunci publik dapat ditautkan ke alamat email pemiliknya. Anda dapat bekerja dengan beberapa penerima pesan hanya dengan memilih daftar penerima berdasarkan alamat email mereka, yang kemudian muncul di kunci publik untuk penerima tersebut. Selain itu, web kepercayaan telah dibangun di sekitar teknologi ini: Anda dapat menemukan kunci publik dari banyak pengguna, diurutkan berdasarkan alamat email mereka. Misalnya, kunci ini sering digunakan untuk menandatangani tag git.
Anda dapat menggunakan OpenPGP Encrypted Message Format untuk mengenkripsi pesan massal ke beberapa penerima. Header pesan OpenPGP berisi satu blok untuk setiap penerima. Setiap blok berisi pengenal kunci 64-bit yang memberi tahu algoritme dekripsi tempat mencoba mendekripsi kunci pribadi yang sesuai. Setelah blob terenkripsi di dalam blok didekripsi, ini menunjukkan kunci simetris yang dapat digunakan untuk mendekripsi pesan massal. Gumpalan kunci publik terenkripsi setiap penerima menunjukkan kunci simetris yang sama.
Kami menggunakan OpenPGP dengan cara yang serupa, tetapi dalam kasus ini, pesan terenkripsi yang dikirimkannya bukanlah sebuah lapisan. Sebaliknya, ini berisi dokumen JSON, yang pada gilirannya berisi kunci simetris yang digunakan untuk mengenkripsi dan mendekripsi layer dan vektor inisialisasi. Kami menyebut kunci ini sebagai kunci enkripsi lapisan (LEK) dan ini adalah bentuk kunci enkripsi data. Keuntungan dari cara ini adalah kita hanya membutuhkan satu LEK. Dengan LEK, kami mengenkripsi lapisan untuk satu atau lebih penerima. Setiap penerima (gambar container) dapat memiliki jenis kunci yang berbeda, dan tidak harus berupa kunci OpenPGP. Misalnya, ini bisa menjadi kunci RSA sederhana. Selama kami memiliki kemampuan untuk menggunakan kunci RSA ini untuk mengenkripsi LEK, kami dapat bekerja dengan banyak penerima dengan jenis kunci yang berbeda.
JSON Web Encryption (JWE)
Enkripsi Web JSON, juga dikenal sebagai JWE, adalah standar Internet IETF lainnya dan ditentukan di RFC7516 . Ini adalah standar enkripsi yang lebih baru daripada OpenPGP, dan oleh karena itu menggunakan cipher tingkat rendah yang lebih baru yang dirancang untuk memenuhi persyaratan enkripsi yang lebih ketat.
Pada skala yang lebih besar, JWE bekerja dengan cara yang mirip dengan OpenPGP karena ia juga memelihara daftar penerima dan pesan massal yang dienkripsi dengan kunci simetris yang dapat diakses oleh setiap penerima pesan. Penerima pesan JWE dapat memiliki berbagai jenis kunci, seperti kunci RSA, jenis kunci kurva eliptik khusus untuk enkripsi, dan kunci simetris. Karena ini adalah standar yang lebih baru, JWE masih dapat diperluas untuk mendukung kunci di perangkat keras seperti TPM atau modul keamanan perangkat keras (HSM) menggunakan PKCS # 11 atau antarmuka Key Management and Interoperability Protocol (KMIP). JWE digunakan dengan cara yang mirip dengan OpenPGP jika penerima memiliki kunci RSA atau kurva elips.Di masa mendatang, kami dapat memperluasnya untuk mendukung kunci simetris seperti KMIP di dalam HSM.
PKCS # 7
PKCS # 7, juga dikenal sebagai Cryptographic Message Syntax (CMS), didefinisikan di IEFT RFC5652 . Menurut Wikipedia tentang CMS, "Ini dapat digunakan untuk menandatangani, mencerna, mengotentikasi, atau mengenkripsi segala bentuk data digital secara digital."
Ini mirip dengan dua teknologi yang dijelaskan sebelumnya karena memungkinkan banyak penerima dan enkripsi pesan massal. Oleh karena itu, kami menggunakannya seperti teknologi lainnya, tetapi hanya untuk penerima yang memberikan sertifikat untuk kunci enkripsi.
Untuk mendukung teknologi enkripsi yang dijelaskan sebelumnya, kami telah memperluas dokumen manifes untuk menyertakan informasi berikut:
- Pesan OpenPGP, JWE dan PKCS # 7 disimpan dalam peta anotasi, yang merupakan bagian dari manifes.
- Setiap lapisan yang ditentukan berisi satu peta. Peta anotasi pada dasarnya adalah kamus dengan string sebagai kunci dan string sebagai nilai (pasangan nilai-kunci).
Untuk mendukung enkripsi gambar, kami telah menetapkan kunci berikut:
- org.opencontainers.image.enc.keys.openpgp
- org.opencontainers.image.enc.keys.jwe
- org.opencontainers.image.enc.keys.pkcs7
Nilai yang direferensikan oleh setiap kunci berisi satu atau beberapa pesan terenkripsi untuk teknologi enkripsi yang sesuai. Karena pesan ini bisa dalam format biner, mereka dikodekan base64. Lapisan terenkripsi harus memiliki setidaknya satu anotasi, tetapi dapat memiliki semuanya, jika penerimanya memiliki jenis kunci yang berbeda dalam jumlah yang memadai.
Untuk menentukan bahwa lapisan dienkripsi dengan LEK, kami memperluas jenis media yang ada dengan akhiran '+ dienkripsi', seperti yang ditunjukkan pada contoh berikut:
- application / vnd.docker.image.rootfs.diff.tar + dienkripsi
- application / vnd.docker.image.rootfs.diff.tar.gzip + dienkripsi
Contoh ini menunjukkan bahwa lapisan diarsipkan dalam file .tar dan dienkripsi - atau keduanya diarsipkan dalam file .tar dan dikompresi dalam file .gzip dan dienkripsi. Tangkapan layar berikut menunjukkan contoh manifes yang tertaut ke lapisan terenkripsi. Ini juga menunjukkan peta anotasi yang berisi pesan JWE terenkripsi.
Enkripsi berlapis menggunakan kunci simetris
Untuk enkripsi simetris dengan LEK, tim kami memilih sandi yang mendukung enkripsi terautentikasi dan didasarkan pada standar enkripsi AES dengan kunci 128- dan 256-bit.
Contoh implementasi: containerd
Kami menerapkan variasi kami dalam proyek runtime kontainer baru yang disebut containerd . Kode sumbernya di golang dapat dilihat dengan mengikuti tautan . Daemon Docker menggunakan containerd untuk menjalankan beberapa layanannya, dan Kubernetes memiliki plugin untuk menggunakan containerd secara langsung. Oleh karena itu, kami berharap ekstensi kami untuk mendukung gambar kontainer terenkripsi akan berguna untuk keduanya.
Implementasi enkripsi multilevel menggunakan LEK berada pada level arsitektur ekstensi yang paling rendah. Salah satu persyaratan implementasi adalah untuk mengakomodasi lapisan volumetrik beberapa gigabyte sambil menjaga jumlah memori yang ditempati oleh proses yang melakukan operasi kriptografi pada lapisan yang hanya berukuran beberapa megabyte.
Dukungan untuk algoritma enkripsi terotentikasi di Golang mengambil array byte sebagai input dan melakukan seluruh tahap mengenkripsi (menyegel) atau mendekripsi (membuka), mencegah transfer dan penambahan array tambahan ke aliran. Karena API kripto ini memerlukan pemuatan seluruh lapisan ke dalam memori atau menciptakan beberapa skema untuk mengubah vektor inisialisasi (IV) untuk setiap blok, kami memutuskan untuk tidak menggunakan enkripsi terautentikasi golang dengan dukungan data tertaut (AEAD). Sebagai gantinya, kami menggunakan pustaka crypto golang jahat yang mendukung AEAD pada aliran(blok) dan menerapkan skema sendiri untuk mengubah IV di setiap blok. Dalam implementasinya, kami membagi layer menjadi blok 1 MB, yang kami transfer satu per satu untuk enkripsi. Pendekatan ini mengurangi jumlah memori saat menggunakan cipher yang diautentikasi. Di sisi dekripsi, kami melakukan yang sebaliknya dan memperhatikan kesalahan yang dikembalikan oleh fungsi Open () untuk memastikan bahwa blok enkripsi tidak dirusak.
Di atas enkripsi simetris, skema kriptografi asimetris mengenkripsi LEK dan vektor inisialisasi (IV). Untuk menambah atau menghapus skema kriptografi, kami mendaftarkan setiap implementasi kriptografi asimetris. Ketika Asymmetric Cryptographic Code API dipanggil untuk mengenkripsi lapisan, kita memanggil penangan kriptografi terdaftar satu per satu, meneruskan kunci publik penerima. Setelah semua kunci penerima digunakan untuk enkripsi, kami kembali ke peta anotasi dengan pengidentifikasi cryptoalgorithm asimetris sebagai kunci pemetaan dan dengan nilai yang berisi pesan yang dienkode dalam OpenPGP, JWE, dan PKCS # 7. Setiap pesan berisi LEK dan IV yang dikemas. Peta anotasi disimpan dalam dokumen manifes seperti yang ditunjukkan pada tangkapan layar sebelumnya.
Kami juga dapat menambahkan penerima ke gambar yang sudah dienkripsi. Penulis gambar menambahkan penerima jika mereka ada dalam daftar. Kunci pribadi digunakan untuk daftar penerima, yang diperlukan untuk membongkar tingkat LEK dan IV. Kami kemudian mengemas LEK dan IV ke dalam pesan baru menggunakan kunci penerima baru dan menambahkan pesan ini ke peta anotasi.
Kami telah menggunakan tiga jenis skema enkripsi asimetris untuk berbagai jenis kunci. Kami menggunakan kunci OpenPGP untuk mengenkripsi pesan OpenPGP. PKCS # 7 yang kami gunakan membutuhkan sertifikat x.509 untuk kunci enkripsi. JWE menangani semua jenis kunci lainnya seperti kunci RSA sederhana, kurva elips, dan kunci simetris. Kami telah membuat prototipe ekstensi untuk JWE yang memungkinkan operasi kriptografi menggunakan kunci yang dikelola oleh server KMIP.
Runtime penampung menyertakan alat klien ctr untuk berinteraksi dengannya. Kami memperluas ctr untuk mengaktifkan pengujian perubahan kami dan memberikan akses ke pengguna kontainer. ctr sudah mengimplementasikan subperintah yang mendukung operasi gambar, seperti berinteraksi dengan registri gambar dengan mengambil dan mengirimkan gambar.
Kami telah memperluas subperintah ini dengan menambahkan fungsionalitas untuk mengenkripsi gambar dan mengaktifkan enkripsi lapisan tertentu dari arsitektur tertentu menggunakan sekumpulan kunci tertentu. Pendekatan ini memungkinkan pengguna untuk mengenkripsi hanya lapisan yang berisi data sensitif dan membiarkan lapisan lain tidak terenkripsi. Yang terakhir dapat dideduplikasi, tetapi ini hampir tidak mungkin untuk lapisan terenkripsi.
Demikian juga, kita dapat menguraikan lapisan individu dari masing-masing arsitektur. Kami telah menambahkan subperintah layerinfo yang menunjukkan status enkripsi setiap lapisan dan menampilkan teknologi enkripsi yang digunakan untuk itu. Untuk OpenPGP, kami juga dapat menampilkan id kunci yang diperlukan untuk dekripsi, atau mengonversinya ke alamat email penerima menggunakan keyring.
Selain itu, Anda dapat mengekspor dan mengimpor gambar container. Kami telah menerapkan dukungan untuk enkripsi lapisan pada ekspor dan dekripsi pada impor. Meskipun kami mendekripsi lapisan untuk membuat sistem file rootf penampung, lapisan terenkripsi dan file metadata asli seperti manifesnya dipertahankan. Pendekatan ini memungkinkan Anda mengekspor gambar terenkripsi dan melakukan pemeriksaan otorisasi saat pengguna ingin memulai penampung dengan gambar terenkripsi.
Saat gambar biasa (tidak terenkripsi) diambil dari registri, maka secara otomatis akan dibuka dan dibuka ritsletingnya sehingga kontainer dapat segera dibuat darinya. Untuk mempermudah gambar yang dienkripsi, kami sarankan Anda memberikan kunci pribadi ke tim pembongkaran sehingga mereka dapat mendekripsi lapisan sebelum membongkar. Jika gambar dienkripsi dengan beberapa kunci, beberapa kunci dapat diteruskan ke perintah tarik. Transfer ini juga didukung. Setelah berhasil mengekstrak gambar terenkripsi dari registri, siapa pun yang memiliki akses ke penampung dapat membuat penampung dari gambar. Untuk mengonfirmasi bahwa pengguna memiliki hak untuk menggunakan gambar kontainer, kami menyarankan agar dia memberikan kunci privat yang digunakan untuk mendekripsi kontainer.Kami menggunakan kunci untuk memeriksa otorisasi pengguna, apakah mereka dapat digunakan untuk mendekripsi LEK dari setiap level terenkripsi, dan jika ini dikonfirmasi, kami mengizinkan penampung untuk memulai.
Panduan langkah demi langkah untuk enkripsi menggunakan containerd
Di bagian ini, kami akan mendemonstrasikan langkah-langkah enkripsi yang diterapkan dengan containderd menggunakan ctr pada baris perintah. Kami akan menunjukkan cara mengenkripsi dan mendekripsi gambar container.
Pertama-tama, Anda perlu mengkloning repositori git containerd / imgcrypt , yang merupakan subproyek dan dapat mengenkripsi / mendekripsi gambar container. Kemudian Anda perlu membangun penampung dan menjalankannya. Untuk menyelesaikan langkah-langkah ini, Anda perlu mengetahui bagaimana lingkungan pengembangan golang diatur:
imgcrypt membutuhkan containerd versi 1.3 atau yang lebih tinggi.
Bangun dan instal imgcrypt:
# make
# sudo make installJalankan containerd dengan file konfigurasi yang terlihat pada contoh di bawah ini. Untuk menghindari konflik di containerd, gunakan direktori / tmp untuk direktori. Juga membangun containerd versi 1.3 dari sumber, tapi jangan menginstalnya.
# cat config.toml
disable_plugins = ["cri"]
root = "/tmp/var/lib/containerd"
state = "/tmp/run/containerd"
[grpc]
address = "/tmp/run/containerd/containerd.sock"
uid = 0
gid = 0
[stream_processors]
[stream_processors."io.containerd.ocicrypt.decoder.v1.tar.gzip"]
accepts = ["application/vnd.oci.image.layer.v1.tar+gzip+encrypted"]
returns = "application/vnd.oci.image.layer.v1.tar+gzip"
path = "/usr/local/bin/ctd-decoder"
[stream_processors."io.containerd.ocicrypt.decoder.v1.tar"]
accepts = ["application/vnd.oci.image.layer.v1.tar+encrypted"]
returns = "application/vnd.oci.image.layer.v1.tar"
path = "/usr/local/bin/ctd-decoder"
# sudo ~/src/github.com/containerd/containerd/bin/containerd -c config.tomlBuat pasangan kunci RSA menggunakan alat baris perintah openssl dan enkripsi gambar:
# openssl genrsa --out mykey.pem
Generating RSA private key, 2048 bit long modulus (2 primes)
...............................................+++++
............................+++++
e is 65537 (0x010001)
# openssl rsa -in mykey.pem -pubout -out mypubkey.pem
writing RSA key
# sudo chmod 0666 /tmp/run/containerd/containerd.sock
# CTR="/usr/local/bin/ctr-enc -a /tmp/run/containerd/containerd.sock"
# $CTR images pull --all-platforms docker.io/library/bash:latest
[...]
# $CTR images layerinfo --platform linux/amd64 docker.io/library/bash:latest
# DIGEST PLATFORM SIZE ENCRYPTION RECIPIENTS
0 sha256:9d48c3bd43c520dc2784e868a780e976b207cbf493eaff8c6596eb871cbd9609 linux/amd64 2789669
1 sha256:7dd01fd971d4ec7058c5636a505327b24e5fc8bd7f62816a9d518472bd9b15c0 linux/amd64 3174665
2 sha256:691cfbca522787898c8b37f063dd20e5524e7d103e1a3b298bd2e2b8da54faf5 linux/amd64 340
# $CTR images encrypt --recipient jwe:mypubkey.pem --platform linux/amd64 docker.io/library/bash:latest bash.enc:latest
Encrypting docker.io/library/bash:latest to bash.enc:latest
$ $CTR images layerinfo --platform linux/amd64 bash.enc:latest
# DIGEST PLATFORM SIZE ENCRYPTION RECIPIENTS
0 sha256:360be141b01f69b25427a9085b36ba8ad7d7a335449013fa6b32c1ecb894ab5b linux/amd64 2789669 jwe [jwe]
1 sha256:ac601e66cdd275ee0e10afead03a2722e153a60982122d2d369880ea54fe82f8 linux/amd64 3174665 jwe [jwe]
2 sha256:41e47064fd00424e328915ad2f7f716bd86ea2d0d8315edaf33ecaa6a2464530 linux/amd64 340 jwe [jwe]Mulai registri gambar lokal Anda sehingga Anda dapat mengunggah gambar yang dienkripsi ke dalamnya. Untuk menerima gambar container terenkripsi, Anda memerlukan versi registry terbaru.
# docker pull registry:latest
# docker run -d -p 5000:5000 --restart=always --name registry registryUnggah gambar terenkripsi ke registri lokal Anda, ekstrak menggunakan ctr-enc, lalu jalankan gambar:
# $CTR images tag bash.enc:latest localhost:5000/bash.enc:latest
# $CTR images push localhost:5000/bash.enc:latest
# $CTR images rm localhost:5000/bash.enc:latest bash.enc:latest
# $CTR images pull localhost:5000/bash.enc:latest
# sudo $CTR run --rm localhost:5000/bash.enc:latest test echo 'Hello World!'
ctr: you are not authorized to use this image: missing private key needed for decryption
# sudo $CTR run --rm --key mykey.pem localhost:5000/bash.enc:latest test echo 'Hello World!'
Hello World!Kesimpulan
Mengenkripsi gambar kontainer adalah tambahan yang baik untuk keamanannya, ini memastikan kerahasiaan data dan integritas gambar kontainer di lokasi penyimpanan. Teknologi yang diusulkan didasarkan pada RSA yang tersedia untuk umum, kurva elips dan teknologi enkripsi AES. Ini menerapkan kunci ke skema enkripsi tingkat yang lebih tinggi seperti OpenPGP, JWE, dan PKCS # 7. Jika Anda tahu cara bekerja dengan OpenPGP, Anda dapat mengenkripsi gambar kontainer untuk penerima OpenPGP menggunakan alamat email mereka, sementara kunci RSA sederhana dan kurva elips digunakan untuk enkripsi seperti JWE.