Share via

Kontainer Rahasia (pratinjau) dengan Azure Kubernetes Service (AKS)

  • Artikel

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 Rahasia (pratinjau) di AKS.

Kontainer Rahasia dibangun pada Kontainer Rahasia Kata dan enkripsi berbasis perangkat keras untuk mengenkripsi memori kontainer. 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 apa termasuk OS Tamu Linux dan semua komponen saat ini. Microsoft menandatangani ke OS tamu dan lingkungan runtime kontainer untuk verifikasi melalui pengesahan. Ini juga merilis algoritma hash aman (SHA) build OS tamu untuk membangun audibilitas string dan cerita 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 pengerasan akses sarana 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 dijalankan sebagai kontainer rahasia
  • Menambahkan kebijakan keamanan ke YAML pod Anda
  • Mengaktifkan penegakan kebijakan keamanan
  • Menyebarkan aplikasi Anda dalam komputasi rahasia

Skenario yang didukung

Kontainer Rahasia (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 pelari GitHub yang dihost sendiri untuk menandatangani kode dengan aman sebagai bagian dari praktik DevOps Integrasi Berkelanjutan 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 terisolasi kernel.
  • Gambar kontainer versi 1 tidak didukung.
  • Pembaruan pada rahasia dan Konfigurasi Peta tidak tercermin dalam tamu.
  • Kontainer sementara dan metode pemecahan masalah lainnya seperti exec ke dalam kontainer, output log dari kontainer, dan stdio (ReadStreamRequest dan WriteStreamRequest) memerlukan modifikasi dan penyebaran ulang kebijakan.
  • Alat generator kebijakan tidak mendukung jenis penyebaran cronjob.
  • 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.
  • Semua kontainer di semua pod pada kluster harus dikonfigurasi ke imagePullPolicy: Always.
  • Generator kebijakan hanya mendukung pod yang menggunakan alamat IPv4.
  • Nilai konfigurasi Peta dan rahasia tidak dapat diubah jika pengaturan menggunakan metode variabel lingkungan setelah pod disebarkan. Kebijakan keamanan mencegahnya.
  • 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 tamu ke file tersebut tidak tercermin pada host.

Gambaran umum alokasi sumber daya

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

  • CPU: Shim menetapkan satu vCPU ke OS dasar di dalam pod. Jika tidak ada sumber daya limits yang ditentukan, beban kerja tidak memiliki berbagi CPU terpisah yang ditetapkan, vCPU kemudian dibagikan dengan beban kerja tersebut. Jika batas CPU ditentukan, berbagi CPU secara eksplisit dialokasikan 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. Kontainer Kata mengabaikan permintaan sumber daya dari manifes YAML pod, dan sebagai hasilnya, containerd tidak meneruskan permintaan ke shim. Gunakan sumber daya limit 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

  • Lihat gambaran umum kebijakan keamanan Kontainer Rahasia untuk mempelajari tentang bagaimana beban kerja dan datanya dalam pod dilindungi.
  • Sebarkan Kontainer Rahasia di AKS dengan kebijakan keamanan default.
  • Pelajari selengkapnya tentang host Azure Dedicated untuk simpul dengan kluster AKS Anda untuk menggunakan isolasi dan kontrol perangkat keras atas peristiwa pemeliharaan platform Azure.