Praktik terbaik untuk konektivitas jaringan dan keamanan di Azure Kubernetes Service (AKS)

  • Artikel

Saat membuat dan mengelola klaster di Azure Kubernetes Service (AKS), kamu menyediakan konektivitas jaringan untuk node dan aplikasi. Sumber daya jaringan ini mencakup rentang alamat IP, penyeimbang muatan, dan pengontrol ingress.

Artikel praktik terbaik ini berfokus pada konektivitas dan keamanan jaringan untuk operator klaster. Dalam artikel ini, Anda akan mempelajari cara:

  • Bandingkan mode jaringan Kubenet dan Azure Container Networking Interface (CNI) dalam AKS.
  • Rencanakan untuk mengatasi IP dan konektivitas yang diperlukan.
  • Distribusikan lalu lintas menggunakan penyeimbang muatan, pengontrol ingress, atau firewall aplikasi web (WAF).
  • Sambungkan dengan aman ke node kluster.

Pilih model jaringan yang sesuai

Panduan praktik terbaik

Gunakan jaringan Azure CNI di AKS untuk integrasi dengan jaringan virtual atau jaringan lokal yang ada. Model jaringan ini memungkinkan pemisahan sumber daya dan kontrol yang lebih besar di lingkungan perusahaan.

Jaringan virtual memberikan konektivitas dasar untuk node AKS dan pelanggan untuk mengakses aplikasi Anda. Ada dua cara berbeda untuk menyebarkan klaster AKS ke jaringan virtual:

  • Jaringan Azure CNI: Menyebarkan ke jaringan virtual dan menggunakan plugin Azure CNI Kubernetes. Pod menerima IP individual yang dapat merutekan ke layanan jaringan lain atau sumber daya lokal.
  • Jaringan Kubenet: Azure mengelola sumber daya jaringan virtual saat kluster disebarkan dan menggunakan plugin Kubenet Kubernetes.

Azure CNI dan kubenet adalah opsi yang valid untuk penyebaran produksi.

Penjaringan CNI

Azure CNI adalah protokol netral vendor yang memungkinkan runtime kontainer membuat permintaan ke penyedia jaringan. Ini menetapkan alamat IP ke Pod dan node, dan menyediakan fitur manajemen alamat IP (IPAM) saat Anda terhubung ke jaringan virtual Azure yang ada. Setiap simpul dan sumber daya pod menerima alamat IP di jaringan virtual Azure. Tidak perlu perutean ekstra untuk berkomunikasi dengan sumber daya atau layanan lain.

Diagram memperlihatkan dua node dengan jembatan yang menghubungkan masing-masing ke satu Azure VNet

Terutama, jaringan Azure CNI untuk produksi memungkinkan pemisahan kontrol dan manajemen sumber daya. Dari perspektif keamanan, Anda sering ingin tim yang berbeda untuk mengelola dan mengamankan sumber daya tersebut. Dengan jaringan Azure CNI, Anda terhubung ke sumber daya Azure yang ada, sumber daya lokal, atau layanan lain secara langsung melalui alamat IP yang ditetapkan untuk setiap Pod.

Saat Anda menggunakan jaringan Azure CNI, sumber daya jaringan virtual berada dalam grup sumber daya terpisah ke klaster AKS. Delegasikan izin untuk identitas klaster AKS untuk mengakses dan mengelola sumber daya ini. Identitas kluster yang digunakan oleh kluster AKS harus memiliki setidaknya izin Kontributor Jaringan pada subnet dalam jaringan virtual Anda.

Jika Anda ingin menentukan peran kustom alih-alih menggunakan peran Kontributor Jaringan bawaan, diperlukan izin berikut:

  • Microsoft.Network/virtualNetworks/subnets/join/action
  • Microsoft.Network/virtualNetworks/subnets/read

Secara default, AKS menggunakan identitas terkelola untuk identitas klasternya. Namun, Anda dapat menggunakan perwakilan layanan sebagai gantinya.

Karena setiap node dan Pod menerima alamat IP-nya sendiri, rencanakan rentang alamat untuk subnet AKS. Ingatlah kriteria berikut:

  • Subnet harus cukup besar untuk menyediakan alamat IP untuk setiap node, pod, dan sumber daya jaringan yang Anda sebarkan.
    • Dengan jaringan kubenet dan Azure CNI, setiap simpul yang berjalan memiliki batas default untuk jumlah pod.
  • Hindari menggunakan rentang alamat IP yang tumpang tindih dengan sumber daya jaringan yang ada.
    • Anda perlu mengizinkan konektivitas ke jaringan lokal atau yang di-peering di Azure.
  • Untuk menangani peningkatan skala peristiwa atau kluster, Anda memerlukan alamat IP tambahan yang tersedia di subnet yang ditetapkan.
    • Ruang alamat ekstra ini sangat penting jika Anda menggunakan kontainer Windows Server, karena kumpulan node tersebut memerlukan pemutakhiran untuk menerapkan patch keamanan terbaru. Untuk informasi selengkapnya tentang peningkatan kumpulan node Windows Server, lihat Peningkatan kumpulan node di AKS.

Untuk menghitung alamat IP yang diperlukan, lihat Mengonfigurasi jaringan Azure CNI di AKS.

Saat membuat klaster dengan jaringan Azure CNI, Anda menentukan rentang alamat lain untuk klaster, seperti alamat jembatan Docker, IP layanan DNS, dan rentang alamat layanan. Secara umum, pastikan rentang alamat ini tidak saling tumpang tindih atau jaringan apa pun yang terkait dengan kluster, termasuk jaringan virtual, subnet, jaringan lokal, dan jaringan yang di-peering.

Untuk detail spesifik seputar batas dan ukuran untuk rentang alamat ini, lihat Mengonfigurasi jaringan Azure CNI di AKS.

Jaringan Kubenet

Meskipun kubenet tidak mengharuskan Anda untuk mengonfigurasi jaringan virtual sebelum menyebarkan kluster, ada kerugian untuk menunggu, seperti:

  • Karena node dan Pod ditempatkan pada subnet IP yang berbeda, User Defined Routing (UDR) dan IP forwarding merutekan traffic antara Pod dan node. Perutean ekstra ini dapat mengurangi kinerja jaringan.
  • Koneksi ke jaringan lokal yang ada atau mengintip ke jaringan virtual Azure lainnya bisa rumit.

Karena Anda tidak membuat jaringan virtual dan subnet secara terpisah dari kluster AKS, Kubenet sangat ideal untuk skenario berikut:

  • Pengembangan kecil atau beban kerja pengujian.
  • Situs web sederhana dengan lalu lintas rendah.
  • Mengangkat dan memindahkan beban kerja ke dalam kontainer.

Untuk deployment produksi, baik kubenet maupun Azure CNI adalah opsi yang valid. Lingkungan yang memerlukan pemisahan kontrol dan manajemen, Azure CNI mungkin merupakan opsi yang disukai. Selain itu, kubenet cocok untuk lingkungan khusus Linux di mana konservasi rentang alamat IP adalah prioritas.

Anda juga dapat mengonfigurasi rentang alamat IP dan jaringan virtual anda sendiri menggunakan kubenet. Seperti jaringan Azure CNI, rentang alamat ini tidak boleh saling tumpang tindih atau jaringan apa pun yang terkait dengan kluster (jaringan virtual, subnet, lokal, dan jaringan yang di-peering).

Untuk detail spesifik seputar batasan dan ukuran untuk rentang alamat ini, lihat Menggunakan jaringan kubenet dengan rentang alamat IP Anda sendiri di AKS.

Mendistribusikan lalu lintas ingress

Panduan praktik terbaik

Untuk mendistribusikan lalu lintas HTTP atau HTTPS ke aplikasi Anda, gunakan sumber daya dan pengontrol masuk. Dibandingkan dengan load balancer Azure, kontroler ingress menyediakan fitur tambahan dan dapat dikelola sebagai sumber daya Kubernetes asli.

Meskipun penyeimbang muatan Azure dapat mendistribusikan lalu lintas pelanggan ke aplikasi di klaster AKS Anda, namun sebatas memahami lalu lintas tersebut. Sumber daya load balancer bekerja di lapisan 4 dan mendistribusikan lalu lintas berdasarkan protokol atau port.

Sebagian besar aplikasi web yang menggunakan HTTP atau HTTPS harus menggunakan sumber daya dan pengontrol ingress Kubernetes, yang berfungsi pada lapisan 7. Ingress dapat mendistribusikan lalu lintas berdasarkan URL aplikasi dan menangani penghentian TLS / SSL. Ingress juga mengurangi jumlah alamat IP yang Anda ekspose dan petakan.

Dengan load balancer, setiap aplikasi biasanya memerlukan alamat IP publik yang ditetapkan dan dipetakan ke layanan di klaster AKS. Dengan sumber daya masuk, satu alamat IP dapat mendistribusikan lalu lintas ke beberapa aplikasi.

Diagram memperlihatkan arus traffic NodePort dalam klaster AKS

Ada dua komponen untuk ingress:

  1. Resource ingress
  2. Controller ingress

Sumber daya Ingress

Sumber daya ingress adalah manifes YAML dari kind: Ingress. Hal ini mendefinisikan host, sertifikat, dan aturan untuk merutekan lalu lintas ke layanan yang sedang berjalan di klaster AKS Anda.

Contoh manifes YAML berikut mendistribusikan lalu lintas untuk myapp.com ke salah satu dari dua layanan, blogservice atau storeservice, dan mengarahkan pelanggan ke satu layanan atau yang lain berdasarkan URL yang mereka akses.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
 name: myapp-ingress
spec:
 ingressClassName: PublicIngress
 tls:
 - hosts:
   - myapp.com
   secretName: myapp-secret
 rules:
   - host: myapp.com
     http:
      paths:
      - path: /blog
        backend:
         service:
           name: blogservice
           port: 80
      - path: /store
        backend:
         service:
           name: storeservice
           port: 80

Kontreler ingress

ingress controlle adalah daemon yang berjalan pada node AKS dan mengawasi permintaan yang masuk. Lalu lintas kemudian didistribusikan berdasarkan aturan yang ditentukan dalam sumber daya ingress. Meskipun pengontrol ingress yang paling umum didasarkan pada NGINX, AKS tidak membatasi Anda untuk pengontrol tertentu. Anda dapat menggunakan Contour, HAProxy, Traefik, dll.

Pengontrol Ingress harus dijadwalkan pada node Linux. Tunjukkan bahwa resource harus berjalan pada node berbasis Linux menggunakan sesingat node dalam manifes YAML atau penyebaran bagan Helm Anda. Untuk informasi lebih lanjut, lihat Menggunakan pemilih node untuk mengontrol di mana Pod dijadwalkan di AKS.

Masuk dengan addon perutean aplikasi

Addon perutean aplikasi adalah cara yang disarankan untuk mengonfigurasi pengontrol Ingress di AKS. Addon perutean aplikasi adalah pengontrol ingress yang dikelola sepenuhnya untuk Azure Kubernetes Service (AKS) yang menyediakan fitur-fitur berikut:

  • Konfigurasi mudah pengontrol NGINX Ingress terkelola berdasarkan 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 informasi selengkapnya tentang add-on perutean aplikasi, lihat ingress NGINX terkelola dengan add-on perutean aplikasi.

Mengamankan lalu lintas dengan firewall aplikasi web (WAF)

Panduan praktik terbaik

Untuk memindai lalu lintas yang masuk atas potensi serangan, gunakan firewall aplikasi web (WAF) seperti Barracuda WAF untuk Azure atau Azure Application Gateway. Sumber daya jaringan yang lebih canggih ini juga dapat merutekan lalu lintas hanya melalui koneksi HTTP dan HTTPS atau penghentian TLS dasar.

Biasanya, sebuah pengontrol ingress adalah resource Kubernetes di klaster AKS yang mendistribusikan traffic ke layanan dan aplikasi. Pengontrol berjalan sebagai daemon pada node AKS, dan mengkonsumsi beberapa sumber daya node, seperti CPU, memori, dan bandwidth jaringan. Di lingkungan yang lebih besar, Anda mungkin ingin mempertimbangkan hal berikut:

  • Offload beberapa perutean lalu lintas ini atau penghentian TLS ke sumber daya jaringan di luar klaster AKS.
  • Pindai lalu lintas yang masuk untuk potensi serangan.

Firewall aplikasi web (WAF) seperti Azure App Gateway dapat melindungi dan mendistribusikan lalu lintas untuk klaster AKS Anda

Untuk lapisan keamanan ekstra itu, firewall aplikasi web (WAF) memfilter lalu lintas yang masuk. Dengan seperangkat aturan, Open Web Application Security Project (OWASP) mengawasi serangan seperti scripting lintas situs atau keracunan cookie. Azure Application Gateway (saat ini dalam pratinjau di AKS) adalah WAF yang terintegrasi dengan kluster AKS, mengunci fitur keamanan ini sebelum lalu lintas mencapai kluster dan aplikasi AKS Anda.

Karena solusi pihak ketiga lainnya juga melakukan fungsi-fungsi ini, Anda dapat terus menggunakan investasi atau keahlian yang ada dalam produk pilihan Anda.

Muat sumber daya penyeimbang atau ingress yang terus berjalan di klaster AKS Anda dan perbaiki distribusi lalu lintas. App Gateway dapat dikelola secara terpusat sebagai pengontrol ingress dengan definisi sumber daya. Untuk memulai, buat pengontrol Application Gateway Ingress.

Mengontrol arus lalu lintas dengan kebijakan jaringan

Panduan praktik terbaik

Gunakan kebijakan jaringan untuk mengizinkan atau menolak traffic ke Pod. Secara default, semua traffic diperbolehkan antar Pod dalam sebuah klaster. Untuk peningkatan keamanan, tentukan aturan yang membatasi komunikasi Pod.

Kebijakan jaringan adalah fitur Kubernetes yang tersedia di AKS yang memungkinkan Anda mengontrol arus traffic antar Pod. Anda mengizinkan atau menolak traffic berdasarkan setelan seperti label yang ditetapkan, namespace, atau portal traffic. Kebijakan jaringan adalah cara cloud-native untuk mengontrol arus lalu lintas bagi Pod. Kebijakan jaringan yang diperlukan dapat diterapkan secara otomatis karena pod dibuat secara dinamis dalam klaster AKS.

Untuk menggunakan kebijakan jaringan, aktifkan fitur saat Anda membuat klaster AKS baru. Anda tidak bisa mengaktifkan kebijakan jaringan pada kluster AKS yang ada. Rencanakan ke depan untuk mengaktifkan kebijakan jaringan pada kluster yang diperlukan.

Catatan

Kebijakan jaringan hanya boleh digunakan untuk simpul dan pod berbasis Linux di AKS.

Kamu membuat kebijakan jaringan sebagai sumber daya Kubernetes menggunakan manifes YAML. Kebijakan diterapkan pada Pod yang ditentukan, dengan aturan ingress atau egress yang mendefinisikan arus lalu lintas.

Contoh berikut menerapkan kebijakan jaringan pada Pod dengan app: backend label yang diterapkan pada mereka. Aturan ingress hanya memungkinkan lalu lintas dari pod dengan aplikasi: label frontend .

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: backend-policy
spec:
  podSelector:
    matchLabels:
      app: backend
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend

Pelajari selengkapnya mengenai ini di Mengamankan traffic antara pod menggunakan kebijakan jaringan di Azure Kubernetes Service (AKS).

Sambungkan dengan aman ke node melalui host bastion

Panduan praktik terbaik

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 klaster AKS Anda dengan aman ke tugas manajemen jarak jauh.

Kamu dapat menyelesaikan sebagian besar operasi di AKS menggunakan alat manajemen Azure atau melalui server API Kubernetes. Node AKS hanya tersedia di jaringan pribadi dan tidak terhubung ke internet publik. Untuk terhubung ke node dan memberikan pemeliharaan dan dukungan, rutekan koneksi Anda melalui host bastion, atau jump box. Verifikasi host ini berada di jaringan virtual manajemen terpisah yang di-peering dengan aman ke jaringan virtual kluster AKS.

Menyambungkan ke node AKS menggunakan host bastion, atau jump box

Anda juga harus mengamankan jaringan manajemen untuk host bastion. Gunakan Azure ExpressRoute atau gateway VPN untuk menyambungkan ke jaringan lokal dan mengontrol akses menggunakan grup keamanan jaringan.

Langkah berikutnya

Artikel ini berfokus pada konektivitas dan keamanan jaringan. Untuk informasi lebih lanjut tentang dasar-dasar jaringan di Kubernetes, lihat Konsep jaringan untuk aplikasi di Azure Kubernetes Service (AKS)