Kontainer Terenkripsi (pratinjau) dengan Layanan Azure Kubernetes (AKS)

Penting

Pratinjau Kontainer Rahasia akan dihentikan pada Maret 2026. Setelah tanggal ini, pelanggan dengan kumpulan simpul Kontainer Rahasia yang ada harus mengharapkan penurunan fungsi, dan Anda tidak akan dapat menambahkan simpul baru apa pun dengan KataCcIsolation runtime. Pelanggan yang saat ini menggunakan kumpulan simpul Kontainer Rahasia dapat terus menggunakannya seperti biasa. Jika Anda ingin memindahkan Kontainer Rahasia, pertimbangkan alternatif berikut:

  • VM Rahasia pada AKS: Menawarkan TEE berbasis perangkat keras serupa yang memanfaatkan fitur keamanan AMD SEV-SNP, tanpa penambahan isolasi per VM untuk beban kerja yang terlihat di Kontainer Rahasia.
  • Dukungan enklave aplikasi: Memberi pengguna simpul VM komputasi rahasia Intel SGX yang mendukung isolasi kontainer tingkat proses berbasis perangkat keras melalui lingkungan eksekusi tepercaya Intel SGX.
  • Kontainer Rahasia pada Azure Container Instances: Memungkinkan pemindahan dan pengoperasian pada kontainer berbasis AMD SEV-SNP. Fungsionalitas termasuk melakukan attestasi tamu lengkap, akses ke alat untuk membuat kebijakan, dan menggunakan kontainer sidecar untuk rilis kunci yang aman. Simpul ACI dapat dijalankan pada AKS melalui simpul virtual.
  • Kontainer Rahasia Azure RedHat OpenShift: Menawarkan TEE yang didukung SEV-SNP AMD serupa dan menggunakan runtime Kata untuk isolasi tingkat per kontainer.
  • Kontainer Rahasia Sumber Terbuka: Memberikan TEE yang didukung AMD SEV-SNP yang sejenis dengan dilengkapi isolasi per kontainer melalui Kata.

Jika Anda memiliki pertanyaan tambahan, buat permintaan dukungan atau posting masalah dalam masalah AKS.

Kontainer Rahasia menyediakan serangkaian fitur dan kemampuan untuk lebih mengamankan beban kerja kontainer standar Anda untuk mencapai tujuan keamanan data, privasi data, dan integritas kode runtime yang lebih tinggi. Azure Kubernetes Service (AKS) mencakup Kontainer Konfidensial (pratinjau) di AKS.

Container Rahasia dibangun di atas Kata Confidential Containers dan enkripsi berbasis perangkat keras untuk mengenkripsi memori container. Ini menetapkan tingkat kerahasiaan data baru dengan mencegah data dalam memori selama komputasi berada dalam teks yang jelas, format yang dapat dibaca. Kepercayaan diperoleh dalam kontainer melalui pengesahan perangkat keras, memungkinkan akses ke data terenkripsi oleh entitas tepercaya.

Bersama dengan Pod Sandboxing, Anda dapat menjalankan beban kerja sensitif yang terisolasi di Azure untuk melindungi data dan beban kerja Anda. Apa yang membuat kontainer rahasia:

  • Transparansi: Lingkungan kontainer rahasia tempat aplikasi sensitif Anda dibagikan, Anda dapat melihat dan memverifikasi apakah aman. Semua komponen Basis Komputasi Tepercaya (TCB) harus sumber terbuka d.
  • Auditabilitas: Anda memiliki kemampuan untuk memverifikasi dan melihat versi paket lingkungan CoCo termasuk OS Tamu Linux dan semua komponen yang sedang digunakan saat ini. Microsoft mengenkripsi pada OS tamu dan lingkungan runtime kontainer untuk melakukan verifikasi melalui atestasi. Ini juga merilis algoritma hash aman (SHA) dari build tamu OS untuk membangun narasi visibilitas string dan kontrol.
  • Pengesahan penuh: Apa pun yang merupakan bagian dari TEE harus sepenuhnya diukur oleh CPU dengan kemampuan untuk memverifikasi dari jarak jauh. Laporan perangkat keras dari prosesor AMD SEV-SNP harus mencerminkan lapisan kontainer dan hash konfigurasi runtime kontainer melalui klaim pengesahan. Aplikasi dapat mengambil laporan perangkat keras secara lokal termasuk laporan yang mencerminkan gambar OS Tamu dan runtime kontainer.
  • Integritas kode: Penerapan runtime selalu tersedia melalui kebijakan yang ditentukan pelanggan untuk kontainer dan konfigurasi kontainer, seperti kebijakan yang tidak dapat diubah dan penandatanganan kontainer.
  • Isolasi dari operator: Desain keamanan yang mengasumsikan hak istimewa paling sedikit dan perisai isolasi tertinggi dari semua pihak yang tidak tepercaya termasuk admin pelanggan/penyewa. Ini termasuk mengamankan akses pesawat kontrol Kubernetes yang ada (kubelet) ke pod rahasia.

Dengan langkah-langkah keamanan atau kontrol perlindungan data lainnya, sebagai bagian dari arsitektur Anda secara keseluruhan, kemampuan ini membantu Anda memenuhi persyaratan kepatuhan peraturan, industri, atau tata kelola untuk mengamankan informasi sensitif.

Artikel ini membantu Anda memahami fitur Kontainer Rahasia, dan cara mengimplementasikan dan mengonfigurasi hal berikut:

  • Menyebarkan atau meningkatkan kluster AKS menggunakan Azure CLI
  • Tambahkan anotasi ke YAML pod Anda untuk menandai pod sebagai kontainer aman.
  • Menambahkan kebijakan keamanan ke YAML pod Anda
  • Menyebarkan aplikasi Anda dalam komputasi rahasia

Penting

Mulai 30 November 2025, Azure Kubernetes Service (AKS) tidak lagi mendukung atau menyediakan pembaruan keamanan untuk Azure Linux 2.0. Gambar node Azure Linux 2.0 dibekukan pada rilis 202512.06.0. Mulai tanggal 31 Maret 2026, gambar simpul akan dihapus, dan Anda tidak akan dapat menskalakan kumpulan simpul Anda. Migrasikan ke versi Linux Azure yang didukung dengan meningkatkan kumpulan simpul Anda ke versi Kubernetes yang didukung atau bermigrasi ke osSku AzureLinux3. Untuk informasi selengkapnya, lihat masalah Penghentian GitHub dan pengumuman penghentian Pembaruan Azure. Untuk tetap mendapatkan informasi tentang pengumuman dan pembaruan, ikuti catatan rilis AKS.

Skenario yang didukung

Kontainer Rahasia (versi pratinjau) sesuai untuk skenario penyebaran yang melibatkan data sensitif. Misalnya, informasi pengidentifikasi pribadi (PII) atau data apa pun dengan keamanan kuat yang diperlukan untuk kepatuhan terhadap peraturan. Beberapa skenario umum dengan kontainer adalah:

  • Jalankan analitik big data menggunakan Apache Spark untuk pengenalan pola penipuan di sektor keuangan.
  • Menjalankan runner GitHub yang dihosting sendiri untuk menandatangani kode dengan aman sebagai bagian dari praktik DevOps Integrasi dan Penyebaran Berkelanjutan (CI/CD).
  • Pembelajaran Mesin inferensi dan pelatihan model ML menggunakan himpunan data terenkripsi dari sumber tepercaya. Ini hanya mendekripsi di dalam lingkungan kontainer rahasia untuk menjaga privasi.
  • Membangun ruang bersih big data untuk pencocokan ID sebagai bagian dari komputasi multi-pihak di industri seperti ritel dengan iklan digital.
  • Membangun zona pendaratan Zero Trust komputasi rahasia untuk memenuhi peraturan privasi untuk migrasi aplikasi ke cloud.

Pertimbangan

Berikut ini adalah pertimbangan dengan pratinjau Kontainer Rahasia ini:

  • Peningkatan waktu startup pod dibandingkan dengan pod runc dan pod yang diisolasi oleh kernel.
  • Gambar kontainer versi 1 tidak didukung.
  • Kontainer sementara dan metode pemecahan masalah lainnya seperti exec ke dalam kontainer, output log dari kontainer, dan stdio memerlukan modifikasi dan penyebaran ulang kebijakan untuk mengaktifkan ExecProcessRequest, ReadStreamRequest, WriteStreamRequest, dan CloseStdinRequest.
  • Karena pengukuran lapisan gambar kontainer yang dikodekan dalam kebijakan keamanan, kami tidak menyarankan penggunaan latest tag saat menentukan kontainer.
  • Layanan, Load Balancer, dan EndpointSlice hanya mendukung protokol TCP.
  • Generator kebijakan hanya mendukung pod yang menggunakan alamat IPv4.
  • Variabel lingkungan pod berdasarkan ConfigMaps dan Secrets tidak dapat diubah setelah pod disebarkan.
  • Log penghentian pod tidak didukung. Saat pod menulis log penghentian ke /dev/termination-log atau ke lokasi kustom jika ditentukan dalam manifes pod, host/kubelet tidak dapat membaca log tersebut. Perubahan dari pod ke file tersebut tidak tercermin pada host.
  • Kontainer Rahasia saat ini hanya mendukung Azure Linux.

Gambaran umum alokasi sumber daya

Penting untuk memahami perilaku alokasi sumber daya memori dan prosesor dalam rilis ini.

  • CPU: Shim menetapkan satu vCPU ke sistem operasi dasar di dalam pod. Jika tidak ada sumber daya limits yang ditentukan, beban kerja tidak memiliki bagian CPU terpisah yang ditetapkan, vCPU kemudian digunakan bersama dengan beban kerja tersebut. Jika batas CPU ditentukan, alokasi CPU secara eksplisit diberikan untuk beban kerja.
  • Memori: Handler Kata-CC menggunakan memori 2 GB untuk OS UVM dan memori tambahan X MB di mana X adalah sumber daya limits jika ditentukan dalam manifes YAML (menghasilkan VM 2 GB ketika tidak ada batas yang diberikan, tanpa memori implisit untuk kontainer). Handler Kata menggunakan memori dasar 256 MB untuk OS UVM dan memori tambahan X MB ketika sumber daya limits ditentukan dalam manifes YAML. Jika batas tidak ditentukan, batas implisit 1.792 MB ditambahkan menghasilkan VM 2 GB dan memori implisit 1.792 MB untuk kontainer.

Dalam rilis ini, menentukan permintaan sumber daya dalam manifes pod tidak didukung. containerd tidak meneruskan permintaan ke Kata Shim, dan akibatnya, pemesanan sumber daya berdasarkan permintaan pada manifes pod tidak diimplementasikan. Gunakan sumber daya limits alih-alih sumber daya requests untuk mengalokasikan memori atau sumber daya CPU untuk beban kerja atau kontainer.

Dengan sistem file kontainer lokal yang didukung oleh memori VM, menulis ke sistem file kontainer (termasuk pengelogan) dapat mengisi memori yang tersedia yang disediakan untuk pod. Kondisi ini dapat mengakibatkan potensi crash pod.

Langkah berikutnya

  • Last updated on