Praktik terbaik untuk keamanan dan peningkatan kluster di Azure Kubernetes Service (AKS)

Berlaku untuk: ✔️ AKS Automatic ✔️ AKS Standard

Saat Anda mengelola kluster di Azure Kubernetes Service (AKS), beban kerja dan keamanan data adalah pertimbangan utama. Saat Anda menjalankan kluster multi-penyewa menggunakan isolasi logis, Anda sangat perlu mengamankan akses ke sumber daya dan beban kerja. Minimalkan risiko serangan dengan menerapkan pembaruan keamanan Kubernetes dan OS simpul terbaru.

Artikel ini berfokus pada cara mengamankan kluster AKS Anda. Anda akan mempelajari cara untuk:

  • Gunakan ID Microsoft Entra dan kontrol akses berbasis peran Kubernetes (Kubernetes RBAC) untuk mengamankan akses server API.
  • Mengamankan akses kontainer ke sumber daya simpul.
  • Tingkatkan kluster AKS ke versi Kubernetes terbaru.
  • Selalu perbarui node dan terapkan patch keamanan secara otomatis.

Anda juga dapat membaca praktik terbaik untuk manajemen gambar kontainer dan untuk keamanan pod.

Tanggung jawab keamanan mode kluster AKS

AKS mendukung dua mode kluster: AKS Automatic dan AKS Standard. Tujuan keamanan sama di kedua mode, tetapi tanggung jawab implementasi berbeda.

AKS Automatic menyertakan dasar yang diperkuat dengan lebih banyak kontrol yang telah dikonfigurasi sebelumnya dalam konfigurasi yang didukung. AKS Standard menyediakan kontrol konfigurasi langsung yang lebih luas, yang meningkatkan tanggung jawab operator untuk penyiapan dasar dan operasi yang sedang berlangsung.

Area AKS Otomatis Standar AKS
Garis besar autentikasi dan otorisasi kluster Lebih banyak setelan bawaan yang telah dikonfigurasi sebelumnya pada konfigurasi yang didukung Umumnya dikonfigurasi secara eksplisit oleh operator
Pengerasan jaringan server API Lebih banyak perilaku dasar yang telah dikonfigurasi sebelumnya dalam konfigurasi yang didukung Pilihan penguatan keamanan eksplisit oleh operator
Kontrol keamanan kebijakan dan garis besar Lebih banyak default prakonfigurasi dalam konfigurasi yang didukung Pengaktifan kebijakan eksplisit dan pemilihan mode
Kontrol kebersihan gambar Kontrol garis besar tersedia dalam konfigurasi yang didukung Pengaktifan eksplisit dan kepemilikan siklus hidup
Operasi kumpulan simpul sistem Perilaku lain yang dikelola oleh layanan Lebih banyak perilaku yang dikelola operator
Tingkatkan kepemilikan Lebih banyak setelan default untuk upgrade terkelola Strategi yang dipilih operator dan tata kelola peluncuran

Aktifkan perlindungan ancaman

Panduan praktik terbaik

Anda dapat mengaktifkan Defender untuk Kontainer untuk membantu mengamankan kontainer Anda. Defender untuk Kontainer dapat menilai konfigurasi kluster dan memberikan rekomendasi keamanan, menjalankan pemindaian kerentanan, dan memberikan perlindungan dan peringatan real time untuk node dan kluster Kubernetes.

Panduan ini berlaku untuk kedua mode. Bahkan ketika AKS Automatic menyediakan pengaturan keamanan default yang sudah diprakonfigurasi, proses onboarding perlindungan ancaman dan alur kerja respons terhadap peringatan tetap menjadi tanggung jawab operasional tim Anda.

Akses aman ke server API dan node kluster

Panduan praktik terbaik

Salah satu cara terpenting untuk mengamankan kluster Anda adalah dengan mengamankan akses ke server API Kubernetes. Untuk mengontrol akses ke server API, integrasikan Kubernetes RBAC dengan Microsoft Entra ID. Dengan kontrol ini, Anda mengamankan AKS dengan cara yang sama seperti Anda mengamankan akses ke langganan Azure Anda.

Server API Kubernetes menyediakan satu titik koneksi untuk permintaan melakukan tindakan dalam kluster. Untuk mengamankan dan mengaudit akses ke server API, batasi akses dan berikan tingkat izin semurah mungkin. meskipun pendekatan ini tidak unik untuk Kubernetes, ini sangat penting ketika Anda telah secara logis mengisolasi kluster AKS Anda untuk lingkungan multi-penyewa.

MICROSOFT Entra ID menyediakan solusi manajemen identitas siap perusahaan yang terintegrasi dengan kluster AKS. Karena Kubernetes tidak menyediakan solusi manajemen identitas, Anda mungkin sulit untuk membatasi akses ke server API secara terperinci. Dengan kluster terintegrasi Microsoft Entra di AKS, Anda menggunakan akun pengguna dan grup yang ada untuk mengautentikasi pengguna ke server API.

Integrasi Microsoft Entra untuk kluster AKS

Dengan menggunakan RBAC Kubernetes dan integrasi ID Microsoft Entra, Anda dapat mengamankan server API dan memberikan izin minimum yang diperlukan untuk kumpulan sumber daya terlingkup, seperti satu namespace. Anda dapat memberikan berbagai peran Kubernetes kepada pengguna atau grup Microsoft Entra. Dengan izin terperinci, Anda dapat membatasi akses ke server API dan menyediakan jejak audit tindakan yang jelas yang dilakukan.

Di AKS Otomatis, garis besar otorisasi dan keamanan lebih dikonfigurasi sebelumnya dalam konfigurasi yang didukung, sehingga operator berfokus pada penanganan validasi, tata kelola, dan pengecualian. Di AKS Standard, operator biasanya mengonfigurasi kontrol ini secara langsung dan mempertahankan postur siklus hidup mereka.

Untuk informasi selengkapnya tentang integrasi Microsoft Entra, RBAC Kubernetes, dan Azure RBAC, lihat Praktik terbaik untuk autentikasi dan otorisasi di AKS.

Membatasi akses ke API Metadata Instans

Panduan praktik terbaik

Tambahkan kebijakan jaringan di semua namespace pengguna untuk mencegah pod keluar ke titik akhir metadata.

Catatan

Untuk menerapkan Kebijakan Jaringan, sertakan atribut --network-policy azure saat membuat kluster AKS. Gunakan perintah berikut untuk membuat kluster: az aks create -g myResourceGroup -n myManagedCluster --network-plugin azure --network-policy azure --generate-ssh-keys

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: restrict-instance-metadata
spec:
  podSelector:
    matchLabels: {}
  policyTypes:
  - Egress
  egress:
  - to:
    - ipBlock:
        cidr: 10.10.0.0/0#example
        except:
        - 169.254.169.254/32

Di AKS Standard, pastikan model jaringan dan mesin kebijakan yang Anda pilih mendukung jalur kebijakan ini. Di AKS Automatic, terapkan pembatasan lalu lintas keluar yang setara di tingkat namespace jika didukung oleh konfigurasi kluster Anda.

Amankan akses kontainer ke sumber daya

Panduan praktik terbaik

Batasi akses ke tindakan yang dapat dilakukan kontainer. Berikan jumlah izin paling sedikit, dan hindari penggunaan akses root atau eskalasi istimewa.

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.

Dengan menggunakan namespace pengguna, Anda meningkatkan isolasi pada host dan membatasi pergerakan lateral jika terjadi breakout kontainer. Peningkatan ini signifikan baik ketika pod berjalan sebagai root maupun tidak.

Untuk kontrol tindakan kontainer yang lebih terperinci, Anda juga dapat menggunakan fitur keamanan Linux bawaan seperti AppArmor dan seccomp.

Bahkan ketika AKS Otomatis menyediakan default yang diperkeras, kontrol keamanan tingkat beban kerja tetap menjadi tanggung jawab tim aplikasi dan platform.

Untuk informasi selengkapnya, lihat Mengamankan akses kontainer ke sumber daya.

Secara teratur memperbarui ke versi terbaru Kubernetes

Panduan praktik terbaik

Untuk tetap terkini pada fitur baru dan perbaikan bug, tingkatkan versi Kubernetes secara teratur di kluster AKS Anda.

Kubernetes merilis fitur baru dengan kecepatan yang lebih cepat daripada platform infrastruktur yang lebih tradisional. Pembaruan Kubernetes meliputi:

  • Fitur baru
  • Perbaikan bug atau keamanan

Fitur baru biasanya bergerak melalui status alfa dan beta sebelum menjadi stabil. Setelah stabil, umumnya tersedia dan direkomendasikan untuk penggunaan produksi. Siklus rilis fitur baru Kubernetes memungkinkan Anda memperbarui Kubernetes tanpa secara rutin menghadapi perubahan yang merusak atau menyesuaikan deployment dan templat Anda.

AKS mendukung tiga versi minor Kubernetes. Setelah versi patch minor baru diperkenalkan, versi minor terlama dan rilis patch yang didukung dihentikan. Pembaruan Kubernetes minor terjadi secara berkala. Untuk tetap berada dalam dukungan, pastikan Anda memiliki proses tata kelola untuk memeriksa pembaruan yang diperlukan. Untuk informasi selengkapnya, lihat AKS versi Kubernetes yang didukung.

Dalam AKS Automatic, perilaku terkait pemutakhiran lebih banyak sudah diprakonfigurasi dalam konfigurasi yang didukung, dan operator harus berfokus pada validasi kesiapan beban kerja dan governans rilis. Di AKS Standard, operator memilih dan mengatur strategi peningkatan dan waktu peluncuran secara lebih langsung.

Untuk memeriksa versi yang tersedia untuk kluster Anda, gunakan az aks get-upgrades perintah seperti yang ditunjukkan dalam contoh berikut:

az aks get-upgrades --resource-group myResourceGroup --name myAKSCluster --output table

Anda kemudian dapat meningkatkan kluster AKS menggunakan az aks upgrade perintah . Proses peningkatan dengan aman:

  • Cordons dan menguras satu node pada satu waktu.
  • Menjadwalkan pod pada simpul yang tersisa.
  • Menyebarkan simpul baru yang menjalankan versi OS dan Kubernetes terbaru.

Penting

Uji versi minor baru di lingkungan uji dev dan validasi bahwa beban kerja Anda tetap sehat dengan versi Kubernetes baru.

Kubernetes mungkin menghentikan API (seperti pada versi 1.16) yang diandalkan beban kerja Anda. Saat membawa versi baru ke dalam produksi, pertimbangkan untuk menggunakan beberapa kumpulan simpul pada versi terpisah dan tingkatkan kumpulan individual satu per satu untuk secara bertahap menerapkan pembaruan di seluruh kluster. Jika menjalankan beberapa kluster, tingkatkan satu kluster sekaligus untuk memantau dampak atau perubahan secara progresif.

Untuk informasi selengkapnya tentang peningkatan di AKS, lihat Versi Kubernetes yang didukung di AKS dan Meningkatkan kluster AKS.

Memproses pembaruan node Linux

Setiap malam, simpul Linux di AKS mendapatkan patch keamanan melalui saluran pembaruan distro mereka. Perilaku ini dikonfigurasi secara otomatis ketika simpul disebarkan pada kluster AKS. Untuk meminimalkan gangguan dan dampak potensial terhadap beban kerja yang berjalan, simpul tidak secara otomatis di-boot ulang jika patch keamanan atau pembaruan kernel memerlukannya. Untuk informasi selengkapnya tentang cara menangani reboot simpul, lihat Menerapkan pembaruan keamanan dan kernel pada simpul di AKS.

Di AKS Automatic, perilaku pembaruan node sudah lebih banyak diprakonfigurasi pada konfigurasi yang didukung. Di AKS Standard, operator biasanya mendefinisikan tata kelola patch dan reboot dengan kontrol operasional eksplisit.

Peningkatan gambar node

Peningkatan tanpa pengawas menerapkan pembaruan ke OS simpul Linux, tetapi gambar yang digunakan untuk membuat simpul untuk kluster Anda tetap tidak berubah. Jika node Linux baru ditambahkan ke kluster Anda, gambar asli digunakan untuk membuat simpul. Simpul baru ini akan menerima semua pembaruan keamanan dan kernel yang tersedia selama pemeriksaan otomatis setiap malam tetapi akan tetap tidak ditambal hingga semua pemeriksaan dan pengulangan sistem selesai. Anda dapat menggunakan peningkatan gambar simpul untuk memeriksa dan memperbarui gambar simpul yang digunakan oleh kluster Anda. Untuk informasi selengkapnya tentang peningkatan gambar simpul, lihat Peningkatan gambar simpul Azure Kubernetes Service (AKS).

Memproses pembaruan simpul Windows Server

Untuk node Windows Server, lakukan operasi peningkatan image node secara teratur untuk mengisolasi dan menguras pod dengan aman serta menerapkan node yang diperbarui.

Konten terkait

Untuk informasi selengkapnya tentang AKS dan mengamankan kluster AKS Anda, lihat artikel berikut ini:

  • Terakhir diperbarui pada