Kebijakan keamanan untuk Kontainer Rahasia di Azure Kubernetes Service

Seperti yang dijelaskan oleh Confidential Computing Consortium (CCC), "Confidential Computing adalah perlindungan data yang digunakan dengan melakukan komputasi di Trusted Execution Environment (TEE) berbasis perangkat keras yang dibuktikan. Kontainer Rahasia AKS dirancang untuk melindungi data pod Kubernetes yang digunakan dari akses yang tidak sah dari luar pod ini. Setiap pod dijalankan dalam Utility VM (UVM) yang dilindungi oleh AMD SEV-SNP TEE dengan mengenkripsi data yang digunakan dan mencegah akses ke data oleh Sistem Operasi Host (OS). Teknisi Microsoft berkolaborasi dengan komunitas sumber terbuka Kontainer Rahasia (CoCo) dan Kontainer Kata pada desain dan implementasi Kontainer Rahasia.

Gambaran umum kebijakan keamanan

Salah satu komponen utama arsitektur sistem Kata Containers adalah agen Kata. Saat menggunakan Kontainer Kata untuk mengimplementasikan Kontainer Rahasia, agen dijalankan di dalam TEE berbasis perangkat keras dan oleh karena itu merupakan bagian dari Trusted Computing Base (TCB) pod. Seperti yang ditunjukkan pada diagram berikut, agen Kata menyediakan sekumpulan API ttrpc yang memungkinkan komponen sistem di luar TEE untuk membuat dan mengelola pod Kubernetes berbasis Rahasia. Komponen lain ini (misalnya, Kata Shim) bukan bagian dari TCB pod. Oleh karena itu, agen harus melindungi dirinya dari panggilan API yang berpotensi buggy atau berbahaya.

Dalam Kontainer Rahasia AKS, perlindungan mandiri API agen Kata diimplementasikan menggunakan kebijakan keamanan (juga dikenal sebagai Kebijakan Agen Kata), yang ditentukan oleh pemilik pod rahasia. Dokumen kebijakan berisi aturan dan data yang sesuai dengan setiap pod, menggunakan bahasa kebijakan Rego standar industri. Penegakan kebijakan di dalam Utility VM (UVM) diterapkan menggunakan Open Policy Agent (OPA) – proyek lulusan Cloud Native Computing Foundation (CNCF).

Konten kebijakan

Kebijakan keamanan menjelaskan semua panggilan ke API ttrpc agen (dan parameter panggilan API ini) yang diharapkan untuk membuat dan mengelola Pod Rahasia. Dokumen kebijakan dari setiap pod adalah file teks, menggunakan bahasa Rego. Ada tiga bagian tingkat tinggi dari dokumen kebijakan.

Data

Data kebijakan khusus untuk setiap pod. Ini berisi, misalnya:

• Daftar Kontainer yang diharapkan dibuat di pod.
• Daftar API yang diblokir oleh kebijakan secara default (karena alasan kerahasiaan).

Contoh data yang disertakan dalam dokumen kebijakan untuk setiap kontainer dalam pod:

• Informasi integritas gambar.
• Perintah dijalankan dalam kontainer.
• Volume dan pemasangan penyimpanan.
• Konteks keamanan eksekusi. Misalnya, apakah sistem file akar bersifat baca-saja?
• Apakah prosesnya diizinkan untuk mendapatkan hak istimewa baru?
• Variabel lingkungan.
• Bidang lain dari konfigurasi runtime kontainer Open Container Initiative (OCI).

Aturan

Aturan kebijakan, yang ditentukan dalam format Rego, dieksekusi oleh OPA untuk setiap panggilan API agen Kata dari luar Utility VM (UVM). Agen menyediakan semua input API ke OPA, dan OPA menggunakan aturan untuk memeriksa apakah input konsisten dengan data kebijakan. Jika aturan dan data kebijakan tidak mengizinkan input API, agen menolak panggilan API dengan mengembalikan pesan kesalahan "diblokir oleh kebijakan". Berikut adalah beberapa contoh aturan:

• Setiap lapisan kontainer diekspos sebagai perangkat blok virtio baca-saja ke Utility VM (UVM). Integritas perangkat blok tersebut dilindungi menggunakan teknologi dm-verity dari kernel Linux. Nilai akar yang diharapkan dari pohon hash dm-verity disertakan dalam data kebijakan, dan diverifikasi pada runtime oleh aturan kebijakan.
• Aturan menolak pembuatan Kontainer saat baris perintah yang tidak terduga, pemasangan penyimpanan, konteks keamanan eksekusi, atau variabel lingkungan terdeteksi.

Secara default, aturan kebijakan umum untuk semua pod. Alat genpolicy menghasilkan data kebijakan dan khusus untuk setiap pod.

Nilai default

Saat mengevaluasi aturan Rego menggunakan data kebijakan dan input API sebagai parameter, OPA mencoba menemukan setidaknya satu set aturan yang mengembalikan true nilai berdasarkan data input. Jika aturan tidak mengembalikan true, OPA kembali ke agen, nilai default untuk API tersebut. Contoh nilai default dari Kebijakan:

• default CreateContainerRequest := false – berarti bahwa setiap panggilan API CreateContainer ditolak kecuali sekumpulan aturan Kebijakan secara eksplisit mengizinkan panggilan tersebut.

• default GuestDetailsRequest := true – berarti bahwa panggilan dari luar TEE ke GUESTDetails API selalu diizinkan karena data yang dikembalikan oleh API ini tidak sensitif untuk kerahasiaan beban kerja pelanggan.

Mengirim kebijakan ke agen Kata

Semua VM Utilitas Kontainer Rahasia (UVM) AKS dimulai menggunakan kebijakan default generik yang disertakan dalam sistem file akar Utility VM (UVM). Oleh karena itu, Kebijakan yang cocok dengan beban kerja pelanggan aktual harus diberikan kepada agen pada waktu proses. Teks kebijakan disematkan dalam file manifes YAML Anda seperti yang dijelaskan sebelumnya, dan disediakan cara ini kepada agen lebih awal selama inisialisasi Utility VM (UVM). Anotasi kebijakan melakukan perjalanan melalui komponen kubelet, kontainer, dan shim Kata dari sistem Kontainer Rahasia AKS. Kemudian agen yang bekerja sama dengan OPA memberlakukan kebijakan untuk semua panggilan ke API sendiri.

Kebijakan ini disediakan menggunakan komponen yang bukan bagian dari TCB Anda, jadi awalnya kebijakan ini tidak tepercaya. Kepercayaan kebijakan harus ditetapkan melalui Pengesahan Jarak Jauh, seperti yang dijelaskan di bagian berikut.

Membangun kepercayaan dalam dokumen kebijakan

Sebelum membuat VM Utilitas (UVM), kata shim menghitung hash SHA256 dari dokumen Kebijakan dan melampirkan nilai hash tersebut ke TEE. Tindakan itu menciptakan pengikatan yang kuat antara konten Kebijakan dan Utilitas VM (UVM). Bidang TEE ini tidak dapat dimodifikasi nanti oleh perangkat lunak yang dijalankan di dalam Utility VM (UVM), atau di luarnya.

Setelah menerima kebijakan, agen memverifikasi hash kebijakan yang cocok dengan bidang TEE yang tidak dapat diubah. Agen menolak Kebijakan masuk jika mendeteksi ketidakcocokan hash.

Sebelum menangani informasi sensitif, beban kerja Anda harus melakukan langkah-langkah Pengesahan Jarak Jauh untuk membuktikan kepada Pihak yang Mengandalkan bahwa beban kerja dijalankan menggunakan versi tee, OS, agen, OPA, dan versi sistem file root yang diharapkan. Pengesahan diimplementasikan dalam Kontainer yang berjalan di dalam Utility VM (UVM) yang mendapatkan bukti pengesahan yang ditandatangani dari perangkat keras AMD SEV-SNP. Salah satu bidang dari bukti pengesahan adalah bidang TEE hash kebijakan yang dijelaskan sebelumnya. Oleh karena itu, layanan Pengesahan dapat memverifikasi integritas kebijakan, dengan membandingkan nilai bidang ini dengan hash yang diharapkan dari kebijakan pod.

Pemberlakuan kebijakan

Agen Kata bertanggung jawab untuk menegakkan kebijakan. Microsoft berkontribusi pada komunitas Kata dan CoCo kode agen yang bertanggung jawab untuk memeriksa kebijakan untuk setiap panggilan API ttrpc agen. Sebelum melakukan tindakan yang sesuai dengan API, agen menggunakan OPA REST API untuk memeriksa apakah aturan kebijakan dan data mengizinkan atau memblokir panggilan.

Langkah berikutnya

Menyebarkan kontainer rahasia di AKS