Menggunakan Azure Firewall untuk membantu melindungi kluster Azure Kubernetes Service (AKS)

Azure Firewall

Azure Kubernetes Service (AKS)

Azure Private Link

Azure Virtual Network

Azure DevOps

Panduan ini menjelaskan cara membuat kluster AKS privat dalam topologi jaringan hub-and-spoke dengan menggunakan Terraform dan Azure DevOps. Azure Firewall digunakan untuk memeriksa lalu lintas ke dan dari kluster Azure Kubernetes Service (AKS ). Kluster dihosting oleh satu atau beberapa jaringan virtual spoke yang di-peering ke jaringan virtual hub.

Arsitektur

Unduh file Visio arsitektur ini.

Alur kerja

Modul Terraform digunakan untuk menyebarkan jaringan virtual baru yang memiliki empat subnet yang menghosting:

Kluster AKS (AksSubnet).
Komputer virtual jump-box (VM) dan titik akhir privat (VmSubnet).
Application Gateway WAF2 (AppGatewaySubnet).
Azure Bastion (AzureBastionSubnet).

Kluster AKS menggunakan identitas terkelola yang ditentukan pengguna untuk membuat sumber daya tambahan, seperti load balancer dan disk terkelola di Azure. Modul Terraform memungkinkan Anda untuk secara opsional menyebarkan kluster AKS yang memiliki fitur-fitur ini:

Kluster AKS terdiri dari kumpulan berikut:

Kumpulan simpul sistem yang hanya menghosting pod dan layanan sistem penting
Kumpulan simpul pengguna yang menghosting beban kerja dan artefak pengguna

VM disebarkan di jaringan virtual yang menghosting kluster AKS. Saat Anda menyebarkan AKS sebagai kluster privat, administrator sistem dapat menggunakan VM ini untuk mengelola kluster melalui alat baris perintah Kubernetes. Log diagnostik boot VM disimpan di akun Azure Storage.

Host Azure Bastion menyediakan konektivitas SSH keamanan yang ditingkatkan ke VM jump-box melalui SSL. Azure Container Registry digunakan untuk membangun, menyimpan, dan mengelola gambar dan artefak kontainer (seperti bagan Helm).

Arsitektur ini mencakup Azure Firewall yang digunakan untuk mengontrol lalu lintas masuk dan keluar melalui aturan DNAT, aturan jaringan, dan aturan aplikasi. Ini juga membantu melindungi beban kerja dengan menggunakan pemfilteran berbasis inteligensi ancaman. Azure Firewall dan Bastion disebarkan ke jaringan virtual hub yang di-peering dengan jaringan virtual yang menghosting kluster AKS privat. Tabel rute dan rute yang ditentukan pengguna digunakan untuk merutekan lalu lintas keluar dari kluster AKS privat ke Azure Firewall.

Catatan

Kami sangat menyarankan Anda menggunakan SKU Premium Azure Firewall karena memberikan perlindungan ancaman tingkat lanjut.

Key Vault digunakan sebagai penyimpanan rahasia oleh beban kerja yang berjalan di AKS untuk mengambil kunci, sertifikat, dan rahasia melalui ID Beban Kerja Microsoft Entra, Driver CSI Penyimpanan Rahasia, atau Dapr. Azure Private Link memungkinkan beban kerja AKS mengakses layanan Azure PaaS, seperti Azure Key Vault, melalui titik akhir privat di jaringan virtual.

Topologi mencakup titik akhir privat dan zona DNS privat untuk layanan ini:

Akun Azure Blob Storage
Container Registry
Key Vault
Server API kluster Kubernetes

Ada tautan jaringan virtual antara jaringan virtual hub-and-spoke yang menghosting kluster AKS dan zona DNS privat yang dijelaskan sebelumnya.

Ruang kerja Analitik Log digunakan untuk mengumpulkan log dan metrik diagnostik dari layanan Azure.

Komponen

Azure Firewall adalah layanan keamanan firewall jaringan cloud-native dan cerdas yang memberikan perlindungan ancaman untuk beban kerja cloud yang berjalan di Azure. Ini adalah layanan firewall stateful penuh yang dilengkapi dengan ketersediaan tinggi bawaan dan skalabilitas cloud tanpa batas. Firewall ini menyediakan inspeksi lalu lintas timur-barat dan utara-selatan.
Container Registry adalah layanan registri Docker privat terkelola yang didasarkan pada Docker Registry 2.0 sumber terbuka. Anda dapat menggunakan registri kontainer Azure dengan alur pengembangan dan penyebaran kontainer yang ada atau menggunakan Tugas Container Registry untuk membuat gambar kontainer di Azure.
Azure Kubernetes Service menyederhanakan penyebaran kluster Kubernetes terkelola di Azure dengan membongkar overhead operasional ke Azure. Sebagai layanan Kubernetes yang di-host, Azure menangani tugas-tugas penting, seperti pemantauan dan pemeliharaan kesehatan. Karena master Kubernetes dikelola oleh Azure, Anda hanya mengelola dan memelihara simpul agen.
Key Vault menyimpan dan mengontrol akses ke rahasia seperti kunci API, kata sandi, sertifikat, dan kunci kriptografi dengan keamanan yang ditingkatkan. Key Vault juga memungkinkan Anda dengan mudah menyediakan, mengelola, dan menyebarkan sertifikat Keamanan Lapisan Transportasi/Lapisan Soket Aman (TLS/SSL) publik dan privat, untuk digunakan dengan Azure dan sumber daya internal Anda yang terhubung.
Azure Bastion adalah platform yang dikelola sepenuhnya sebagai layanan (PaaS) yang Anda sediakan di dalam jaringan virtual Anda. Azure Bastion menyediakan konektivitas Remote Desktop Protocol (RDP) dan Secure Shell (SSH) keamanan yang ditingkatkan ke VM di jaringan virtual Anda, langsung dari portal Azure melalui TLS.
Azure Virtual Machines menyediakan sumber daya komputasi sesuai permintaan dan dapat diskalakan yang memberi Anda fleksibilitas virtualisasi.
Azure Virtual Network adalah blok bangunan dasar untuk jaringan privat di Azure. Virtual Network memungkinkan sumber daya Azure (seperti VM) untuk berkomunikasi satu sama lain, internet, dan jaringan lokal dengan keamanan yang ditingkatkan. Jaringan virtual Azure seperti jaringan tradisional yang lokal, tetapi mencakup manfaat infrastruktur Azure seperti skalabilitas, ketersediaan, dan isolasi.
Antarmuka Jaringan Virtual memungkinkan Azure VM berkomunikasi dengan internet, Azure, dan sumber daya lokal. Anda dapat menambahkan beberapa kartu antarmuka jaringan ke satu Azure VM, sehingga VM anak dapat memiliki perangkat antarmuka jaringan dan alamat IP khusus sendiri.
Disk terkelola Azure menyediakan volume penyimpanan tingkat blok yang dikelola Azure di Azure VM. Disk ultra, solid-state drive premium (SSD), SSD standar, dan hard disk drive standar (HDD) tersedia.
Blob Storage adalah solusi penyimpanan objek untuk cloud. Blob Storage dioptimalkan untuk menyimpan data tidak terstruktur dalam jumlah besar.
Private Link memungkinkan Anda mengakses layanan Azure PaaS (misalnya, Blob Storage dan Key Vault) melalui titik akhir privat di jaringan virtual Anda. Anda juga dapat menggunakannya untuk mengakses layanan yang dihosting Azure yang Anda miliki atau yang disediakan oleh mitra Microsoft.

Alternatif

Anda dapat menggunakan firewall pihak ketiga dari Marketplace Azure alih-alih Azure Firewall. Jika Anda melakukannya, Anda bertanggung jawab untuk mengonfigurasi firewall dengan benar untuk memeriksa dan mengizinkan atau menolak lalu lintas masuk dan keluar dari kluster AKS.

Detail skenario

Dalam lingkungan produksi, komunikasi dengan kluster Kubernetes harus dilindungi oleh firewall yang memantau dan mengontrol lalu lintas jaringan masuk dan keluar berdasarkan serangkaian aturan keamanan. Firewall biasanya membuat hambatan antara jaringan tepercaya dan jaringan yang tidak tepercaya, seperti internet.

Anda dapat membuat kluster AKS privat dalam topologi jaringan hub-and-spoke dengan menggunakan Terraform dan Azure DevOps. Azure Firewall digunakan untuk memeriksa lalu lintas ke dan dari kluster Azure Kubernetes Service (AKS ). Kluster dihosting oleh satu atau beberapa jaringan virtual spoke yang di-peering ke jaringan virtual hub.

Azure Firewall mendukung tiga SKU berbeda untuk memenuhi berbagai kasus dan preferensi penggunaan pelanggan:

Azure Firewall Premium disarankan untuk mengamankan aplikasi yang sangat sensitif, seperti pemrosesan pembayaran. Ini mendukung kemampuan perlindungan ancaman tingkat lanjut seperti malware dan inspeksi TLS.
Azure Firewall Standard direkomendasikan untuk pelanggan yang mencari firewall Lapisan 3–Lapisan 7 dan yang memerlukan penskalaan otomatis untuk menangani periode lalu lintas puncak hingga 30 Gbps. Ini mendukung fitur perusahaan, seperti inteligensi ancaman, proksi DNS, DNS kustom, dan kategori web.
Azure Firewall Basic direkomendasikan untuk pelanggan dengan kebutuhan throughput kurang dari 250 Mbps.

Tabel berikut ini memperlihatkan fitur dari tiga SKU Azure Firewall. Untuk informasi selengkapnya, lihat Harga Azure Firewall.

Screenshot that shows features of the three Azure Firewall SKUs

Secara default, kluster AKS memiliki akses internet keluar yang tidak terbatas. Tingkat akses jaringan ini memungkinkan simpul dan layanan yang berjalan di kluster AKS untuk mengakses sumber daya eksternal sesuai kebutuhan. Jika Anda ingin membatasi lalu lintas keluar, sejumlah port dan alamat terbatas harus tetap dapat diakses untuk mempertahankan tugas pemeliharaan kluster yang sehat. Cara term mudah untuk memberikan keamanan untuk lalu lintas keluar dari kluster Kubernetes seperti AKS adalah dengan menggunakan firewall perangkat lunak yang dapat mengontrol lalu lintas keluar berdasarkan nama domain. Azure Firewall dapat membatasi lalu lintas HTTP dan HTTPS keluar berdasarkan nama domain yang sepenuhnya memenuhi syarat (FQDN) tujuan. Anda juga dapat mengonfigurasi firewall dan aturan keamanan untuk mengizinkan port dan alamat yang diperlukan ini. Untuk informasi selengkapnya, lihat Mengontrol lalu lintas keluar untuk node kluster di AKS.

Demikian juga, Anda dapat mengontrol lalu lintas masuk dan meningkatkan keamanan dengan mengaktifkan pemfilteran berbasis inteligensi ancaman pada Azure Firewall yang disebarkan ke jaringan perimeter bersama. Pemfilteran ini dapat memberikan pemberitahuan dan menolak lalu lintas ke dan dari alamat IP dan domain berbahaya yang diketahui.

Kemungkinan kasus penggunaan

Skenario ini mengatasi kebutuhan untuk meningkatkan keamanan lalu lintas masuk dan keluar ke dan dari kluster Kubernetes.

Hindari perutean asimetris

Dalam solusi ini, Azure Firewall disebarkan ke jaringan virtual hub, dan kluster AKS privat disebarkan ke jaringan virtual spoke. Azure Firewall menggunakan kumpulan aturan jaringan dan aplikasi untuk mengontrol lalu lintas keluar. Dalam situasi ini, Anda perlu mengonfigurasi lalu lintas masuk ke titik akhir publik apa pun yang diekspos oleh layanan apa pun yang berjalan di AKS untuk memasuki sistem melalui salah satu alamat IP publik yang digunakan oleh Azure Firewall.

Paket tiba di alamat IP publik firewall tetapi kembali ke firewall melalui alamat IP privat (menggunakan rute default). Ini adalah masalah. Untuk menghindarinya, buat rute lain yang ditentukan pengguna untuk alamat IP publik firewall, seperti yang ditunjukkan dalam diagram berikut. Paket yang masuk ke alamat IP publik firewall dirutekan melalui internet. Konfigurasi ini menghindari rute default ke alamat IP privat firewall.

Untuk merutekan lalu lintas beban kerja AKS Anda ke Azure Firewall di jaringan virtual hub, Anda perlu:

Buat dan kaitkan tabel rute ke setiap subnet yang menghosting simpul pekerja kluster Anda.
Buat rute yang ditentukan pengguna untuk meneruskan lalu lintas untuk CIDR 0.0.0.0/0 ke alamat IP privat Azure Firewall. Tentukan Appliance virtual untuk jenis hop Berikutnya.

Untuk informasi selengkapnya, lihat Tutorial: Menyebarkan dan mengonfigurasi Azure Firewall menggunakan portal Microsoft Azure.

Untuk informasi selengkapnya, lihat:

Menyebarkan beban kerja ke kluster AKS privat saat menggunakan Azure DevOps

Jika Anda menggunakan Azure DevOps, perhatikan bahwa Anda tidak dapat menggunakan agen yang dihosting Microsoft Azure DevOps untuk menyebarkan beban kerja Anda ke kluster AKS privat. Mereka tidak memiliki akses ke server API-nya. Untuk menyebarkan beban kerja ke kluster AKS privat, Anda perlu menyediakan dan menggunakan agen yang dihost sendiri Azure DevOps di jaringan virtual yang sama dengan kluster AKS privat Anda, atau di jaringan virtual yang di-peering. Dalam kasus terakhir, pastikan untuk membuat tautan jaringan virtual antara zona DNS privat kluster AKS di grup sumber daya simpul dan jaringan virtual yang menghosting agen yang dihost sendiri Azure DevOps.

Anda dapat menyebarkan satu agen Azure DevOps Windows atau Linux di komputer virtual, atau Anda dapat menggunakan Virtual Machine Scale Set. Untuk informasi selengkapnya, lihat Agen Azure Virtual Machine Scale Set. Sebagai alternatif, Anda dapat menyiapkan agen yang dihost sendiri di Azure Pipelines untuk berjalan di dalam kontainer Windows Server Core (untuk host Windows) atau kontainer Ubuntu (untuk host Linux) dengan Docker. Sebarkan sebagai pod dengan satu atau beberapa replika di kluster AKS privat Anda. Untuk informasi selengkapnya, lihat:

Jika subnet yang menghosting kumpulan simpul kluster AKS privat Anda dikonfigurasi untuk merutekan lalu lintas keluar ke Azure Firewall melalui tabel rute dan rute yang ditentukan pengguna, pastikan untuk membuat aplikasi dan aturan jaringan yang tepat. Aturan ini perlu memungkinkan agen mengakses situs eksternal untuk mengunduh dan menginstal alat seperti Docker, Kubectl, Azure CLI, dan Helm pada komputer virtual agen. Untuk informasi selengkapnya, lihat Menjalankan agen yang dihost sendiri di Docker dan Membangun dan menyebarkan Azure DevOps Pipeline Agent di AKS.

Menggunakan Azure Firewall di depan Load Balancer Standar publik

Definisi sumber daya dalam modul Terraform menggunakan argumen meta siklus hidup untuk menyesuaikan tindakan saat sumber daya Azure diubah di luar kontrol Terraform. Argumen ignore_changes digunakan untuk menginstruksikan Terraform untuk mengabaikan pembaruan ke properti sumber daya tertentu, seperti tag. Definisi sumber daya Azure Firewall Policy berisi blok siklus hidup untuk mencegah Terraform memperbarui sumber daya saat kumpulan aturan atau satu aturan dibuat, diperbarui, atau dihapus. Demikian juga, Azure Route Table berisi blok siklus hidup untuk mencegah Terraform memperbarui sumber daya saat rute yang ditentukan pengguna dibuat, dihapus, atau diperbarui. Ini memungkinkan Anda mengelola aturan DNAT, aplikasi, dan jaringan Azure Firewall Policy dan rute yang ditentukan pengguna dari Tabel Rute Azure di luar kontrol Terraform.

Sampel yang terkait dengan artikel ini berisi alur CD Azure DevOps yang menunjukkan cara menyebarkan beban kerja ke kluster AKS privat dengan menggunakan alur Azure DevOps yang berjalan pada agen yang dihost sendiri. Sampel menyebarkan aplikasi web manajemen proyek redmine Bitnami dengan menggunakan bagan Helm publik. Diagram ini menunjukkan topologi jaringan sampel:

Berikut alur pesannya:

Permintaan untuk aplikasi web yang dihosting AKS dikirim ke IP publik yang diekspos oleh Azure Firewall melalui konfigurasi IP publik. IP publik dan konfigurasi IP publik didedikasikan untuk beban kerja ini.
Aturan DNAT Azure Firewall menerjemahkan alamat IP publik Azure Firewall dan port ke IP publik dan port yang digunakan oleh beban kerja di Load Balancer Standar publik Kubernetes dari kluster AKS di grup sumber daya simpul.
Load balancer mengirimkan permintaan ke salah satu pod layanan Kubernetes yang berjalan pada salah satu node agen kluster AKS.
Pesan respons dikirim kembali ke pemanggil asli melalui rute yang ditentukan pengguna. IP publik Azure Firewall adalah awalan alamat, dan Internet adalah jenis hop Berikutnya.
Setiap panggilan keluar yang dimulai beban kerja dirutekan ke alamat IP privat Azure Firewall dengan rute default yang ditentukan pengguna. 0.0.0.0/0 adalah awalan alamat, dan Appliance virtual adalah jenis hop Berikutnya.

Untuk informasi selengkapnya, lihat Menggunakan Azure Firewall di depan Load Balancer Standar Publik kluster AKS.

Menggunakan Azure Firewall di depan Load Balancer Standar internal

Dalam sampel yang terkait dengan artikel ini, aplikasi ASP.NET Core dihosting sebagai layanan oleh kluster AKS dan dibatasi oleh pengontrol ingress NGINX. Pengontrol ingress NGINX diekspos melalui load balancer internal yang memiliki alamat IP privat di jaringan virtual spoke yang menghosting kluster AKS. Untuk informasi selengkapnya, lihat Membuat pengontrol ingress ke jaringan virtual internal di AKS. Saat Anda menyebarkan pengontrol ingress NGINX, atau lebih umumnya layanan LoadBalancer atau ClusterIP , dengan service.beta.kubernetes.io/azure-load-balancer-internal: "true" anotasi di bagian metadata, load balancer standar internal yang disebut kubernetes-internal dibuat di bawah grup sumber daya simpul. Untuk informasi selengkapnya, lihat Menggunakan load balancer internal dengan AKS. Seperti yang ditunjukkan dalam diagram berikut, aplikasi web pengujian diekspos oleh Azure Firewall melalui IP publik Azure khusus.

Berikut alur pesannya:

Permintaan untuk aplikasi web pengujian yang dihosting AKS dikirim ke IP publik yang diekspos oleh Azure Firewall melalui konfigurasi IP publik. IP publik dan konfigurasi IP publik didedikasikan untuk beban kerja ini.
Aturan DNAT Azure Firewall menerjemahkan IP publik Azure Firewall dan port ke IP privat dan port yang digunakan oleh pengontrol ingress NGINX di Load Balancer Standar internal kluster AKS dalam grup sumber daya simpul.
Permintaan dikirim oleh load balancer internal ke salah satu pod layanan Kubernetes yang berjalan pada salah satu node agen kluster AKS.
Pesan respons dikirim kembali ke pemanggil asli melalui rute yang ditentukan pengguna. 0.0.0.0/0 adalah awalan alamat, dan Appliance virtual adalah jenis hop Berikutnya.
Setiap panggilan keluar yang dimulai beban kerja dirutekan ke alamat IP privat rute yang ditentukan pengguna.

Untuk informasi selengkapnya, lihat Menggunakan Azure Firewall di depan Load Balancer Standar internal.

Pertimbangan

Pertimbangan ini mengimplementasikan pilar Azure Well-Architected Framework, yang merupakan serangkaian tenet panduan yang dapat digunakan untuk meningkatkan kualitas beban kerja. Untuk informasi selengkapnya, lihat Microsoft Azure Well-Architected Framework.

Beberapa pertimbangan berikut adalah rekomendasi umum yang tidak spesifik untuk menggunakan Azure Firewall untuk meningkatkan perlindungan kluster AKS. Kami percaya mereka adalah persyaratan penting dari solusi ini. Ini berlaku untuk pertimbangan keamanan, performa, ketersediaan dan keandalan, penyimpanan, jala layanan, dan pemantauan.

Keamanan

Keamanan memberikan jaminan terhadap serangan yang disukai dan penyalahgunaan data dan sistem berharga Anda. Untuk informasi selengkapnya, lihat Gambaran Umum pilar keamanan.

Platform Azure memberikan perlindungan yang ditingkatkan terhadap berbagai ancaman, seperti penyusupan jaringan dan serangan penolakan layanan terdistribusi (DDoS). Anda harus menggunakan firewall aplikasi web (WAF) untuk memberikan perlindungan untuk aplikasi web dan layanan yang dihosting AKS yang mengekspos titik akhir HTTPS publik. Anda perlu memberikan perlindungan dari ancaman umum seperti injeksi SQL, scripting lintas situs, dan eksploitasi web lainnya. Untuk melakukannya, gunakan aturan Open Web Application Security Project (OWASP) dan aturan kustom. Azure Web Application Firewall memberikan perlindungan terpusat yang ditingkatkan dari aplikasi web Anda dari eksploitasi dan kerentanan umum. Anda dapat menyebarkan Azure WAF dengan Azure Application Gateway, Azure Front Door, dan Azure Content Delivery Network.

Serangan DDoS adalah salah satu masalah ketersediaan dan keamanan terbesar yang dihadapi organisasi yang memindahkan aplikasi mereka ke cloud. Serangan DDoS mencoba menghabiskan sumber daya aplikasi, sehingga membuat aplikasi tidak tersedia bagi pengguna yang sah. Serangan DDoS dapat ditargetkan di titik akhir apa pun yang dapat dijangkau secara publik melalui internet. Setiap properti di Azure menyertakan perlindungan melalui perlindungan infrastruktur Azure DDoS tanpa biaya tambahan. Skala dan kapasitas jaringan Azure yang disebarkan secara global memberikan peningkatan pertahanan terhadap serangan lapisan jaringan umum melalui pemantauan lalu lintas yang selalu aktif dan mitigasi real time. Perlindungan infrastruktur DDoS tidak memerlukan konfigurasi pengguna atau perubahan aplikasi. Ini membantu melindungi semua layanan Azure, termasuk layanan PaaS seperti Azure DNS.

Azure DDoS Network Protection, dikombinasikan dengan praktik terbaik desain aplikasi, menyediakan fitur mitigasi DDoS yang ditingkatkan untuk memberikan lebih banyak pertahanan terhadap serangan DDoS. Anda harus mengaktifkan Azure DDOS Network Protection di jaringan virtual perimeter apa pun.

Berikut ini adalah beberapa pertimbangan keamanan tambahan:

Buat titik akhir privat untuk layanan PaaS apa pun yang digunakan oleh beban kerja AKS, seperti Key Vault, Azure Bus Layanan, dan Azure SQL Database. Lalu lintas antara aplikasi dan layanan ini tidak terekspos ke internet publik. Lalu lintas antara jaringan virtual kluster AKS dan instans layanan PaaS melalui titik akhir privat menjelajahi jaringan backbone Microsoft, tetapi komunikasi tidak melewati Azure Firewall. Mekanisme ini memberikan keamanan yang lebih baik dan perlindungan yang lebih baik terhadap kebocoran data. Untuk informasi selengkapnya, lihat Apa itu Azure Private Link?.
Saat Anda menggunakan Application Gateway di depan kluster AKS, gunakan Kebijakan Firewall Aplikasi Web untuk membantu melindungi beban kerja yang menghadap publik yang berjalan pada AKS dari serangan.
Gunakan kebijakan jaringan untuk memisahkan dan membantu mengamankan komunikasi intraservice dengan mengontrol komponen mana yang dapat berkomunikasi satu dengan yang lain. Secara default, semua pod dalam kluster Kubernetes dapat mengirim dan menerima traffic tanpa batasan. Untuk meningkatkan keamanan, Anda dapat menggunakan kebijakan jaringan Azure atau kebijakan jaringan Calico untuk menentukan aturan yang mengontrol arus lalu lintas antara layanan mikro yang berbeda. Untuk informasi selengkapnya, lihat kebijakan jaringan.
Jangan mengekspos konektivitas jarak jauh ke node AKS Anda. Buat host bastion, atau jump box, dalam jaringan virtual manajemen. Gunakan host bastion untuk merutekan lalu lintas ke kluster AKS Anda.
Pertimbangkan untuk menggunakan kluster AKS privat di lingkungan produksi Anda, atau setidaknya akses aman ke server API, dengan menggunakan rentang alamat IP resmi di AKS. Saat Anda menggunakan rentang alamat IP resmi pada kluster publik, izinkan semua alamat IP keluar dalam kumpulan aturan jaringan Azure Firewall. Operasi dalam kluster menggunakan server API Kubernetes.
Jika Anda mengaktifkan proksi DNS di Azure Firewall, Azure Firewall dapat memproses dan meneruskan kueri DNS dari satu atau beberapa jaringan virtual ke server DNS yang Anda pilih. Fungsionalitas ini sangat penting dan diperlukan untuk pemfilteran FQDN yang andal dalam aturan jaringan. Anda dapat mengaktifkan proksi DNS di pengaturan Kebijakan Firewall dan Azure Firewall. Untuk mempelajari selengkapnya tentang log proksi DNS, lihat Log dan metrik Azure Firewall.
Saat menggunakan Azure Firewall di depan Application Gateway, Anda dapat mengonfigurasi sumber daya ingress Kubernetes untuk mengekspos beban kerja melalui HTTPS, dan menggunakan subdomain dan sertifikat digital terpisah untuk setiap penyewa. Pengontrol Ingress Application Gateway (AGIC) secara otomatis mengonfigurasi pendengar Application Gateway untuk penghentian Secure Sockets Layer (SSL).
Anda dapat menggunakan Azure Firewall di depan proksi layanan seperti pengontrol ingress NGINX. Pengontrol ini menyediakan proksi terbalik, perutean lalu lintas yang dapat dikonfigurasi, dan penghentian TLS untuk layanan Kubernetes. Sumber daya ingress Kubernetes digunakan untuk mengonfigurasi aturan dan rute ingress untuk masing-masing layanan Kubernetes. Dengan menggunakan pengontrol ingress dan aturan ingress, Anda dapat menggunakan satu alamat IP untuk merutekan lalu lintas ke beberapa layanan dalam kluster Kubernetes. Anda dapat membuat sertifikat TLS dengan menggunakan otoritas sertifikat yang dikenali. Atau, Anda dapat menggunakan Let's Encrypt untuk membuat sertifikat TLS secara otomatis dengan alamat IP publik dinamis atau dengan alamat IP publik statis. Untuk informasi selengkapnya, lihat Membuat pengontrol ingress HTTPS dan menggunakan sertifikat TLS Anda sendiri di AKS.
Koordinasi ketat di antara operator Azure Firewall dan tim kluster dan beban kerja diperlukan baik untuk penyebaran kluster awal maupun secara berkelanjutan karena beban kerja dan kebutuhan kluster berkembang. Ini terutama berlaku ketika Anda mengonfigurasi mekanisme autentikasi, seperti OAuth 2.0 dan OpenID Koneksi, yang digunakan oleh beban kerja untuk mengautentikasi klien mereka.
Gunakan panduan berikut untuk membantu mengamankan lingkungan yang dijelaskan dalam artikel ini:

Ketersediaan dan keandalan

Keandalan memastikan aplikasi Anda dapat mencapai komitmen yang Anda buat kepada pelanggan Anda. Untuk informasi selengkapnya, lihat Gambaran Umum pilar keandalan.

Pertimbangan ketersediaan dan keandalan di sini tidak khusus untuk multitenansi di AKS. Kami percaya mereka adalah persyaratan penting untuk solusi ini. Pertimbangkan metode berikut untuk mengoptimalkan ketersediaan kluster dan beban kerja AKS Anda.

Ketahanan intrawilayah

Selama penyebaran, Anda dapat mengonfigurasi Azure Firewall untuk menjangkau beberapa zona ketersediaan untuk peningkatan ketersediaan. Untuk persentase waktu aktif, lihat Azure Firewall SLA. Anda juga dapat mengaitkan Azure Firewall dengan zona tertentu demi kedekatan, meskipun konfigurasi ini memengaruhi SLA. Tidak ada biaya tambahan untuk firewall yang disebarkan di zona ketersediaan. Namun, ada biaya tambahan untuk transfer data masuk dan keluar yang terkait dengan zona ketersediaan. Untuk informasi selengkapnya, lihat Detail harga Bandwidth.
Pertimbangkan untuk menyebarkan kumpulan simpul kluster AKS Anda di semua zona ketersediaan di suatu wilayah. Gunakan Azure Standard Load Balancer atau Application Gateway di depan kumpulan simpul. Topologi ini memberikan ketahanan yang lebih baik jika ada pemadaman pusat data tunggal. Node kluster didistribusikan di beberapa pusat data, di tiga zona ketersediaan terpisah dalam suatu wilayah.
Aktifkan redundansi zona di Container Registry untuk ketahanan intra-wilayah dan ketersediaan tinggi.
Gunakan batasan penyebaran topologi pod untuk mengontrol bagaimana pod tersebar di kluster AKS Anda di antara domain kegagalan seperti wilayah, zona ketersediaan, dan simpul.
Pertimbangkan untuk menggunakan Uptime SLA untuk kluster AKS yang menghosting beban kerja mission-critical. Uptime SLA adalah fitur opsional yang memungkinkan SLA yang didukung secara finansial dan lebih tinggi untuk kluster. Waktu aktif SLA menjamin ketersediaan tinggi titik akhir server API Kubernetes untuk kluster yang menggunakan zona ketersediaan. Anda juga dapat menggunakannya untuk kluster yang tidak menggunakan zona ketersediaan, tetapi SLA lebih rendah. Untuk detail SLA, lihat Waktu Aktif SLA. AKS menggunakan replika simpul master di seluruh domain pembaruan dan kesalahan untuk memastikan persyaratan SLA terpenuhi.

Pemulihan bencana dan keberlangsungan bisnis

Pertimbangkan untuk menerapkan solusi Anda ke setidaknya dua wilayah Azure berpasangan dalam sebuah geografi. Gunakan load balancer global, seperti Azure Traffic Manager atau Azure Front Door, dengan metode perutean aktif/aktif atau aktif/pasif, untuk menjamin kelangsungan bisnis dan pemulihan bencana (DR).
Azure Firewall adalah layanan regional. Jika Anda menyebarkan solusi di dua wilayah atau lebih, Anda perlu membuat Azure Firewall di setiap wilayah. Anda dapat membuat Azure Firewall Policy global untuk menyertakan aturan yang diamanatkan organisasi yang berlaku untuk semua hub regional. Anda dapat menggunakan kebijakan ini sebagai kebijakan induk untuk kebijakan Azure regional. Kebijakan yang dibuat dengan kebijakan induk tidak kosong mewarisi semua koleksi aturan dari kebijakan induk. Kumpulan aturan jaringan yang diwarisi dari kebijakan induk selalu diprioritaskan di atas kumpulan aturan jaringan yang didefinisikan sebagai bagian dari kebijakan baru. Logika yang sama berlaku untuk kumpulan aturan aplikasi. Namun, kumpulan aturan jaringan selalu diproses sebelum pengumpulan aturan aplikasi, terlepas dari warisan. Untuk informasi selengkapnya tentang kebijakan Standar dan Premium, lihat Gambaran umum kebijakan Azure Firewall Manager.
Pastikan untuk membuat skrip, mendokumen, dan secara berkala menguji proses failover regional apa pun di lingkungan QA. Melakukannya membantu menghindari masalah yang tidak dapat diprediksi jika layanan inti dipengaruhi oleh pemadaman di wilayah utama. Pengujian ini juga memeriksa apakah pendekatan DR memenuhi target RPO/RTO, bersama dengan proses manual akhir dan intervensi yang diperlukan untuk failover.
Pastikan untuk menguji prosedur fail-back untuk memvalidasi bahwa prosedur tersebut berfungsi seperti yang diharapkan.
Simpan gambar kontainer Anda di Container Registry. Replikasi geografis registri ke setiap wilayah AKS. Untuk informasi selengkapnya, lihat Replikasi geografis di Azure Container Registry.
Jika memungkinkan, hindari menyimpan status layanan dalam kontainer. Sebagai gantinya, gunakan Azure PaaS yang mendukung replikasi multiregion.
Jika Anda menggunakan Azure Storage, siapkan dan uji proses untuk memigrasikan penyimpanan Anda dari wilayah utama ke wilayah cadangan.

Keunggulan operasional

Keunggulan operasional mencakup proses operasi yang menyebarkan aplikasi dan membuatnya tetap berjalan dalam produksi. Untuk informasi selengkapnya, lihat Gambaran umum pilar keunggulan operasional.

DevOps

Sebarkan beban kerja Anda ke AKS dengan menggunakan bagan Helm dalam alur integrasi berkelanjutan dan pengiriman berkelanjutan (CI/CD). Gunakan sistem DevOps seperti GitHub Actions atau Azure DevOps. Untuk informasi selengkapnya, lihat Membangun dan menyebarkan ke Azure Kubernetes Service.
Untuk menguji aplikasi dengan benar sebelum Anda membuatnya tersedia untuk pengguna, gunakan pengujian A/B dan penyebaran kenari dalam manajemen siklus hidup aplikasi Anda. Ada beberapa teknik yang dapat digunakan untuk membagi lalu lintas di berbagai versi layanan yang sama. Sebagai alternatif, Anda dapat menggunakan kemampuan pemisahan lalu lintas yang disediakan oleh implementasi service mesh. Untuk informasi selengkapnya, lihat Pemisahan Lalu Lintas Linkerd dan Manajemen Lalu Lintas Istio.
Gunakan Azure Container Registry atau registri kontainer lain (seperti Docker Hub) untuk menyimpan gambar Docker pribadi yang diterapkan ke kluster. AKS dapat mengautentikasi dengan Azure Container Registry dengan menggunakan identitas Microsoft Entra-nya.
Uji masuk dan keluar pada beban kerja Anda di lingkungan pra-produksi terpisah yang mencerminkan topologi jaringan dan aturan firewall lingkungan produksi Anda. Strategi peluncuran bertahap akan membantu Anda mendeteksi masalah jaringan atau keamanan sebelum Anda merilis fitur atau aturan jaringan baru ke dalam produksi.

Pemantauan

Azure Firewall sepenuhnya terintegrasi dengan Azure Monitor untuk mencatat lalu lintas masuk dan keluar yang diproses oleh firewall. Untuk informasi selengkapnya, lihat Pemfilteran berbasis inteligensi ancaman Azure Firewall.

Pertimbangan pemantauan berikut tidak spesifik untuk multipenyewa di AKS, tetapi kami yakin itu adalah persyaratan penting untuk solusi ini.

Gunakan wawasan Kontainer untuk memantau status kesehatan kluster dan beban kerja AKS.
Konfigurasikan semua layanan PaaS (seperti Container Registry dan Key Vault) untuk mengumpulkan log dan metrik diagnostik.

Pengoptimalan biaya

Biaya arsitektur yang dihasilkan tergantung pada detail konfigurasi berikut:

Tingkat layanan
Skalabilitas (jumlah instans yang dialokasikan secara dinamis oleh layanan untuk mendukung permintaan tertentu)
Skrip Automation
Tingkat pemulihan bencana Anda

Setelah Anda menilai detail konfigurasi ini, gunakan kalkulator harga Azure untuk memperkirakan biaya Anda. Untuk opsi pengoptimalan harga lainnya, lihat prinsip pengoptimalan biaya dalam Microsoft Azure Well-Architected Framework.

Menyebarkan skenario ini

Kode sumber untuk skenario ini tersedia di GitHub. Solusi ini merupakan sumber terbuka dan dilengkapi dengan Lisensi MIT.

Prasyarat

Untuk penyebaran online, Anda memerlukan akun Azure. Jika Anda tidak memilikinya, buat akun Azure gratis sebelum Memulai. Anda perlu memenuhi persyaratan ini sebelum dapat menyebarkan modul Terraform dengan menggunakan Azure DevOps:

Simpan file status Terraform di akun penyimpanan Azure. Untuk informasi selengkapnya tentang menggunakan akun penyimpanan untuk menyimpan status Terraform jarak jauh, penguncian status, dan enkripsi saat tidak aktif, lihat Menyimpan status Terraform di Azure Storage.
Buat proyek Azure DevOps. Untuk informasi selengkapnya, lihat Membuat proyek di Azure DevOps.
Buat koneksi layanan Azure DevOps ke langganan Azure Anda. Anda dapat menggunakan Autentikasi Perwakilan Layanan (SPA) atau identitas layanan terkelola Azure saat membuat koneksi layanan. Dalam kedua kasus tersebut, pastikan bahwa perwakilan layanan atau identitas terkelola yang digunakan oleh Azure DevOps untuk menyambungkan ke langganan Azure Anda diberi peran pemilik di seluruh langganan.

Penyebaran ke Azure

Buat informasi langganan Azure Anda berguna.

Kloning repositori GitHub workbench:

git clone https://github.com/Azure-Samples/private-aks-cluster-terraform-devops.git

Ikuti petunjuk yang diberikan di file GETSTARTED.md.

Kontributor

Artikel ini dikelola oleh Microsoft. Ini awalnya ditulis oleh kontributor berikut.

Penulis utama:

Paolo Salvatori | Teknisi Layanan Utama

Untuk melihat profil LinkedIn non-publik, masuk ke LinkedIn.

Langkah berikutnya

Tinjau rekomendasi dan praktik terbaik untuk AKS di Microsoft Azure Well-Architected Framework:

Menggunakan Azure Firewall untuk membantu melindungi kluster Azure Kubernetes Service (AKS)