Share via

Keamanan untuk AKS

  • Artikel

Artikel ini memancang Anda melalui aspek tata kelola keamanan Azure Kubernetes Service (AKS) untuk dipertimbangkan sebelum Anda menerapkan solusi apa pun.

Artikel ini berfokus pada cara menerapkan solusi dengan menggunakan Azure dan perangkat lunak sumber terbuka. Keputusan yang Anda buat saat membuat zona pendaratan skala perusahaan sebagian dapat menentukan tata kelola Anda. Untuk memahami prinsip tata kelola, lihat Tata kelola dan kepatuhan keamanan skala perusahaan.

Permukaan serangan

Pertimbangkan lima permukaan serangan berikut saat Anda membuat strategi keamanan untuk kluster Kubernetes:

  • Bangun
  • Registri
  • Kluster
  • Simpul
  • Aplikasi

Untuk setiap kategori, kami membahas risiko utama yang perlu dipertimbangkan dan penanggulangan risiko tersebut.

Keamanan {i>Build

Keamanan {i>build

Risiko utama

Konfigurasi gambar yang buruk dapat menyebabkan kerentanan keamanan di bawah alur. Misalnya, Anda mungkin memiliki kontainer yang berjalan dengan hak istimewa yang lebih besar dari yang mereka butuhkan. Kontainer juga dapat dikonfigurasi untuk memungkinkan akses jaringan tertentu, yang mungkin membahayakan sistem. Tidak membatasi panggilan sistem yang diizinkan ke panggilan yang diperlukan untuk pengoperasian kontainer yang aman dapat meningkatkan risiko dari kontainer yang disusupi.

Kerentanan lain dapat memungkinkan kontainer untuk mendapatkan akses ke direktori sensitif host atau memungkinkan kontainer untuk mengubah lokasi yang mengontrol fungsi dasar host.

Kontainer nakal adalah kontainer yang tidak dienkripsi di lingkungan. Mereka dapat menjadi hasil dari pengembang yang menguji kode mereka di lingkungan pengujian. Kontainer ini mungkin belum melalui pemindaian ketat untuk kerentanan atau dikonfigurasi dengan benar. Kerentanan ini mungkin membuka titik masuk bagi penyerang.

Menggunakan gambar dasar yang bukan berasal dari sumber tepercaya atau tidak diperbarui dengan pembaruan keamanan juga dapat menyebabkan kerentanan dalam kontainer yang mereka gunakan untuk membangun.

Penanggulangan risiko

Keamanan {i>build

Anda dapat membuat alur yang memindai dan gagal membangun karena memiliki satu atau 10 kerentanan kritis. Pendekatan yang lebih baik mungkin adalah melihat lapisan berikutnya ke bawah. Anda dapat mulai menyegmentasikan titik tanggung jawab berdasarkan status vendor.

Atur ambang batas pada lapisan status kerentanan. Apa pun dengan status Terbuka, Tidak akan diperbaiki, atau Ditangguhkan terus mengalir ke alur di mana SecOps dapat mengakses risiko, seperti yang mereka lakukan hari ini. Kerentanan dengan status perbaikan Vendor yang tersedia adalah sesuatu yang dapat diatasi pengembang. Penggunaan masa tenggang memungkinkan waktu bagi pengembang untuk memulihkan kerentanan.

Seiring dengan penilaian kerentanan adalah penilaian kepatuhan. Misalnya, mengizinkan gambar berjalan sebagai root atau mengekspos SSH merusak postur kepatuhan sebagian besar perusahaan. Atasi masalah ini selama build alih-alih selama penyebaran.

Biasanya, Anda memindai gambar Anda terhadap tolok ukur Docker CIS. Ketika Anda menggunakan jenis alur ini, Anda tidak akan memutuskan pengembangan dengan memperkenalkan remediasi keamanan, tetapi Anda dapat meningkatkan postur keamanan perusahaan Anda secara keseluruhan.

Penggunaan alat yang mengaktifkan kemampuan ini sangat penting untuk secara efektif menerapkan strategi yang tepat untuk bisnis Anda. Alat tradisional sering kali tidak dapat mendeteksi kerentanan dalam kontainer, yang dapat menyebabkan rasa keamanan yang salah. Alat yang mempertimbangkan pendekatan build berbasis alur dan sifat teknologi kontainer yang tidak dapat diubah dan deklaratif diperlukan untuk mengamankan ekosistem kontainer Anda dengan benar.

Alat-alat ini harus memiliki properti berikut:

  • Integrasi dengan seluruh masa pakai gambar, dari awal proses build ke registri hingga runtime.
  • Visibilitas ke kerentanan di semua lapisan gambar, termasuk lapisan dasar gambar, kerangka kerja aplikasi, dan perangkat lunak kustom.
  • Penegakan berbasis kebijakan dengan tingkat granularitas yang tepat, yang memungkinkan organisasi Anda untuk membuat gerbang kualitas di setiap tahap proses build dan penyebaran.

Keamanan Registri

Keamanan registri adalah tentang:

  • Kontrol penyimpangan dari build.
  • Pencegahan pendorongan/penarikan gambar yang terkontaminasi.
  • Penandatanganan gambar.

Risiko utama

Gambar sering berisi informasi kepemilikan, termasuk kode sumber organisasi. Jika koneksi ke registri tidak aman dengan tepat, konten gambar dapat menimbulkan risiko kerahasiaan separah bentuk data lain yang dikirimkan dalam organisasi Anda. Gambar kedaluarsa dengan versi kedaluarsa yang rentan dalam registri dapat meningkatkan risiko keamanan jika disebarkan secara tidak sengaja.

Kerentanan keamanan lain mungkin mencakup batasan autentikasi dan otorisasi yang tidak memadai untuk registri kontainer. Registri ini mungkin menampung aset kepemilikan sensitif dalam gambar.

Karena konten dibangun dan disebarkan, distribusi konten ini adalah salah satu dari banyak vektor serangan. Bagaimana Anda memastikan bahwa konten yang ditahapkan untuk distribusi adalah konten yang sama yang dikirimkan ke titik akhir yang dimaksudkan?

Penanggulangan risiko

Siapkan proses penyebaran untuk memastikan bahwa alat pengembangan, jaringan, dan runtime kontainer terhubung ke registri hanya melalui saluran terenkripsi. Selain itu, pastikan bahwa konten berasal dari sumber tepercaya. Untuk mengurangi risiko dari penggunaan gambar basi:

  • Hapus gambar yang tidak aman dan rentan yang seharusnya tidak lagi digunakan dari registri kontainer.
  • Menerapkan akses gambar dengan menggunakan nama yang tidak dapat diubah yang menentukan versi gambar tertentu yang akan digunakan. Anda dapat menerapkan konfigurasi ini dengan menggunakan tag terbaru atau versi gambar tertentu. {i>Tagtag terbaru mewakili versi terbaru.

Akses ke registri yang berisi gambar sensitif harus memerlukan autentikasi dan otorisasi. Semua akses tulis juga harus memerlukan autentikasi. Misalnya, kebijakan Anda dapat memungkinkan pengembang hanya mendorong gambar ke repositori tertentu yang menjadi tanggung jawab mereka.

Akses ke registri ini harus digabungkan dan memanfaatkan kebijakan akses tingkat bisnis. Misalnya, Anda dapat mengonfigurasi alur CI/CD untuk mendorong gambar ke repositori hanya setelah mereka lulus penilaian kepatuhan pemindaian kerentanan dan pengujian kontrol kualitas.

Registri kontainer sekarang dianggap registri artefak menjadi sarana utama untuk menyebarkan jenis konten apa pun, bukan hanya gambar kontainer. Setiap cloud menyediakan registri dengan proyek sumber terbuka dan produk vendor yang tersedia untuk hosting lokal atau privat dalam penyedia cloud. Konten dipromosikan di dalam dan di seluruh registri dari {i>build

Bagaimana Anda dapat memastikan integritas konten yang masuk ke registri adalah konten yang sama yang keluar dari registri? Mengadopsi solusi penandatanganan gambar memastikan bahwa penyebaran hanya berasal dari registri tepercaya dan menyebarkan konten tepercaya.

Keamanan klaster

Keamanan kluster adalah tentang:

  • Autentikasi dan otorisasi.
  • Keamanan jaringan.
  • Manajemen kerentanan dan kepatuhan.

Risiko utama

Terkadang satu kluster Kubernetes mungkin digunakan untuk menjalankan aplikasi yang berbeda yang dikelola oleh tim yang berbeda dengan persyaratan tingkat akses yang berbeda. Jika akses diberikan kepada individu tanpa batasan atau hanya sesuai dengan kebutuhan mereka, pengguna yang jahat atau ceroboh dapat membahayakan beban kerja yang dapat mereka akses dan aset lain di kluster.

Kerentanan keamanan lain mungkin terjadi ketika direktori pengguna kluster sendiri mengelola otorisasi dan autentikasi. Direktori autentikasi organisasi sering kali lebih dikontrol dengan ketat. Karena akun-akun ini sangat istimewa, dan lebih sering yatim piatu, kemungkinan akun yang disusupi meningkat.

Skenario ini dapat menyebabkan kerentanan kluster atau bahkan di seluruh sistem. Data yang disimpan oleh volume kontainer dikelola oleh orkestrator, yang harus memiliki akses ke data apa pun simpul tempatnya dihosting.

Filter jaringan tradisional mungkin memiliki kebutaan keamanan karena overlay jaringan yang dirancang untuk mengenkripsi data saat transit. Desain ini menyulitkan pemantauan lalu lintas dalam kluster, sehingga ketentuan khusus mungkin diperlukan untuk memantau kluster Kubernetes.

Lalu lintas dari berbagai aplikasi yang berbagi kluster yang sama mungkin memiliki tingkat sensitivitas yang berbeda, seperti situs web yang menghadap publik dan aplikasi internal yang menjalankan proses bisnis sensitif yang penting. Berbagi jaringan virtual yang sama dalam kluster dapat menyebabkan data sensitif yang disusupi. Misalnya, penyerang mungkin menggunakan jaringan bersama yang terekspos ke internet untuk menyerang aplikasi internal.

Lindungi komponen yang menjalankan kluster itu sendiri dari kerentanan dan masalah kepatuhan. Pastikan Anda menjalankan versi kubernetes terbaru yang mungkin untuk memanfaatkan remediasi.

Penanggulangan risiko

Akses pengguna kluster Kubernetes harus menggunakan model akses dengan hak istimewa paling sedikit. Hanya memberikan pengguna akses untuk melakukan tindakan tertentu pada {i>host

Gunakan metode autentikasi yang kuat seperti autentikasi multifaktor untuk mengamankan akses ke akun ini. Direktori pengguna organisasi harus digunakan untuk mengelola kluster melalui akses menyeluruh dibandingkan dengan akun pengguna khusus kluster yang mungkin tidak memiliki tingkat kebijakan dan kontrol yang sama.

Gunakan metode enkripsi yang memungkinkan kontainer mengakses data dengan benar apa pun host yang dijalankan kontainer. Alat enkripsi ini harus mencegah akses yang tidak diizinkan ke data oleh kontainer lain bahkan dalam node yang sama yang seharusnya tidak memiliki akses ke mereka.

Konfigurasikan kluster Kubernetes untuk memisahkan lalu lintas jaringan menjadi jaringan virtual atau subnet diskrit berdasarkan tingkat sensitivitas. Segmentasi per aplikasi mungkin juga dimungkinkan, tetapi menentukan jaringan berdasarkan tingkat sensitivitas mungkin cukup. Misalnya, jaringan virtual untuk aplikasi yang menghadap pelanggan yang dipisahkan dari yang melayani aplikasi internal dengan lalu lintas sensitif harus diterapkan minimal.

Anda dapat menggunakan taint dan toleransi untuk mengisolasi penyebaran ke set simpul tertentu berdasarkan tingkat sensitivitas. Hindari menghosting beban kerja yang sangat sensitif dalam simpul yang sama dengan beban kerja tersebut dengan sensitivitas yang lebih rendah. Menggunakan kluster yang dikelola secara terpisah adalah pilihan yang lebih aman.

Segmentasikan kontainer berdasarkan tujuan, sensitivitas, dan postur utas untuk memberikan perlindungan ekstra untuk beban kerja sensitif. Dengan mengesegmentasi kontainer dengan cara ini, lebih sulit bagi penyerang yang telah mendapatkan akses ke satu segmen untuk mendapatkan akses ke segmen lain. Konfigurasi ini memiliki keuntungan tambahan untuk memastikan data residual, seperti cache atau pemasangan volume, diisolasi oleh tingkat sensitivitas.

Kluster Kubernetes harus dikonfigurasi untuk:

  • Menyediakan lingkungan yang aman untuk aplikasi yang berjalan di atasnya.
  • Pastikan node ditambahkan dengan aman ke kluster.
  • Memiliki identitas persisten untuk membantu memastikan keamanan sepanjang siklus hidup mereka.
  • Memberikan informasi langsung dan akurat tentang kondisi kluster, termasuk jaringan dan node di dalamnya.

Node yang dikompromikan harus mudah untuk diisolasi dan dihapus dari kluster tanpa mempengaruhi performa kluster. AKS membuatnya sederhana.

Tentukan standar konfigurasi runtime kontainer untuk memastikan kepatuhan secara otomatis. Ada banyak kebijakan dalam Azure yang memudahkan proses ini, dan pengguna juga dapat membuat kebijakan mereka sendiri. Gunakan fitur keamanan Azure untuk terus menilai pengaturan konfigurasi di seluruh lingkungan dan secara aktif menerapkannya.

Secara otomatis memastikan bahwa kerentanan komponen Kubernetes sedang ditangani. Gunakan lingkungan terpisah untuk pengembangan, pengujian, dan produksi, masing-masing dengan kontrol dan kontrol akses berbasis peran (RBAC) mereka sendiri untuk manajemen kontainer. Kaitkan semua pembuatan kontainer dengan identitas pengguna individual dan harus dicatat untuk audit. Konfigurasi ini membantu mengurangi risiko kontainer nakal.

Keamanan simpul

Keamanan node adalah tentang:

  • Perlindungan runtime.
  • Manajemen kerentanan dan kepatuhan.

Risiko utama

Node pekerja memiliki hak akses istimewa ke semua komponen pada node. Penyerang dapat menggunakan layanan apa pun yang dapat diakses jaringan sebagai titik masuk, sehingga menyediakan akses ke host dari beberapa titik dapat secara serius meningkatkan permukaan serangannya. Semakin besar permukaan serangan, semakin banyak peluang bagi penyerang untuk mendapatkan akses ke node dan sistem operasinya.

Selain itu, sistem operasi khusus kontainer seperti yang digunakan dalam node AKS memiliki permukaan serangan yang lebih kecil karena tidak berisi pustaka yang memungkinkan sistem operasi reguler untuk secara langsung menjalankan {i>database

Sistem operasi {i>host

Hak akses pengguna yang tidak tepat juga dapat menyebabkan risiko keamanan ketika pengguna masuk langsung ke simpul untuk mengelola kontainer dibandingkan dengan melalui sarana kontrol AKS. Masuk secara langsung dapat memungkinkan pengguna untuk membuat perubahan pada aplikasi selain yang harus mereka akses.

Selain itu, kontainer berbahaya dapat menyebabkan gangguan sistem {i>filehost

Penanggulangan risiko

Batasi akses node dengan membatasi akses SSH.

Menggunakan OS khusus kontainer dalam simpul AKS biasanya mengurangi permukaan serangan karena layanan dan fungsionalitas lain dinonaktifkan. Mereka juga memiliki sistem file baca-saja dan menggunakan praktik pengerasan kluster lainnya secara default.

Platform Azure secara otomatis menerapkan penambalan keamanan OS ke node Linux setiap malam. Jika pembaruan keamanan Linux OS memerlukan mulai ulang host, ia tidak akan secara otomatis melakukan mulai ulang. AKS menyediakan mekanisme untuk reboot untuk menerapkan {i>patch

Pertahanan Microsoft untuk Server tidak berlaku untuk simpul AKS Linux dan Windows karena Microsoft mengelola OS mereka. Jika tidak ada komputer virtual lain yang berada dalam langganan tempat AKS disebarkan, Anda dapat menonaktifkan Pertahanan Microsoft untuk Server dengan aman.

Jika lingkungan telah disebarkan, termasuk kebijakan Azure yang direkomendasikan zona pendaratan skala perusahaan, Anda dapat mengonfigurasi pengecualian ke penetapan kebijakan di grup manajemen yang secara otomatis memungkinkan Pertahanan Microsoft untuk Server untuk menghindari biaya yang tidak perlu.

Keamanan aplikasi

Keamanan aplikasi adalah tentang:

  • Perlindungan runtime.
  • Manajemen kerentanan dan kepatuhan.

Risiko utama

Gambar adalah {i>file

Anda harus selalu memperbarui file-file ini dengan versi terbaru karena pengembang paket secara teratur mengidentifikasi kerentanan keamanan. Buat pembaruan kontainer lebih jauh ke {i>upstreamhost

File berbahaya juga dapat disematkan dalam gambar, yang kemudian dapat digunakan untuk menyerang kontainer atau komponen sistem lainnya. Kontainer pihak ketiga dapat menjadi kemungkinan vektor serangan. Detail spesifik mungkin tidak diketahui tentang detail tersebut dan dapat membocorkan data. Mungkin kontainer belum diperbarui dengan pembaruan keamanan yang diperlukan.

Vektor serangan lain adalah penggunaan penyematan rahasia seperti kata sandi dan string koneksi langsung dalam sistem file gambar. Praktik ini dapat menyebabkan risiko keamanan karena siapa pun yang memiliki akses ke gambar bisa mendapatkan akses ke rahasia.

Mungkin ada kekurangan dalam aplikasi itu sendiri, seperti aplikasi yang rentan terhadap {i>scriptinghost

Runtime kontainer AKS memudahkan pemantauan kerentanan dengan menggunakan berbagai alat keamanan yang tersedia di Azure. Untuk informasi selengkapnya, lihat Pengantar Pertahanan Microsoft untuk Kubernetes.

Anda juga harus mengontrol lalu lintas jaringan keluar yang dikirim ke kontainer untuk memastikan bahwa kontainer tidak dapat mengirim lalu lintas di seluruh jaringan tingkat sensitivitas yang berbeda seperti lingkungan yang menghosting data aman atau ke internet. Azure memudahkan kontrol ini dengan berbagai jaringan dan fitur keamanan AKS.

Secara {i>default

Penanggulangan risiko

Jangan pernah menyimpan rahasia dalam kode aplikasi atau sistem {i>fileruntime

Hindari penggunaan gambar dan registri yang tidak tepercaya dan pastikan bahwa hanya gambar dari set tepercaya yang diizinkan untuk berjalan di kluster mereka. Untuk pendekatan multilayer:

  • Kontrol secara terpusat gambar dan registri apa yang dipercaya.
  • Secara diskrit mengidentifikasi setiap gambar dengan tanda tangan kriptografi.
  • Menerapkan kebijakan yang memastikan semua {i>host
  • Validasi tanda tangan ini sebelum eksekusi.
  • Pantau dan perbarui gambar dan registri ini saat kerentanan dan persyaratan konfigurasi berubah.

Profil komputasi yang aman harus digunakan untuk membatasi kontainer dan dialokasikan pada runtime. Profil kustom dapat dibuat dan diteruskan ke {i>runtime

Alat dapat secara otomatis membuat profil aplikasi dengan menggunakan pembelajaran perilaku dan mendeteksi anomali. Anda dapat menggunakan solusi pihak ketiga untuk mendeteksi anomali saat runtime. Anomali dapat mencakup peristiwa seperti:

  • Eksekusi proses atau panggilan sistem tidak valid atau tidak terduga.
  • Perubahan pada file konfigurasi dan biner yang dilindungi.
  • Menulis ke lokasi dan tipe file yang tidak terduga.
  • Pembuatan pendengar jaringan yang tidak terduga.
  • Lalu lintas yang dikirim ke tujuan jaringan yang tidak terduga.
  • Penyimpanan dan eksekusi malware.

Microsoft Defender untuk Kubernetes saat ini berinvestasi di bidang ini.

Kontainer harus berjalan dengan sistem file akar mereka dalam mode baca-saja untuk mengisolasi penulisan ke direktori yang ditentukan, yang dapat dengan mudah dipantau oleh alat tersebut. Konfigurasi ini membuat kontainer lebih tahan terhadap kompromi karena Anda mengisolasi perubahan pada lokasi tertentu ini. Mereka dapat dengan mudah dipisahkan dari sisa aplikasi.

Pertimbangan Desain

AKS memiliki beberapa antarmuka ke layanan Azure lainnya seperti MICROSOFT Entra ID, Azure Storage, dan Azure Virtual Network. Menggunakan layanan ini membutuhkan perhatian khusus selama fase perencanaan. AKS juga menambahkan kompleksitas ekstra yang mengharuskan Anda untuk mempertimbangkan penerapan tata kelola keamanan dan mekanisme kepatuhan yang sama dan kontrol seperti di sisa lanskap infrastruktur Anda.

Berikut adalah beberapa pertimbangan desain lain untuk tata kelola dan kepatuhan keamanan AKS:

  • Jika Anda membuat kluster AKS dalam langganan yang disebarkan sesuai dengan praktik terbaik zona pendaratan skala perusahaan, biasakan diri dengan kebijakan Azure yang akan diwarisi kluster. Untuk informasi selengkapnya, lihat Kebijakan yang disertakan dalam implementasi referensi zona pendaratan Azure.
  • Tentukan apakah sarana kontrol kluster harus dapat diakses melalui internet (kami merekomendasikan pembatasan IP), yang merupakan default, atau hanya dari dalam jaringan privat Anda di Azure atau lokal sebagai kluster privat. Jika organisasi Anda mengikuti praktik terbaik zona pendaratan skala perusahaan, Corp grup manajemen memiliki Azure Policy yang terkait yang memaksa kluster menjadi privat. Untuk informasi selengkapnya, lihat Kebijakan yang disertakan dalam implementasi referensi zona pendaratan Azure.
  • Evaluasi menggunakan modul keamanan AppArmor Linux bawaan untuk membatasi tindakan yang dapat dilakukan kontainer, seperti fungsi baca, tulis, jalankan, atau sistem seperti memasang sistem file. Misalnya, semua langganan memiliki kebijakan Azure yang mencegah pod di semua kluster AKS membuat kontainer istimewa. Untuk informasi selengkapnya, lihat Kebijakan yang disertakan dalam implementasi referensi zona pendaratan Azure.
  • Evaluasi menggunakan seccomp (komputasi aman) pada tingkat proses untuk membatasi panggilan proses yang dapat dilakukan kontainer. Misalnya, Azure Policy diterapkan sebagai bagian dari implementasi zona pendaratan skala perusahaan generik di grup manajemen zona pendaratan untuk mencegah eskalasi hak istimewa kontainer untuk melakukan penggunaan akar seccomp melalui kebijakan Azure untuk Kubernetes.
  • Tentukan apakah registri kontainer Anda dapat diakses melalui internet atau hanya dalam jaringan virtual tertentu. Menonaktifkan akses internet dalam registri kontainer dapat memiliki efek negatif pada sistem lain yang mengandalkan konektivitas publik untuk mengaksesnya. Contohnya termasuk alur integrasi berkelanjutan atau Pertahanan Microsoft untuk pemindaian gambar. Untuk informasi selengkapnya, lihat Koneksi secara privat ke registri kontainer dengan menggunakan Azure Private Link.
  • Tentukan apakah registri kontainer privat Anda dibagikan di beberapa zona pendaratan atau jika Anda menyebarkan registri kontainer khusus ke setiap langganan zona pendaratan.
  • Pertimbangkan untuk menggunakan solusi keamanan seperti Microsoft Defender untuk Kubernetes untuk deteksi ancaman.
  • Pertimbangkan untuk memindai gambar kontainer Anda untuk kerentanan.
  • Pertimbangkan untuk menonaktifkan Pertahanan Microsoft untuk Server dalam langganan AKS jika tidak ada komputer virtual non-AKS, untuk menghindari biaya yang tidak perlu.

Rekomendasi desain

Penting

pemindaian gambar Microsoft Defender untuk Cloud tidak kompatibel dengan titik akhir Container Registry. Untuk informasi selengkapnya, lihat Koneksi secara privat ke registri kontainer dengan menggunakan Private Link.