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

Keamanan kontainer melindungi seluruh alur ujung ke ujung dari membangun ke beban kerja aplikasi yang berjalan di Azure Kubernetes Service (AKS).

Rantai Pasokan Aman mencakup lingkungan build 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.
  • Wawasan Ujung ke Ujung dari build melalui 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.

Keamanan Build

Sebagai titik masuk untuk Rantai Pasokan, penting untuk melakukan analisis statis build gambar sebelum dipromosikan ke bawah alur. Ini termasuk penilaian kerentanan dan kepatuhan. Ini bukan tentang gagal membangun karena memiliki kerentanan, karena itu memutus pengembangan. Ini tentang melihat Status Vendor ke segmen berdasarkan kerentanan yang dapat ditindaklanjuti oleh tim pengembangan. Gunakan juga Masa Tenggang untuk memungkinkan waktu pengembang 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 khusus yang disewa tunggal untuk menyediakan API Server, Scheduler, dll. 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 simpul

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

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

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

Catatan

Kluster AKS yang berjalan:

  • Kubernetes versi 1.19 dan yang lebih tinggi - Kumpulan simpul Linux digunakan containerd sebagai runtime kontainernya. Kumpulan simpul Windows Server 2019 digunakan containerd sebagai runtime kontainernya, yang saat ini dalam pratinjau. 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. Kumpulan simpul Windows Server 2019 menggunakan Docker untuk runtime kontainer default.

Untuk informasi selengkapnya tentang proses peningkatan keamanan untuk simpul pekerja Linux dan Windows, lihat Simpul patching keamanan.

Kluster AKS yang menjalankan VM Azure Generation 2 mencakup dukungan untuk Peluncuran Tepercaya (pratinjau), yang melindungi dari teknik serangan tingkat lanjut dan persisten dengan menggabungkan teknologi yang dapat diaktifkan 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.

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 disebarkan 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 kumpulan kluster dan simpul, atau untuk kluster atau kumpulan simpul yang ada, sedang dalam 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 sejati saat menjalankan beban kerja multipenyewa yang bermusuhan, hanya percayai 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 terisolasi kernel untuk digunakan sebagai simpul 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 teks yang jelas, format yang dapat dibaca, dan perubahan. Ini membantu mengisolasi kontainer Anda dari grup/pod kontainer lain, serta kernel OS simpul VM. Kontainer Rahasia (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 load balancer, 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 layanan 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.

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 sepenuhnya mengelola penyimpanan etcd dan data dienkripsi saat tidak aktif dalam platform Azure.

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: