Bagikan melalui

Konsep keamanan untuk aplikasi dan kluster di Azure Kubernetes Service (AKS)

Keamanan kontainer melindungi seluruh rangkaian proses end-to-end dari pembangunan hingga pekerjaan aplikasi yang berjalan di Azure Kubernetes Service (AKS).

Rantai Pasokan Aman mencakup lingkungan pengembangan dan registri.

Kubernetes mencakup komponen keamanan, seperti standar keamanan pod dan Rahasia. Azure menyertakan komponen seperti Direktori Aktif, Pertahanan Microsoft untuk Kontainer, Azure Policy, Azure Key Vault, grup keamanan jaringan, dan peningkatan kluster yang diorkestrasi. AKS menggabungkan komponen keamanan ini untuk:

  • Berikan kisah autentikasi dan otorisasi lengkap.
  • Terapkan Azure Policy Bawaan AKS untuk mengamankan aplikasi Anda.
  • Pandangan menyeluruh mulai dari pembangunan hingga aplikasi Anda dengan Microsoft Defender for Containers.
  • Jaga agar kluster AKS anda tetap menjalankan pembaruan keamanan OS terbaru dan rilis Kubernetes.
  • Berikan lalu lintas pod yang aman dan akses ke kredensial sensitif.

Artikel ini memperkenalkan konsep inti yang mengamankan aplikasi Anda di AKS.

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.

Keamanan Pembangunan

Sebagai titik masuk untuk rantai pasok, penting untuk melakukan analisis statis pembangunan citra sebelum dipromosikan ke dalam alur kerja. Ini termasuk penilaian kerentanan dan kepatuhan. Ini bukan tentang gagal membangun karena memiliki kerentanan, karena itu memutus pengembangan. Ini tentang melihat Status Vendor untuk menyegmentasikan berdasarkan kerentanan yang dapat ditangani oleh tim pengembangan. Gunakan juga Masa Tenggang untuk memberikan waktu kepada pengembang agar dapat memulihkan masalah yang diidentifikasi.

Keamanan Registri

Menilai status kerentanan gambar di Registri mendeteksi penyimpangan dan juga menangkap gambar yang tidak berasal dari lingkungan build Anda. Gunakan Notary V2 untuk melampirkan tanda tangan ke gambar Anda untuk memastikan penyebaran berasal dari lokasi tepercaya.

Keamanan klaster

Dalam AKS, komponen master Kubernetes merupakan bagian dari layanan terkelola yang disediakan, dikelola, dan dipelihara oleh Microsoft. Setiap kluster AKS memiliki master Kubernetes yang berbasis tenant tunggal untuk menyediakan API Server, Scheduler, dan lainnya. Untuk informasi selengkapnya, lihat Manajemen kerentanan untuk Azure Kubernetes Service.

Secara default, server API Kubernetes menggunakan alamat IP publik dan nama domain yang sepenuhnya memenuhi syarat (FQDN). Anda dapat membatasi akses ke titik akhir server API menggunakan rentang IP resmi. Anda juga dapat membuat kluster privat sepenuhnya untuk membatasi akses server API ke jaringan virtual Anda.

Anda dapat mengontrol akses ke server API menggunakan kontrol akses berbasis peran Kubernetes (Kubernetes RBAC) dan Azure RBAC. Untuk informasi selengkapnya, lihat Integrasi Microsoft Entra dengan AKS.

Keamanan Node

Simpul AKS adalah mesin virtual Azure (VM) yang Anda kelola dan pertahankan.

  • Node Linux menjalankan versi yang dioptimalkan dari Ubuntu atau Azure Linux.
  • Node Windows Server menjalankan rilis Windows Server yang dioptimalkan menggunakan runtime kontainer containerd.

Ketika kluster AKS dibuat atau skalanya ditingkatkan, node secara otomatis diluncurkan dengan pembaruan keamanan OS terbaru dan konfigurasi.

Catatan

Kluster AKS yang sedang berjalan atau aktif:

  • Kubernetes versi 1.19 dan yang lebih tinggi - Kumpulan simpul Linux menggunakan containerd sebagai runtime kontainernya. Kumpulan simpul Windows Server 2019 dan Windows Server 2022 digunakan containerd sebagai runtime kontainernya. Untuk informasi selengkapnya, lihat Menambahkan kumpulan simpul Windows Server dengan containerd.
  • Kubernetes versi 1.19 dan yang lebih lama - Kumpulan simpul Linux menggunakan Docker sebagai runtime kontainernya.

Untuk informasi selengkapnya tentang proses upgrade keamanan untuk node pekerja Linux dan Windows, lihat Menambal keamanan node.

Kluster AKS yang menjalankan VM Azure Generasi 2 menyertakan dukungan untuk Peluncuran Tepercaya. Fitur ini melindungi dari teknik serangan tingkat lanjut dan persisten dengan menggabungkan teknologi yang dapat Anda aktifkan secara independen, seperti boot aman dan versi virtual modul platform tepercaya (vTPM). Administrator dapat menyebarkan simpul pekerja AKS dengan bootloader terverifikasi dan ditandatangani, kernel OS, dan driver untuk memastikan integritas seluruh rantai boot VM yang mendasar.

Opsi Sistem Operasi yang dioptimalkan untuk kontainer dan keamanan

AKS merilis dukungan untuk dua opsi OS Linux baru yang dioptimalkan. Azure Linux OS Guard (pratinjau) adalah buatan Microsoft dan dioptimalkan untuk Azure. OS Guard dibangun di atas Azure Linux dengan konfigurasi khusus untuk mendukung beban kerja kontainer dengan pengoptimalan keamanan. Flatcar Container Linux untuk AKS (pratinjau) adalah OS tidak berubah yang dioptimalkan untuk kontainer, berbasis CNCF dan netral vendor, yang paling cocok digunakan di lingkungan multicloud dan lokal. Opsi OS ini memberikan peningkatan keamanan jika dibandingkan dengan opsi OS Linux lainnya, seperti:

  • Azure Linux OS Guard dan Flatcar Container Linux untuk AKS memiliki sistem operasi yang tidak dapat diubah yang tidak dapat Anda ubah saat runtime. Semua biner OS, pustaka, dan konfigurasi statis bersifat baca-saja, dan integritas bit-for-bit sering dilindungi secara kriptografis. Sistem operasi tujuan khusus ini dikirim sebagai gambar mandiri dan datang tanpa jenis manajemen paket atau cara tradisional lainnya untuk mengubah OS. Beban kerja pengguna berjalan di lingkungan terisolasi seperti kontainer, terisolasi dari OS.
  • Azure Linux OS Guard dan Flatcar Container Linux untuk AKS menggunakan SELinux untuk Kontrol Akses Wajib.
  • Azure Linux OS Guard memberlakukan pengaktifan FIPS dan Peluncuran Tepercaya , memberikan peningkatan kepatuhan dan perlindungan terhadap serangan tingkat lanjut dan persisten dengan menggabungkan boot aman dan versi virtual modul platform tepercaya (vTPM).

Saat memutuskan antara opsi OS yang dioptimalkan kontainer mana yang akan digunakan, AKS merekomendasikan hal berikut:

  • Gunakan Flatcar Container Linux untuk AKS (pratinjau) jika Anda mencari OS netral vendor yang tidak dapat diubah dengan dukungan lintas cloud.
  • Gunakan Azure Linux OS Guard (pratinjau) jika Anda mencari OS tidak dapat diubah yang siap untuk digunakan perusahaan, sesuai rekomendasi dari Microsoft.
  • Gunakan Ubuntu jika Anda mencari OS tujuan umum netral vendor dengan dukungan lintas cloud.
  • Gunakan Azure Linux jika Anda mencari OS tujuan umum siap perusahaan, yang direkomendasikan oleh Microsoft.

Cuplikan layar tabel yang membandingkan opsi OS yang dioptimalkan seperti Flatcar Container Linux untuk AKS dan Azure Linux OS Guard dengan opsi OS tujuan umum seperti Ubuntu dan Azure Linux.

Otorisasi node

Otorisasi node adalah mode otorisasi tujuan khusus yang secara khusus mengotorisasi permintaan API kubelet untuk melindungi dari serangan Timur-Barat. Otorisasi node diaktifkan secara default pada kluster AKS 1,24 +.

Penyebaran simpul

Simpul ditempatkan ke subnet jaringan virtual privat, tanpa alamat IP publik yang ditetapkan. Untuk tujuan pemecahan masalah dan manajemen, SSH diaktifkan secara default dan hanya dapat diakses menggunakan alamat IP internal. Menonaktifkan SSH selama pembuatan kluster dan kumpulan simpul, atau untuk kluster atau kumpulan simpul yang ada, saat ini dalam tahap pratinjau. Lihat Mengelola akses SSH untuk informasi selengkapnya.

Penyimpanan simpul

Untuk menyediakan penyimpanan, simpul menggunakan Azure Managed Disks. Untuk sebagian besar ukuran simpul VM, Azure Managed Disks adalah disk Premium yang didukung oleh SSD berkinerja tinggi. Data yang disimpan di disk terkelola secara otomatis dienkripsi saat tidak digunakan dalam platform Azure. Untuk meningkatkan redundansi, Azure Managed Disks direplikasi dengan aman dalam pusat data Azure.

Beban kerja multipenyewa yang bermusuhan

Saat ini, lingkungan Kubernetes tidak aman untuk penggunaan multipenyewa yang bermusuhan. Fitur keamanan ekstra, seperti Kebijakan Keamanan Pod atau Kubernetes RBAC untuk simpul, secara efisien memblokir eksploitasi. Untuk keamanan yang sesungguhnya saat menjalankan beban kerja multipenyewa yang bermusuhan, percayalah hanya pada hypervisor. Domain keamanan untuk Kubernetes menjadi seluruh kluster, bukan simpul individual.

Untuk jenis beban kerja multipenyewa yang bermusuhan ini, Anda harus menggunakan kluster yang terisolasi secara fisik. Untuk informasi selengkapnya tentang cara mengisolasi beban kerja, lihat Praktik terbaik untuk isolasi kluster di AKS.

Isolasi komputasi

Karena kepatuhan atau persyaratan peraturan, beban kerja tertentu mungkin memerlukan isolasi tingkat tinggi dari beban kerja pelanggan lainnya. Untuk beban kerja ini, Azure menyediakan:

  • Kontainer yang terisolasi kernel untuk digunakan sebagai node agen dalam kluster AKS. Kontainer ini sepenuhnya terisolasi ke jenis perangkat keras tertentu dan diisolasi dari fabric Azure Host, sistem operasi host, dan hypervisor. Mereka didedikasikan untuk satu pelanggan. Pilih salah satu ukuran VM yang terisolasi sebagai ukuran simpul saat membuat kluster AKS atau menambahkan kumpulan simpul.
  • Kontainer Rahasia (pratinjau), juga berdasarkan Kontainer Rahasia Kata, mengenkripsi memori kontainer dan mencegah data dalam memori selama komputasi berada dalam format teks yang dapat dibaca, serta mencegah gangguan atau perubahan. Ini membantu mengisolasi kontainer Anda dari grup/pod kontainer lain, serta kernel sistem operasi simpul VM. Kontainer Konfidensial (pratinjau) menggunakan enkripsi memori berbasis perangkat keras (SEV-SNP).
  • Pod Sandboxing (pratinjau) menyediakan batas isolasi antara aplikasi kontainer dan kernel bersama dan sumber daya komputasi (CPU, memori, dan jaringan) dari host kontainer.

Keamanan jaringan

Untuk konektivitas dan keamanan dengan jaringan lokal, Anda dapat menerapkan kluster AKS ke subnet jaringan virtual Azure yang sudah ada. Jaringan virtual ini terhubung kembali ke jaringan lokal Anda menggunakan Azure Site-to-Site VPN atau Express Route. Tentukan kontroler ingress Kubernetes dengan alamat IP internal privat untuk membatasi akses layanan ke koneksi jaringan internal.

Kelompok keamanan jaringan Azure

Untuk memfilter alur lalu lintas jaringan virtual, Azure menggunakan aturan kelompok keamanan jaringan. Aturan ini menentukan rentang IP sumber dan tujuan, port, dan protokol yang diizinkan atau ditolak aksesnya ke sumber daya. Aturan default dibuat untuk memperbolehkan lalu lintas TLS ke server API Kubernetes. Anda membuat layanan dengan penyeimbang beban, pemetaan port, atau rute ingress. AKS secara otomatis memodifikasi kelompok keamanan jaringan untuk alur lalu lintas.

Jika Anda menyediakan subnet Anda sendiri untuk klaster AKS (baik menggunakan Azure CNI atau Kubenet), jangan ubah kelompok keamanan jaringan tingkat subnet yang dikelola oleh AKS. Sebagai gantinya, buat lebih banyak kelompok keamanan jaringan tingkat subnet untuk mengubah alur lalu lintas. Pastikan mereka tidak mengganggu lalu lintas yang diperlukan yang mengelola kluster, seperti akses load balancer, komunikasi dengan sarana kontrol, atau keluar.

Kebijakan jaringan Kubernetes

Untuk membatasi lalu lintas jaringan antar pod di kluster, AKS menawarkan dukungan untuk kebijakan jaringan Kubernetes. Dengan kebijakan jaringan, Anda dapat mengizinkan atau menolak jalur jaringan tertentu dalam kluster berdasarkan namespace dan pemilih label.

Keamanan Aplikasi

Untuk melindungi pod yang berjalan di AKS, pertimbangkan Pertahanan Microsoft untuk Kontainer untuk mendeteksi dan membatasi serangan cyber terhadap aplikasi yang berjalan di pod Anda. Jalankan pemindaian terus-menerus untuk mendeteksi drift dalam keadaan kerentanan aplikasi Anda dan menerapkan proses "biru / hijau / kenari" untuk menambal dan mengganti gambar yang rentan.

Amankan akses kontainer ke sumber daya

Sama halnya dengan prinsip bahwa Anda harus memberikan izin sesedikit mungkin untuk pengguna dan grup, Anda juga harus membatasi kontainer untuk hanya melakukan tindakan dan proses yang benar-benar dibutuhkan. Untuk meminimalkan risiko serangan, hindari konfigurasi aplikasi dan kontainer yang memerlukan eskalasi hak istimewa atau akses root. Fitur keamanan Linux bawaan seperti AppArmor dan seccomp direkomendasikan sebagai praktik terbaik untuk [mengamankan akses kontainer ke sumber daya][secure-container-access].

Rahasia Kubernetes

Dengan Rahasia Kubernetes, Anda menyuntikkan data sensitif ke dalam pod, seperti kredensial atau kunci akses.

  1. Buat Rahasia dengan menggunakan API Kubernetes.
  2. Tentukan pod atau penyebaran Anda serta minta Rahasia tertentu.
    • Rahasia hanya disediakan untuk simpul dengan pod terjadwal yang membutuhkannya.
    • Rahasia disimpan dalam tmpfs, tidak ditulis ke disk.
  3. Ketika Anda menghapus pod terakhir pada simpul yang memerlukan Rahasia, Rahasia dihapus dari tmpfs simpul.
    • Rahasia disimpan dalam namespace layanan tertentu dan hanya dapat diakses dari pod dalam namespace yang sama.

Menggunakan Rahasia mengurangi informasi sensitif yang ditentukan dalam pod atau layanan manifes YAML. Sebagai gantinya, Anda meminta Rahasia yang disimpan di Server API Kubernetes sebagai bagian dari manifes YAML Anda. Pendekatan ini hanya menyediakan akses pod tertentu ke Rahasia.

Catatan

File manifes rahasia mentah berisi data rahasia dalam format base64. Untuk informasi selengkapnya, lihat dokumentasi resmi. Perlakukan file ini sebagai informasi sensitif, dan jangan pernah memasukkannya ke kontrol sumber.

Rahasia Kubernetes disimpan di etcd, penyimpanan nilai kunci terdistribusi. AKS memungkinkan enkripsi di sisa rahasia di etcd menggunakan kunci yang dikelola pelanggan.

Langkah berikutnya

Untuk mulai mengamankan kluster AKS Anda, lihat Meningkatkan kluster AKS.

Untuk praktik terbaik terkait, lihat Praktik terbaik untuk keamanan kluster dan peningkatan versi di AKS dan Praktik terbaik untuk keamanan pod di AKS.

Untuk informasi lebih lanjut mengenai konsep inti Kubernetes dan AKS, lihat:

  • Last updated on