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

Keamanan kontainer melindungi seluruh alur end-to-end dari build ke beban kerja 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 mencakup komponen seperti Microsoft Entra ID, Microsoft Defender untuk Kontainer, Azure Policy, Azure Key Vault, kelompok 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.
  • Wawasan menyeluruh mulai dari proses build hingga aplikasi Anda dengan Microsoft Defender untuk Kontainer.
  • 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.

AKS mendukung dua mode kluster: AKS Automatic dan AKS Standard. Konsep keamanan dalam artikel ini berlaku untuk kedua mode kecuali dinyatakan lain. AKS Otomatis menyertakan garis besar keamanan yang diperkuat dengan beberapa kontrol yang telah dikonfigurasi sebelumnya secara default, sementara AKS Standard memberikan lebih banyak fleksibilitas konfigurasi.

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

Penting

Mulai November 30, 2025, Azure Kubernetes Service (AKS) tidak lagi mendukung atau menyediakan pembaruan keamanan untuk Azure Linux 2.0. Gambar node Linux 2.0 Azure 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 GitHub Retirement dan pengumuman penghentian pembaruan Azure. Untuk tetap mendapatkan informasi tentang pengumuman dan pembaruan, ikuti catatan rilis AKS.

Bangun Keamanan

Keamanan build adalah titik awal bagi rantai pasokan Anda yang aman. Sebelum gambar dipromosikan ke lingkungan penyebaran, jalankan analisis statis dan penilaian kerentanan dan kepatuhan di CI.

Dalam kedua mode AKS, prioritaskan triase berbasis risiko daripada memblokir semua build karena adanya kerentanan apa pun. Prioritaskan remediasi menggunakan status dan tingkat keparahan vendor, dan terapkan masa tenggang untuk pengecualian yang tidak dapat dieksploitasi atau terikat waktu.

AKS Automatic membantu mengurangi drift konfigurasi pada tahap lanjutan dengan membangun kluster dari baseline yang telah diperkuat dengan kontrol keamanan yang sudah dikonfigurasi sebelumnya. Hal ini membuat validasi kualitas image dan kepatuhan terhadap kebijakan pada tahap build menjadi semakin penting, karena image tepercaya lebih konsisten dipromosikan ke baseline runtime yang aman.

AKS Standard memberikan lebih banyak fleksibilitas tingkat kluster, sehingga alur build harus secara eksplisit memberlakukan garis besar organisasi Anda untuk pembuktian gambar, ambang kerentanan, dan gerbang kebijakan sebelum penyebaran.

Keamanan registri

Keamanan registri memastikan bahwa hanya image yang tepercaya dan patuh yang tersedia untuk deployment serta membantu mendeteksi penyimpangan setelah proses build. Menilai status kerentanan gambar dalam registri terus menerus, tidak hanya pada waktu build. Pemindaian registri mendeteksi kerentanan yang baru diungkapkan dan image yang melewati jalur build yang telah disetujui. Gunakan penandatanganan dan verifikasi gambar, seperti Notary V2, untuk memastikan beban kerja disebarkan dari sumber tepercaya dengan bukti yang dapat diverifikasi.

Untuk AKS Otomatis, di mana beberapa kemampuan keamanan runtime telah dikonfigurasi sebelumnya, kontrol registri tetap menjadi gerbang upstream penting untuk menjaga rantai pasokan runtime tetap bersih. Untuk AKS Standard, terapkan kontrol registri yang sama dan selaraskan dengan pendaftaran kluster dan konfigurasi kebijakan Anda untuk menerapkan penggunaan gambar tepercaya secara konsisten.

Keamanan klaster

Di AKS, komponen utama Kubernetes adalah bagian dari layanan terkelola yang disediakan, dikelola, dan dikelola oleh Microsoft. Setiap kluster AKS memiliki Kubernetes utama khusus untuk penyewa tunggal guna menyediakan API Server, Scheduler, dan lain-lain. 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.

Untuk AKS Otomatis, integrasi jaringan virtual server API telah dikonfigurasi sebelumnya sebagai bagian dari postur keamanan default. Di AKS Standard, kemampuan yang sama tersedia dan dapat diaktifkan berdasarkan desain jaringan dan persyaratan keamanan Anda.

Anda dapat mengontrol akses ke server API menggunakan kontrol akses berbasis peran Kubernetes (Kubernetes RBAC) dan Azure RBAC. Di AKS Otomatis, Azure RBAC untuk otorisasi Kubernetes telah dikonfigurasi sebelumnya. Di AKS Standard, Anda dapat memilih dan mengonfigurasi model otorisasi yang paling sesuai dengan lingkungan Anda. Untuk informasi selengkapnya, lihat integrasi Microsoft Entra dengan AKS.

Default keamanan Otomatis AKS

AKS Otomatis menyertakan garis besar yang diperkeras dengan kontrol keamanan yang telah dikonfigurasi sebelumnya secara default, termasuk:

  • Azure RBAC untuk otorisasi Kubernetes
  • Integrasi server API dengan jaringan virtual
  • Identitas beban kerja dan pengeluar sertifikat OIDC
  • Perlindungan penyebaran dan Standar Keamanan Pod dasar dalam mode penegakan
  • Pembersih gambar untuk menghapus gambar rentan yang tidak digunakan
  • Pembatasan keamanan kumpulan simpul sistem terkelola yang mempertahankan batas antara beban kerja pelanggan dan infrastruktur yang dikelola AKS

Standar AKS mendukung kemampuan ini dengan fleksibilitas implementasi yang lebih besar, tetapi mungkin memerlukan pengaktifan eksplisit dan manajemen operasional.

Keamanan Node

Simpul AKS adalah mesin virtual Azure (VM). Di AKS Standard, Anda mengelola konfigurasi kumpulan simpul dan opsi siklus hidup. Di AKS Otomatis, AKS mengelola kumpulan simpul sistem dan komponen sistem inti atas nama Anda, termasuk penskalaan dan peningkatan, dengan pembatasan keamanan untuk infrastruktur sistem terkelola.

Node Linux menjalankan versi Ubuntu atau Azure Linux yang telah dioptimalkan. simpul 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 baru: Pool node Linux menggunakan containerd sebagai runtime kontainer. kumpulan simpul Server Windows 2019 dan Windows Server 2022 menggunakan containerd sebagai runtime kontainernya. Untuk informasi selengkapnya, lihat Tambahkan 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 peningkatan keamanan untuk simpul pekerja Linux dan Windows, lihat simpul patching keamanan.

Kluster AKS yang menjalankan VM Generasi 2 Azure menyertakan dukungan untuk Trusted Launch. 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

Azure Container Linux (ACL) adalah OS yang tidak dapat diubah dan dioptimalkan kontainer untuk AKS. ACL berasal dari proyek Flatcar Container Linux dan dibangun di atas desain imutabel Flatcar yang telah terbukti dan mengutamakan kontainer, sekaligus menambahkan paket Azure Linux, layanan pemeliharaan, dan integrasi platform. Ini memungkinkan ACL untuk tetap selaras dengan inovasi Flatcar hulu sambil memenuhi persyaratan produksi, keamanan, dan kepatuhan Azure. Untuk mempelajari lebih lanjut tentang Flatcar Container Linux, lihat dokumentasi Flatcar.

ACL umumnya tersedia (GA) sebagai opsi OS pada AKS mulai AKS v1.34. Anda dapat menyebarkan kumpulan simpul ACL di kluster AKS baru, menambahkan kumpulan simpul ACL ke kluster yang ada, dan memigrasikan kumpulan simpul Linux yang ada ke ACL.

Untuk informasi selengkapnya tentang ACL, lihat Azure Container Linux (ACL) untuk gambaran umum AKS.

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 pada disk terkelola secara otomatis dienkripsi saat tidak aktif 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 host Azure, 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 menyebarkan kluster AKS ke subnet jaringan virtual Azure yang ada. Jaringan virtual ini terhubung kembali ke jaringan lokal Anda menggunakan VPN Situs-ke-Situs Azure atau Rute Ekspres. Tentukan kontroler ingress Kubernetes dengan alamat IP internal privat untuk membatasi akses layanan ke koneksi jaringan internal.

Dalam AKS Automatic, kemampuan jaringan virtual terkelola serta pengaturan default inti untuk lalu lintas masuk dan keluar telah dikonfigurasi sebelumnya guna menyediakan konfigurasi dasar yang aman. Dalam Standar AKS, model jaringan dan kontrol egress/ingress lebih fleksibel dan harus dipilih berdasarkan arsitektur keamanan Anda.

kelompok keamanan jaringan Azure

Untuk memfilter arus 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 kluster AKS Anda (baik menggunakan Azure CNI atau Kubenet), jangan mengubah grup keamanan jaringan tingkat NIC 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 Microsoft Defender 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.

Di AKS Otomatis, identitas beban kerja dan penerbit OIDC telah dikonfigurasi sebelumnya untuk menyederhanakan akses beban kerja yang aman ke layanan Azure. Dalam Standar AKS, kemampuan ini tersedia dan dapat diaktifkan sebagai bagian dari postur keamanan garis besar Anda.

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.

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.

Konten terkait

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

Jika Anda mengevaluasi default khusus mode dan tanggung jawab operasional, lihat Apa itu Azure Kubernetes Service (AKS) Otomatis?

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