Bersiap untuk menyebarkan beban kerja aplikasi web Amazon Web Services (AWS) ke Azure

Artikel ini menyediakan panduan komprehensif tentang cara menyebarkan infrastruktur yang kuat dan siap produksi untuk memfasilitasi hosting, perlindungan, penskalaan, dan pemantauan aplikasi web di platform Azure.

Penyebaran Yelb di AWS

Aplikasi web sampel Yelb di AWS disebarkan menggunakan Bash, AWS CLI, eksctl, kubectl, dan Helm. Sampel pendamping berisi skrip Bash dan manifes YAML yang dapat Anda gunakan untuk mengotomatiskan penyebaran aplikasi Yelb di AWS Elastic Kubernetes Service (EKS). Solusi ini menunjukkan cara menerapkan firewall aplikasi web menggunakan AWS WAF untuk melindungi aplikasi web yang berjalan di Amazon Elastic Kubernetes Service (EKS). Anda dapat menggunakan skrip Bash untuk membuat kluster EKS dan menyebarkan aplikasi Yelb . Aplikasi web Yelb diekspos ke internet publik menggunakan Amazon Application Load Balancer (ALB) dan dilindungi menggunakan daftar kontrol akses web AWS WAF (web ACL). Untuk petunjuk terperinci, lihat Porting Aplikasi Web dari AWS Elastic Kubernetes Service (EKS) ke Azure Kubernetes Service (AKS).

Penyebaran Yelb di Azure

Di bagian berikut, Anda mempelajari cara menyebarkan aplikasi web sampel Yelb pada kluster Azure Kubernetes Service (AKS) dan mengeksposnya melalui pengontrol ingress seperti pengontrol ingress NGINX. Layanan pengontrol ingress dapat diakses melalui load balancer internal (atau privat), yang menyeimbangkan lalu lintas dalam jaringan virtual yang menaungi kluster AKS. Dalam skenario hibrid, frontend load balancer dapat diakses dari jaringan lokal. Untuk mempelajari selengkapnya tentang penyeimbangan beban internal, lihat Menggunakan load balancer internal dengan Azure Kubernetes Service (AKS).

Sampel pendamping mendukung penginstalan pengontrol ingress NGINX terkelola dengan add-on perutean aplikasi atau pengontrol ingress NGINX yang tidak dikelola menggunakan bagan Helm. Add-on pengontrol ingress NGINX untuk routing aplikasi menyediakan fitur-fitur berikut:

• Konfigurasi mudah untuk pengontrol ingress NGINX terkelola yang didasarkan pada pengontrol ingress Kubernetes NGINX.
• Integrasi dengan Azure DNS untuk manajemen zona publik dan privat.
• Penghentian SSL dengan sertifikat yang disimpan di Azure Key Vault.

Untuk konfigurasi lain,

• Konfigurasi DNS dan SSL
• Konfigurasi tambahan perutean aplikasi
• Konfigurasikan kontroler ingress internal NGINX untuk zona DNS privat Azure.

Untuk meningkatkan keamanan, aplikasi Yelb dilindungi oleh sumber daya Azure Application Gateway . Sumber daya ini disebarkan dalam subnet khusus dalam jaringan virtual yang sama dengan kluster AKS atau dalam jaringan virtual yang di-peering. Azure Web Application Firewall (WAF) mengamankan akses ke aplikasi web yang dihosting di Azure Kubernetes Service (AKS) dan diekspos melalui Azure Application Gateway terhadap eksploitasi dan kerentanan umum.

Prasyarat

• Langganan Azure yang aktif. Jika Anda tidak memilikinya, buat akun Azure gratis sebelum Memulai.
• Peran bawaan Pemilik Azure, atau peran bawaan Administrator Akses Pengguna dan Kontributor, pada langganan di akun Azure Anda.
• Azure CLI versi 2.61.0 atau yang lebih baru. Untuk informasi selengkapnya, lihat Menginstal Azure CLI.
• Ekstensi pratinjau untuk Azure Kubernetes Service (AKS).
• jq versi 1.5 atau yang lebih baru.
• Python 3 atau yang lebih baru.
• kubectl versi 1.21.0 atau yang lebih baru
• Helm versi 3.0.0 atau yang lebih baru
• Visual Studio Code diinstal pada salah satu platform yang didukung bersama dengan ekstensi Bicep.
• Sumber daya Azure Key Vault yang ada dengan sertifikat TLS yang valid untuk aplikasi web Yelb.
• Zona Azure DNS yang ada atau server DNS yang setara untuk resolusi nama aplikasi Yelb.

Arsitektur

Sampel ini menyediakan kumpulan templat Bicep , skrip Bash, dan manifes YAML untuk membangun kluster AKS, menyebarkan aplikasi Yelb , mengekspos layanan UI menggunakan pengontrol ingress NGINX, dan melindunginya dengan Azure Application Gateway dan Azure Web Application Firewall (WAF).

Sampel ini juga mencakup dua file parameter Bicep terpisah dan dua set skrip Bash dan manifes YAML, masing-masing diarahkan untuk menyebarkan dua opsi solusi yang berbeda. Untuk informasi selengkapnya tentang Bicep, lihat Apa itu Bicep?

Penghentian TLS pada Application Gateway dan pemanggilan Yelb melalui HTTP

Dalam solusi ini, Azure Web Application Firewall (WAF) memastikan keamanan sistem dengan memblokir serangan berbahaya. Azure Application Gateway menerima panggilan masuk dari aplikasi klien, melakukan penghentian TLS, dan meneruskan permintaan ke layanan yang dihosting yelb-ui AKS. Komunikasi ini dicapai melalui load balancer internal dan pengontrol ingress NGINX menggunakan protokol transportasi HTTP. Diagram berikut mengilustrasikan arsitektur:

Alur pesan adalah sebagai berikut:

1. Azure Application Gateway menangani penghentian TLS dan mengirim panggilan masuk ke layanan yang dihosting yelb-ui AKS melalui HTTP.
2. Listener Application Gateway menggunakan sertifikat SSL yang diperoleh dari Azure Key Vault untuk memastikan komunikasi yang aman.
3. Kebijakan Azure WAF yang terkait dengan Listener menerapkan aturan OWASP dan aturan kustom untuk permintaan masuk, secara efektif mencegah banyak jenis serangan berbahaya.
4. Pengaturan HTTP Backend Application Gateway memanggil aplikasi Yelb melalui HTTP menggunakan port 80.
5. Kumpulan Backend Application Gateway dan Pemeriksaan Kesehatan memanggil pengontrol ingress NGINX melalui load balancer internal AKS menggunakan protokol HTTP untuk manajemen lalu lintas.
6. Pengontrol ingress NGINX menggunakan load balancer internal AKS untuk memastikan komunikasi yang aman dalam kluster.
7. Objek ingress Kubernetes menggunakan pengontrol ingress NGINX untuk mengekspos aplikasi melalui HTTP melalui load balancer internal.
8. yelb-ui Layanan dengan jenis ClusterIP membatasi pemanggilannya hanya di dalam kluster atau melalui pengontrol ingress "NGINX".

Menerapkan TLS end-to-end menggunakan Azure Application Gateway

Penghentian TLS

Azure Application Gateway mendukung penghentian TLS di tingkat gateway, yang berarti bahwa lalu lintas didekripsi di gateway sebelum dikirim ke server backend. Untuk mengonfigurasi penghentian TLS, Anda perlu menambahkan sertifikat TLS/SSL ke pendengar. Sertifikat harus dalam format Pertukaran Informasi Pribadi (PFX), yang berisi kunci privat dan publik. Anda dapat mengimpor sertifikat dari Azure Key Vault ke Application Gateway. Untuk informasi selengkapnya, lihat penghentian TLS dengan sertifikat Key Vault.

Model keamanan Zero Trust

Jika Anda mengadopsi model keamanan Zero Trust , Anda harus mencegah komunikasi yang tidak terenkripsi antara proksi layanan seperti Azure Application Gateway dan server backend. Dengan model keamanan Zero Trust, kepercayaan tidak secara otomatis diberikan kepada pengguna atau perangkat apa pun yang mencoba mengakses sumber daya dalam jaringan. Sebaliknya, diperlukan verifikasi identitas dan otorisasi berkelanjutan untuk setiap permintaan, terlepas dari lokasi atau jaringan pengguna. Dalam skenario kami, menerapkan model keamanan Zero Trust melibatkan penggunaan Azure Application Gateway sebagai proksi layanan, yang bertindak sebagai front-end untuk permintaan masuk. Permintaan ini kemudian melakukan perjalanan ke pengontrol ingress NGINX di Azure Kubernetes Service (AKS) dalam format terenkripsi.

TLS ujung-ke-ujung dengan Gateway Aplikasi

Anda dapat menerapkan pendekatan Zero Trust dengan mengonfigurasi Azure Application Gateway untuk enkripsi TLS end-to-end dengan server backend. Enkripsi TLS end-to-end memungkinkan Anda mengirimkan data sensitif dengan aman ke backend sambil memanfaatkan fitur penyeimbangan beban lapisan 7 Application Gateway, termasuk afinitas sesi berbasis cookie, perutean berbasis URL, perutean berdasarkan situs, dan kemampuan untuk menulis ulang atau menyuntikkan header X-Forwarded-*.

Ketika Application Gateway dikonfigurasi dengan mode komunikasi TLS end-to-end, Application Gateway mengakhiri sesi TLS di gateway dan mendekripsi lalu lintas pengguna. Kemudian menerapkan aturan yang dikonfigurasi untuk memilih instans kumpulan backend yang sesuai guna mengarahkan lalu lintas. Selanjutnya, Application Gateway memulai koneksi TLS baru ke server backend dan mendekripsi ulang data menggunakan sertifikat kunci publik server backend sebelum mengirimkan permintaan ke backend. Respons dari server web mengikuti proses yang sama sebelum mencapai pengguna akhir. Untuk mengaktifkan TLS end-to-end, Anda perlu mengatur pengaturan protokol di Pengaturan HTTP Backend ke HTTPS dan menerapkannya ke kumpulan backend. Pendekatan ini memastikan bahwa komunikasi Anda dengan server backend diamankan dan sesuai dengan kebutuhan Anda.

Untuk informasi selengkapnya, lihat Enkripsi TLS end-to-end Application Gateway dan Praktik terbaik untuk mengamankan Application Gateway Anda.

Dalam solusi ini, Azure Web Application Firewall (WAF) memastikan keamanan sistem dengan memblokir serangan berbahaya. Azure Application Gateway menangani panggilan masuk dari aplikasi klien, melakukan penghentian TLS, dan menerapkan TLS end-to-end dengan memanggil layanan yang dihosting yelb-ui AKS yang mendasar menggunakan protokol transportasi HTTPS melalui load balancer internal dan pengontrol ingress NGINX. Diagram berikut mengilustrasikan arsitektur:

Alur pesan adalah sebagai berikut:

1. Azure Application Gateway menangani penghentian TLS dan berkomunikasi dengan aplikasi backend melalui HTTPS.
2. Listener Application Gateway menggunakan sertifikat SSL yang diperoleh dari Azure Key Vault.
3. Kebijakan Azure WAF yang terkait dengan Listener menjalankan aturan OWASP dan aturan kustom terhadap permintaan masuk untuk memblokir serangan berbahaya.
4. Pengaturan HTTP Backend Application Gateway dikonfigurasi untuk memanggil layanan AKS yang dihosting yelb-ui melalui HTTPS pada port 443.
5. Kumpulan Backend Pool dan Health Probe Application Gateway memanggil pengontrol ingress NGINX melalui load balancer internal AKS menggunakan HTTPS.
6. Pengontrol ingress NGINX dikonfigurasi untuk menggunakan load balancer internal AKS.
7. SAKS cluster dikonfigurasi dengan add-on Azure Key Vault provider untuk Driver Secrets Store CSI agar dapat mengambil rahasia, sertifikat, dan kunci dari Azure Key Vault melalui volume CSI.
8. SecretProviderClass digunakan untuk mengambil sertifikat yang digunakan oleh Application Gateway dari Key Vault.
9. Objek ingress Kubernetes menggunakan NGINX ingress controller untuk mengekspos aplikasi melalui HTTPS melalui penyeimbang beban internal AKS.
10. Layanan yelb-ui ini memiliki ClusterIP jenis, yang membatasi pemanggilannya ke dalam kluster atau melalui pengontrol ingress NGINX.

Untuk membantu memastikan keamanan dan stabilitas sistem, pertimbangkan rekomendasi berikut:

• Perbarui Azure WAF Policy secara teratur dengan aturan terbaru untuk memastikan keamanan yang optimal.
• Terapkan mekanisme pemantauan dan pengelogan untuk melacak dan menganalisis permintaan masuk dan potensi serangan.
• Secara teratur melakukan pemeliharaan dan pembaruan kluster AKS, pengontrol ingress NGINX, dan Application Gateway untuk mengatasi kerentanan keamanan apa pun dan mempertahankan infrastruktur yang aman.
• Terapkan mekanisme pemantauan dan pengelogan untuk melacak dan menganalisis permintaan masuk dan potensi serangan.
• Secara teratur melakukan pemeliharaan dan pembaruan kluster AKS, pengontrol ingress NGINX, dan Application Gateway untuk mengatasi kerentanan keamanan apa pun dan mempertahankan infrastruktur yang aman.

Nama host

Listener Application Gateway dan ingress Kubernetes dikonfigurasi untuk menggunakan nama host yang sama. Penting untuk menggunakan nama host yang sama untuk proksi layanan dan aplikasi web backend karena alasan berikut:

• Preservasi status sesi: Saat Anda menggunakan nama host yang berbeda untuk proksi dan aplikasi backend, status sesi dapat hilang. Ini berarti bahwa sesi pengguna mungkin tidak bertahan dengan benar, mengakibatkan pengalaman pengguna yang buruk dan potensi kehilangan data.
• Kegagalan autentikasi: Jika nama host berbeda antara proksi dan aplikasi backend, mekanisme autentikasi mungkin gagal. Pendekatan ini dapat menyebabkan pengguna tidak dapat masuk atau mengakses sumber daya aman dalam aplikasi.
• Paparan URL yang tidak disengaja: Jika nama host tidak dipertahankan, ada risiko bahwa URL backend mungkin terekspos ke pengguna akhir. Hal ini dapat menyebabkan potensi kerentanan keamanan dan akses tidak sah ke informasi sensitif.
• Masalah cookie: Cookie memainkan peran penting dalam mempertahankan sesi pengguna dan meneruskan informasi antara klien dan server. Ketika nama host berbeda, cookie mungkin tidak berfungsi seperti yang diharapkan, yang menyebabkan masalah seperti autentikasi yang gagal, penanganan sesi yang tidak tepat, dan pengalihan yang salah.
• Persyaratan TLS/SSL end-to-end: Jika TLS/SSL end-to-end diperlukan untuk komunikasi yang aman antara proksi dan layanan backend, sertifikat TLS yang cocok untuk nama host asli diperlukan. Menggunakan nama host yang sama menyederhanakan proses manajemen sertifikat dan memastikan bahwa komunikasi aman terjalin dengan mulus.

Anda dapat menghindari masalah ini dengan menggunakan nama host yang sama untuk proksi layanan dan aplikasi web backend. Aplikasi backend melihat domain yang sama dengan browser web, memastikan bahwa status sesi, autentikasi, dan fungsi penanganan URL dengan benar.

Alur Pesan

Diagram berikut menunjukkan langkah-langkah untuk alur pesan selama penyebaran dan runtime.

Alur kerja penyebaran

Langkah-langkah berikut menjelaskan proses penyebaran. Alur kerja ini sesuai dengan angka hijau dalam diagram sebelumnya.

1. Teknisi keamanan menghasilkan sertifikat untuk domain kustom yang digunakan beban kerja, dan menyimpannya di brankas kunci Azure. Anda dapat memperoleh sertifikat yang valid dari otoritas sertifikasi (CA) terkenal.
2. Teknisi platform menentukan informasi yang diperlukan dalam file parameter bicep main.bicepparams dan menyebarkan templat Bicep untuk membuat sumber daya Azure. Informasi yang diperlukan meliputi:
   • Awalan untuk sumber daya Azure.
   • Nama dan grup sumber daya Azure Key Vault yang ada yang menyimpan sertifikat TLS untuk nama host beban kerja dan domain kustom pendengar Application Gateway.
3. Anda dapat mengonfigurasi skrip penyebaran untuk menginstal paket berikut ke kluster AKS Anda. Untuk informasi selengkapnya, periksa bagian parameter modul Bicep.
   • Prometheus dan Grafana menggunakan Helm charts komunitas Kubernetes Prometheus: Secara default, konfigurasi sampel ini tidak menginstal Prometheus dan Grafana pada kluster AKS. Sebaliknya, ia menginstal Azure Managed Prometheus dan Azure Managed Grafana.
   • cert-manager: Certificate Manager tidak diperlukan dalam sampel ini, karena pengontrol ingress Application Gateway dan NGINX menggunakan sertifikat TLS yang telah diunggah sebelumnya dari Azure Key Vault.
   • Pengontrol ingress NGINX melalui bagan Helm: Jika Anda menggunakan pengontrol ingress NGINX terkelola dengan add-on perutean aplikasi, Anda tidak perlu menginstal instans lain dari pengontrol ingress NGINX melalui Helm.
4. Pendengar Application Gateway mengambil sertifikat TLS dari Azure Key Vault.
5. Objek ingress Kubernetes menggunakan sertifikat yang diperoleh dari penyedia Azure Key Vault untuk Secrets Store CSI Driver untuk mengekspos layanan UI Yelb melalui HTTPS.
6. Pendengar Application Gateway mengambil sertifikat TLS dari Azure key Vault.
7. Objek ingress Kubernetes menggunakan sertifikat yang diperoleh dari penyedia Azure Key Vault untuk Secrets Store CSI Driver untuk mengekspos layanan UI Yelb melalui HTTPS.

Alur kerja pada saat runtime

1. Aplikasi klien memanggil aplikasi web sampel menggunakan nama host-nya. Zona DNS yang terkait dengan domain kustom Pendengar Application Gateway menggunakan catatan A untuk menyelesaikan kueri DNS dengan alamat IP publik Azure yang digunakan oleh konfigurasi IP front-end Application Gateway.
2. Permintaan dikirim ke IP publik Azure yang digunakan oleh konfigurasi IP front-end Application Gateway.
3. Application Gateway melakukan tindakan berikut:
   1. Application Gateway menangani penghentian TLS dan berkomunikasi dengan aplikasi backend melalui HTTPS.
   2. Listener Application Gateway menggunakan sertifikat SSL yang diperoleh dari Azure Key Vault.
   3. Kebijakan Azure WAF yang terkait dengan Listener menjalankan aturan OWASP dan aturan kustom terhadap permintaan masuk dan memblokir serangan berbahaya.
   4. Pengaturan HTTP Backend Application Gateway dikonfigurasi untuk memanggil aplikasi web sampel melalui HTTPS pada port 443.
4. Pool Backend Application Gateway memanggil NGINX ingress controller melalui load balancer internal AKS menggunakan HTTPS.
5. Permintaan dikirim ke salah satu node agen yang menghosting pod pengontrol ingress NGINX.
6. Salah satu replika pengontrol ingress NGINX menangani permintaan dan mengirim permintaan ke salah satu endpoint layanan dari layanan yelb-ui.
7. yelb-ui memanggil layanan yelb-appserver.
8. yelb-appserver memanggil layanan yelb-db dan yelb-cache.
9. yelb-ui memanggil layanan yelb-appserver.
10. yelb-appserver memanggil layanan yelb-db dan yelb-cache.

Penyebaran

Secara default, templat Bicep menginstal kluster AKS dengan plugin jaringan Azure CNI Overlay dan sarana data Cilium . Anda dapat menggunakan plugin jaringan alternatif. Selain itu, proyek menunjukkan cara menyebarkan kluster AKS dengan ekstensi dan fitur berikut:

• ID Beban Kerja Microsoft Entra
• Add-on mesh layanan berbasis Istio
• Integrasi API Server VNET
• Azure NAT Gateway
• Add-on autoscaling berbasis peristiwa (KEDA)
• Ekstensi Dapr
• Ekstensi Flux V2
• Pod Vertikal Autoscaling
• Penyedia Azure Key Vault untuk Secrets Store CSI Driver
• Pembersih Gambar
• Observabilitas Jaringan Azure Kubernetes Service (AKS)
• Ingress NGINX terkelola dengan add-on perutean aplikasi

Di lingkungan produksi, sebaiknya sebarkan kluster AKS privat dengan SLA Waktu Aktif. Untuk informasi selengkapnya, lihat kluster AKS privat dengan alamat DNS publik.

Atau, Anda dapat menyebarkan kluster AKS publik dan mengamankan akses ke server API menggunakan rentang alamat IP resmi. Untuk informasi terperinci dan instruksi tentang cara menyebarkan infrastruktur di Azure menggunakan templat Bicep, lihat sampel kode Azure pendamping.

Di lingkungan produksi, sebaiknya sebarkan kluster AKS privat dengan SLA Waktu Aktif. Untuk informasi selengkapnya, lihat kluster AKS privat dengan alamat DNS Publik. Atau, Anda dapat menyebarkan kluster AKS publik dan mengamankan akses ke server API menggunakan rentang alamat IP resmi. Untuk informasi terperinci dan instruksi tentang cara menyebarkan infrastruktur di Azure menggunakan templat Bicep, lihat sampel kode Azure pendamping.

Langkah berikutnya

Menyebarkan beban kerja aplikasi web AWS ke Azure

Kontributor

Microsoft mempertahankan artikel ini. Kontributor berikut awalnya menulisnya:

Penulis utama:

• Paolo Salvatori | Insinyur Pelanggan Utama

Kontributor lain:

• Ken Kilty | TPM Utama
• Russell de Pina | TPM Utama
• Erin Schaffer | Pengembang Konten 2