Praktik terbaik untuk kebijakan jaringan di Azure Kubernetes Service (AKS)

Kubernetes, secara default, beroperasi sebagai jaringan datar di mana semua pod dapat berkomunikasi secara bebas satu sama lain. Konektivitas yang tidak terbatas ini dapat nyaman bagi pengembang tetapi menimbulkan risiko keamanan yang signifikan saat aplikasi diskalakan. Bayangkan organisasi menyebarkan beberapa layanan mikro, setiap menangani data sensitif, transaksi pelanggan, atau operasi backend. Tanpa batasan apa pun, pod yang disusupi berpotensi mengakses data yang tidak sah atau mengganggu layanan.

Untuk mengatasi masalah keamanan ini, Kebijakan Jaringan di Kubernetes memungkinkan administrator untuk mengontrol dan membatasi lalu lintas antar beban kerja. Mereka menyediakan cara deklaratif untuk menerapkan aturan lalu lintas, memastikan perilaku jaringan yang aman dan terkontrol dalam kluster.

Apa itu Kebijakan Jaringan Kubernetes?

Kebijakan Jaringan di Kubernetes adalah sekumpulan aturan yang mengontrol bagaimana pod berkomunikasi satu sama lain dan dengan layanan eksternal. Ini memberikan kontrol terperinci atas lalu lintas jaringan, memungkinkan administrator untuk memberlakukan keamanan dan segmentasi di tingkat namespace. Dengan menerapkan Kebijakan Jaringan, Anda mendapatkan:

• Postur keamanan yang lebih kuat: Mencegah pergerakan lateral yang tidak sah dalam kluster.
• Kepatuhan dan tata kelola: Terapkan persyaratan peraturan dengan mengontrol jalur komunikasi.
• Mengurangi radius ledakan: Batasi dampak beban kerja yang disusupi dengan membatasi akses jaringannya.

Awalnya, Kebijakan Jaringan dirancang agar berfungsi pada Layer 3 (IP) dan Layer 4 (TCP/UDP) dari model OSI, memungkinkan kontrol dasar terhadap komunikasi antar pod dan komunikasi dengan eksternal. Namun, mesin kebijakan jaringan canggih seperti Cilium telah memperluas Kebijakan Jaringan ke Lapisan 7 (Lapisan Aplikasi), memungkinkan kontrol yang lebih dalam atas lalu lintas aplikasi untuk aplikasi cloud-native modern.

Kebijakan Jaringan ditentukan pada tingkat namespace, yang berarti setiap kebijakan berlaku untuk beban kerja dalam namespace tertentu. Komponen utama Kebijakan Jaringan meliputi:

• Selektor pod: Menentukan pod mana yang diterapkan kebijakan berdasarkan label.
• Aturan Ingress: Tentukan koneksi masuk yang diizinkan.
• Aturan keluar: Tentukan koneksi keluar yang diizinkan.
• Jenis kebijakan: Tentukan apakah kebijakan berlaku untuk masuk (masuk), keluar (keluar), atau keduanya.

Fondasi membangun kebijakan jaringan yang efektif

Membangun kebijakan jaringan yang efektif di Kubernetes bukan hanya tentang menulis konfigurasi YAML—kebijakan ini memerlukan pemahaman mendalam tentang arsitektur aplikasi, pola lalu lintas, dan persyaratan keamanan Anda. Tanpa gambaran yang jelas tentang bagaimana beban kerja berkomunikasi, menegakkan kebijakan keamanan dapat menyebabkan gangguan atau kesenjangan perlindungan yang tidak diinginkan. Bagian berikut mencakup cara mendekati desain kebijakan jaringan secara sistematis.

Memahami konektivitas beban kerja Anda

Sebelum menerapkan kebijakan jaringan, Anda memerlukan visibilitas tentang bagaimana beban kerja berkomunikasi satu sama lain dan layanan eksternal. Langkah ini memastikan bahwa kebijakan tidak secara tidak sengaja memblokir lalu lintas penting sambil secara efektif membatasi paparan yang tidak perlu.

• Manfaatkan Alat Visibilitas: selain persyaratan jaringan yang disediakan oleh tim aplikasi, Anda dapat menggunakan alat seperti Cilium Hubble, dan Retina membantu Anda menganalisis lalu lintas pod-ke-pod, mengidentifikasi layanan mana yang perlu berkomunikasi dan menentukan dependensi masuk dan keluar mereka. Misalnya, frontend mungkin perlu menjangkau API backend, tetapi seharusnya tidak berbicara langsung ke database. Identifikasi layanan mana yang perlu berkomunikasi dan menentukan dependensi masuk dan keluar mereka. Misalnya, frontend mungkin perlu menjangkau API backend, tetapi seharusnya tidak berbicara langsung ke database.

• Pentingnya label dalam kebijakan jaringan: Secara tradisional, kebijakan keamanan jaringan telah mengandalkan alamat IP statis untuk menentukan aturan lalu lintas. Pendekatan ini bermasalah di Kubernetes karena pod bersifat sementara—dibuat dan sering dihancurkan, sering kali dengan alamat IP yang ditetapkan secara dinamis. Mempertahankan aturan keamanan berdasarkan IP yang terus berubah akan memerlukan pembaruan berkelanjutan, membuat manajemen kebijakan tidak efisien dan rawan kesalahan.

Label menyelesaikan tantangan ini dengan menyediakan cara yang stabil untuk mengelompokkan beban kerja. Daripada mengandalkan IP tetap, Kebijakan Jaringan Kubernetes menggunakan label untuk menentukan aturan keamanan yang tetap konsisten bahkan saat pod melakukan restart atau berpindah antar simpul. Misalnya, kebijakan dapat memungkinkan komunikasi antara pod berlabel app: frontend dan app: backend, memastikan arus lalu lintas sebagaimana dimaksud terlepas dari perubahan IP Pod. Pendekatan berbasis label ini sangat penting untuk mencapai keamanan jaringan yang dapat diskalakan dan digerakkan niat di lingkungan cloud-native.

Strategi pelabelan yang terdefinisi dengan baik menyederhanakan manajemen kebijakan, mengurangi kesalahan konfigurasi, dan meningkatkan penegakan keamanan di seluruh kluster.

• Tentukan Segmentasi mikro: Mengatur beban kerja ke zona keamanan (misalnya, frontend, backend, database) membantu menegakkan prinsip hak istimewa paling sedikit. Misalnya, layanan mikro yang menangani transaksi pelanggan harus diisolasi dari aplikasi tujuan umum.

Pendekatan keamanan berlapis untuk Kubernetes

Hanya mengandalkan Kebijakan Jaringan Kubernetes dasar mungkin tidak cukup untuk semua kebutuhan keamanan. Pendekatan berlapis memastikan perlindungan komprehensif di berbagai tingkat komunikasi jaringan.

• (L3/L4) kebijakan: Fondasi keamanan jaringan, mengontrol lalu lintas berdasarkan label pod dan namespace di tingkat IP, port, dan protokol.
• Kebijakan berbasis FQDN: Membatasi lalu lintas keluar ke domain eksternal tertentu, memastikan beban kerja hanya dapat menjangkau layanan eksternal yang disetujui (misalnya: hanya mengizinkan akses ke microsoft.com untuk panggilan API).
• Kebijakan Lapisan 7: Memperkenalkan kontrol halus atas lalu lintas dengan memfilter permintaan berdasarkan metode HTTP, header, dan jalur. Ini berguna untuk mengamankan API dan memberlakukan kebijakan keamanan lapisan aplikasi.

Manajemen Kebijakan Jaringan

Siapa yang harus mengelola kebijakan jaringan? Ini sering tergantung pada persyaratan struktur dan keamanan organisasi. Pendekatan yang seimbang memungkinkan tim keamanan dan pengembang aplikasi untuk berkolaborasi secara efektif.

• Administrasi keamanan terpusat: Tim keamanan atau jaringan harus menentukan kebijakan dasar untuk memberlakukan persyaratan keamanan global, seperti aturan tolak-semua default atau pembatasan berbasis kepatuhan.
• Otonomi pengembang dengan pagar pembatas: Tim aplikasi harus dapat menentukan kebijakan jaringan khusus layanan dalam namespace layanan mereka, memungkinkan keamanan sambil menjaga kelincahan.
• Manajemen siklus hidup kebijakan: Meninjau dan memperbarui kebijakan secara teratur memastikan bahwa keamanan tetap selaras dengan arsitektur aplikasi yang berkembang. Alat pengamatan dapat membantu mendeteksi kesalahan konfigurasi kebijakan dan aturan yang hilang.

Contoh: Mengamankan aplikasi web multi-tingkat dengan Kebijakan Jaringan

Langkah 1: Memahami konektivitas beban kerja

• Alat visibilitas: Gunakan Cilium Hubble untuk mengamati cara pod berkomunikasi.

• Pemetaan konektivitas:

  Sumber	Tujuan	Protokol	Pelabuhan
  Frontend	Bagian Belakang	TCP	8080
  Bagian Belakang	Database	TCP	5432
  Bagian Belakang	Gateway Pembayaran Eksternal	TCP	443

Langkah 2: Menerapkan label untuk penegakan kebijakan

Dengan melabeli beban kerja dengan benar, kebijakan dapat tetap stabil meskipun IP Pod berubah.

• app: frontend untuk pod UI.
• app: backend untuk pod API.
• app: database untuk pod DB.

Langkah 3: Menerapkan Kebijakan Jaringan tingkat aplikasi

Dalam contoh ini, kami menggunakan dua lapisan kebijakan jaringan: kebijakan dasar L3/L4 untuk mengontrol lalu lintas antara layanan mikro dan kebijakan nama domain yang sepenuhnya memenuhi syarat (FQDN) untuk mengontrol lalu lintas keluar dengan gateway pembayaran eksternal.

Izinkan frontend untuk berkomunikasi dengan backend	Izinkan backend untuk mengakses database	Izinkan backend untuk mencapai API pembayaran eksternal
Kebijakan 1: Keluar frontend to: - podSelector: matchLabels: app: backend ports: - protocol: TCP port: 8080 Kebijakan 2: backend akses masuk from: - podSelector: matchLabels: app: frontend ports: - protocol: TCP port: 8080	Kebijakan 1: Keluar backend to: - podSelector: matchLabels: app: database ports: - protocol: TCP port: 5432 Kebijakan 2: Masuknya database from: - podSelector: matchLabels: app: backend ports: - protocol: TCP port: 5432	Kebijakan 1: Backend spec: endpointSelector: matchLabels: app: backend egress: - toFQDNs: - matchName: payments.example.com ports: - protocol: TCP port: 443

Langkah 4: Mengelola dan memelihara kebijakan

• Tim keamanan dan platform memberlakukan aturan dasar penolakan.

  Kebijakan garis besar	Kebijakan platform	Keamanan
  - Pengaturan default menolak semua lalu lintas	- Izinkan DNS - Izinkan Catatan	- Memblokir lalu lintas untuk diketahui IP berbahaya dan domain

• Memastikan bahwa kebijakan jaringan aplikasi mematuhi persyaratan platform dan keamanan sambil menghindari pelanggaran kebijakan apa pun.

  Garis Dasar	Kebijakan platform	Kebijakan keamanan	Izinkan frontend untuk berkomunikasi dengan backend	Izinkan backend untuk mengakses database	Izinkan backend untuk mencapai API pembayaran eksternal
  - Pengaturan default menolak semua lalu lintas	- Izinkan DNS - Izinkan Log	- Memblokir lalu lintas ke IP dan domain berbahaya yang diketahui	Kebijakan 1: Eksi antarmuka depan: - ke:    - podSelector:      matchLabels:       app: backend     Port:      - protokol: TCP       port: 8080 Kebijakan 2: Masuk backend: -dari:    - podSelector:      matchLabels:       aplikasi: frontend     Port:      - protokol: TCP       port: 8080	Kebijakan 1: Keluar backend: - ke:    - podSelector:      matchLabels:       aplikasi: database     Port:      - protokol: TCP       port: 5432 Kebijakan 2: Masuknya database: -dari:    - podSelector:      matchLabels:       app: penggunaan belakang     Port:      - protokol: TCP       port: 5432	Kebijakan 1: Backend Spec: endpointSelector:    matchLabels:     aplikasi: bagian belakang jalan keluar: - keFQDNs:    - matchName: payments.example.com Port: - protokol: TCP   port: 443

  Pendekatan terstruktur ini memastikan keamanan tanpa mengganggu fungsionalitas aplikasi.

Azure Powered by Cilium

Azure Container Network Interface (CNI) yang didukung oleh Cilium memanfaatkan eBPF (Filter Paket Berkeley yang diperluas) untuk menyediakan jaringan, observabilitas, dan keamanan berkinerja tinggi untuk beban kerja Kubernetes. Tidak seperti CNI tradisional yang mengandalkan pemfilteran paket berbasis iptables, Azure CNI yang didukung oleh Cilium menggunakan eBPF untuk beroperasi pada tingkat kernel, memungkinkan penegakan kebijakan jaringan yang efisien dan dapat diskalakan. Pada Azure Kubernetes Service (AKS), Cilium adalah satu-satunya mesin kebijakan jaringan yang didukung, yang mencerminkan investasi Azure dalam performa, skalabilitas, dan keamanan. Azure Kubernetes Service mengintegrasikan Cilium sebagai komponen terkelola, menyederhanakan penegakan keamanan jaringan. Administrator dapat menentukan Kebijakan Jaringan Cilium langsung dalam kluster AKS mereka tanpa memerlukan pengontrol eksternal.

Cilium memperluas penggunaan label dengan fitur Identitas. Kluster besar dengan banyak pod mungkin mengalami masalah skala di mana pembaruan filter IP terus-menerus terjadi dengan tingkat perubahan pod yang tinggi. Di balik layar, Identitas memetakan ke label dan memungkinkan koneksi dimulai segera setelah identitas terpecahkan, tanpa perlu memperbarui aturan pada node.

Dengan Azure CNI yang didukung oleh Cilium, Anda tidak perlu menginstal mesin kebijakan jaringan terpisah seperti Azure Network Policy Manager atau Calico.

Gunakan perintah berikut untuk membuat kluster dengan Azure CNI yang didukung oleh cilium

az aks create \
  --name <clusterName> \
  --resource-group <resourceGroupName> \
  --location <location> \
  --network-plugin azure \
  --network-plugin-mode overlay \
  --pod-cidr 192.168.0.0/16 \
  --network-dataplane cilium \
  --generate-ssh-keys

Anatomi Kebijakan Jaringan Cilium

Dengan Azure CNI yang didukung oleh Cilium, Anda dapat mengonfigurasi kebijakan jaringan secara asli di Kubernetes menggunakan dua format yang tersedia:

• Sumber daya standarNetworkPolicy, yang mendukung kebijakan L3 dan L4 saat masuk atau keluar dari Pod.
• Format yang diperluasCiliumNetworkPolicy, yang tersedia sebagai CustomResourceDefinition yang mendukung spesifikasi kebijakan pada Layer 3-7 baik untuk ingress maupun egress.

Dengan CRD ini, kita dapat menentukan kebijakan keamanan, dan Kubernetes secara otomatis mendistribusikan kebijakan ini ke semua node dalam kluster.

Kebijakan Jaringan terdiri dari beberapa komponen utama:

• Pemilih pod: Menentukan pod mana yang akan diterapkan kebijakan dengan menggunakan label.

• Jenis kebijakan: Menentukan apakah kebijakan berlaku untuk masuk (lalu lintas masuk), keluar (lalu lintas keluar), atau keduanya.

• Aturan Ingress: Menentukan sumber yang diizinkan (pod, namespace, atau rentang IP) dan port.

• Aturan keluar: Menentukan tujuan dan port yang diizinkan.

  apiVersion: networking.k8s.io/v1
  kind: NetworkPolicy
  metadata:
    name: frontend-egress
    namespace: default
  spec:
    podSelector:
      matchLabels:
        app: frontend
    policyTypes:
      - Egress
    egress:
      - to:
          - podSelector:
              matchLabels:
                app: backend
        ports:
          - protocol: TCP
            port: 8080
  

Kebijakan Jaringan Tingkat Lanjut

Layanan Azure Kubernetes menawarkan Advanced Container Networking Service (ACNS) serangkaian layanan yang dirancang untuk meningkatkan kemampuan jaringan kluster AKS.

Fitur utama ACNS adalah Container Network Security, yang menawarkan fungsionalitas keamanan tingkat lanjut untuk melindungi beban kerja kontainer. Salah satu aspek penting adalah kemampuan untuk menerapkan kebijakan jaringan tingkat lanjut, termasuk pemfilteran Nama Domain yang Sepenuhnya Memenuhi Syarat (FQDN) dan kebijakan Lapisan 7 (L7), memungkinkan kontrol yang lebih terperinci atas lalu lintas keluar dan komunikasi lapisan aplikasi.

Mengamankan lalu lintas keluar dengan Pemfilteran FQDN

Secara tradisional, kebijakan jaringan di Kubernetes didasarkan pada alamat IP. Namun, di lingkungan dinamis di mana IP Pod sering berubah, mengelola kebijakan tersebut menjadi rumit. Pemfilteran FQDN menyederhanakan ini dengan memungkinkan kebijakan ditentukan menggunakan nama domain alih-alih alamat IP. Pendekatan ini memberikan metode yang lebih intuitif dan mudah digunakan untuk mengontrol lalu lintas jaringan, memungkinkan organisasi untuk menegakkan kebijakan keamanan dengan presisi dan fleksibilitas yang lebih besar.

Menerapkan pemfilteran FQDN di kluster AKS memerlukan pengaktifan ACNS dan mengonfigurasi kebijakan yang diperlukan untuk menentukan domain yang diizinkan atau diblokir, sehingga meningkatkan postur keamanan aplikasi kontainer Anda.

Untuk mengaktifkan Advanced Container Networking Services (ACNS) di Azure Kubernetes Service (AKS), gunakan bendera --enable-acns

Contoh: Aktifkan Layanan Jaringan Kontainer Tingkat Lanjut pada kluster yang ada

az aks update \
  --resource-group $RESOURCE_GROUP \
  --name $CLUSTER_NAME \
  --enable-acns

Contoh: Merancang kebijakan jaringan yang memungkinkan lalu lintas ke "bing.com"

apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:
  name: "allow-bing-fqdn"
spec:
  endpointSelector:
    matchLabels:
      app: demo-container
  egress:
    - toEndpoints:
        - matchLabels:
            "k8s:io.kubernetes.pod.namespace": kube-system
            "k8s:k8s-app": kube-dns
      toPorts:
        - ports:
            - port: "53"
              protocol: ANY
          rules:
            dns:
              - matchPattern: "*.bing.com"
    - toFQDNs:
        - matchPattern: "*.bing.com"

Perlindungan dan keamanan untuk API dengan kebijakan L7

Karena aplikasi modern semakin mengandalkan API untuk komunikasi, mengamankan interaksi ini di lapisan jaringan saja tidak lagi cukup. Kebijakan jaringan standar beroperasi pada Layer 3 (IP) dan Layer 4 (TCP/UDP), mengontrol pod mana yang dapat berkomunikasi, tetapi tidak memiliki visibilitas ke dalam permintaan API aktual yang dibuat.

Kebijakan Lapisan 7 (L7) memberikan manfaat dan fitur berikut:

• Keamanan API granular: Terapkan kebijakan berdasarkan data permintaan HTTP, gRPC, atau Kafka, bukan hanya alamat IP dan port.
• Mengurangi permukaan serangan: Mencegah akses yang tidak sah dan mengurangi serangan berbasis API dengan memfilter lalu lintas di lapisan aplikasi.
• Kepatuhan dan audit: Pastikan kepatuhan terhadap standar keamanan dengan mencatat dan mengontrol interaksi API tertentu.
• Manajemen kebijakan yang disederhanakan: Hindari beban operasional dari proksi sidecar tambahan dengan memanfaatkan kontrol L7 bawaan yang didukung oleh Cilium.

Kebijakan L7 AKS diaktifkan melalui ACNS dan tersedia untuk pelanggan yang menggunakan Azure CNI yang didukung oleh Cilium. Kebijakan ini mendukung protokol HTTP, gRPC, dan Kafka.

Untuk menerapkan kebijakan L7, pelanggan menentukan CiliumNetworkPolicy sumber daya, menentukan aturan untuk kontrol lalu lintas lapisan aplikasi.

Contoh: Mengaktifkan ACNS pada kluster yang ada

az aks update \
  --resource-group $RESOURCE_GROUP \
  --name $CLUSTER_NAME \
  --enable-acns

Contoh: Izinkan hanya permintaan GET ke /api dari pod frontend ke layanan backend pada port 8080

apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:
  name: frontend-l7-policy
  namespace: default
spec:
  endpointSelector:
    matchLabels:
      app: frontend
  egress:
    - toEndpoints:
        - matchLabels:
            app: backend
      toPorts:
        - ports:
            - port: "8080"
              protocol: TCP
          rules:
            http:
              - method: "GET"
                path: "/api"

Strategi untuk kebijakan jaringan

Mengamankan beban kerja Kubernetes memerlukan pendekatan yang bijaksana untuk menentukan dan menegakkan kebijakan jaringan. Strategi yang dirancang dengan baik memastikan bahwa aplikasi hanya berkomunikasi seperti yang dimaksudkan, mengurangi risiko akses yang tidak sah, gerakan lateral, dan potensi pelanggaran. Bagian berikut mencakup strategi kunci untuk menerapkan Kebijakan Jaringan Kubernetes yang efektif.

Mengadopsi model Zero-Trust

Secara default, Kubernetes memungkinkan komunikasi yang tidak terbatas antara semua pod dalam kluster. Pendekatan Zero-Trust menentukan bahwa tidak ada lalu lintas yang harus dipercaya secara default, dan hanya jalur komunikasi yang diizinkan secara eksplisit yang harus diizinkan. Menerapkan kebijakan jaringan yang menolak semua secara default memastikan bahwa hanya lalu lintas data yang diperlukan yang mengalir antar beban kerja.

Contoh kebijakan tolak-semua:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny
  namespace: default
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress

Pemisahan namespace dan multi-penyewa

Di lingkungan multi-penyewa, namespace memungkinkan pengisolasian beban kerja. Tim yang berbeda biasanya mengelola aplikasi mereka dalam namespace khusus, memastikan isolasi logis antar beban kerja. Pemisahan ini sangat penting ketika beberapa aplikasi berjalan bersama satu sama lain. Menerapkan kebijakan jaringan pada cakupan namespace sering kali merupakan langkah pertama dalam mengamankan beban kerja, karena mencegah pergerakan lateral yang tidak dibatasi antara aplikasi yang dikelola oleh tim yang berbeda.

Misalnya, batasi semua lalu lintas masuk ke sebuah namespace, hanya mengizinkan lalu lintas dari namespace yang sama.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: restrict-cross-namespace
  namespace: team-a
spec:
  podSelector: {}
  policyTypes:
    - Ingress
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              name: team-a

Mikrosegmentasi untuk isolasi beban kerja

Meskipun segmentasi berbasis namespace adalah langkah pertama yang penting dalam mengamankan kluster Kubernetes multi-tenant, mikrosegmentasi tingkat aplikasi memberikan kontrol yang sangat terperinci atas bagaimana beban kerja berinteraksi di dalam namespace. Isolasi namespace layanan saja tidak mencegah komunikasi yang tidak diinginkan atau tidak sah antara aplikasi yang berbeda dalam namespace yang sama. Di sinilah segmentasi tingkat pod menjadi penting.

Misalnya, jika layanan frontend hanya boleh berbicara dengan layanan backend dalam namespace layanan yang sama, kebijakan yang menggunakan label pod dapat memberlakukan pembatasan ini:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: frontend-to-backend
  namespace: team-a
spec:
  podSelector:
    matchLabels:
      app: frontend
  policyTypes:
    - Egress
  egress:
    - to:
        - podSelector:
            matchLabels:
              app: backend
      ports:
        - protocol: TCP
          port: 8080

Hal ini mencegah pod frontend membuat koneksi yang tidak diinginkan ke layanan lain, mengurangi risiko akses yang tidak sah atau pergerakan lateral di dalam namespace layanan.

Dengan menggabungkan isolasi di seluruh namespace dengan kebijakan tingkat aplikasi yang halus, tim dapat menerapkan model keamanan berlapis yang mencegah lalu lintas yang tidak sah sambil memungkinkan komunikasi yang diperlukan untuk fungsionalitas aplikasi.

Pendekatan keamanan berlapis

Keamanan jaringan harus diimplementasikan secara berlapis, menggabungkan beberapa tingkat penerapan:

• Kebijakan L3/L4: Membatasi lalu lintas di tingkat IP dan port (misalnya: mengizinkan lalu lintas TCP pada port 443).
• Pemfilteran berbasis FQDN: Membatasi komunikasi eksternal berdasarkan nama domain daripada alamat IP.
• Kebijakan L7: Mengontrol komunikasi berdasarkan atribut lapisan aplikasi (misalnya: hanya mengizinkan permintaan HTTP GET ke jalur API tertentu).

Misalnya, kebijakan Cilium L7 dapat membatasi layanan frontend untuk hanya mengeluarkan permintaan GET ke API backend:

apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:
  name: frontend-l7-policy
  namespace: default
spec:
  endpointSelector:
    matchLabels:
      app: frontend
  egress:
    - toEndpoints:
        - matchLabels:
            app: backend
      toPorts:
        - ports:
            - port: "8080"
              protocol: TCP
          rules:
            http:
              - method: "GET"
                path: "/api"

Ini mencegah frontend membuat permintaan POST atau DELETE, membatasi permukaan serangan.

Mengintegrasikan RBAC dengan manajemen Kebijakan Jaringan

Kontrol akses berbasis peran (RBAC) memainkan peran penting dalam memastikan bahwa hanya pengguna atau tim yang berwenang yang dapat membuat, memodifikasi, atau menghapus kebijakan jaringan. Tanpa kontrol akses yang tepat, kebijakan yang salah dikonfigurasi dapat mengekspos beban kerja ke akses yang tidak sah atau secara tidak sengaja memblokir lalu lintas aplikasi penting.

Dengan memanfaatkan RBAC Kubernetes bersama dengan kebijakan jaringan, organisasi dapat memberlakukan pemisahan tugas antara administrator platform, tim keamanan, dan pengembang aplikasi. Pendekatan umumnya adalah:

• Platform atau tim keamanan menentukan kebijakan keamanan dasar yang memberlakukan kepatuhan dan membatasi akses eksternal.
• Tim aplikasi diberikan izin terbatas untuk membuat atau memperbarui kebijakan jaringan hanya untuk namespace layanan masing-masing.

Misalnya, kebijakan RBAC berikut memungkinkan pengembang untuk membuat dan memodifikasi kebijakan jaringan tetapi hanya dalam namespace layanan yang ditetapkan:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: network-policy-editor
  namespace: team-a
rules:
  - apiGroups: ["networking.k8s.io"]
    resources: ["networkpolicies"]
    verbs: ["get", "list", "create", "update", "delete"]

Peran ini kemudian dapat terikat ke tim tertentu menggunakan RoleBinding:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: team-a-network-policy-binding
  namespace: team-a
subjects:
  - kind: User
    name: developer@example.com
    apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: network-policy-editor
  apiGroup: rbac.authorization.k8s.io

Dengan membatasi modifikasi kebijakan jaringan kepada tim dan namespace yang ditunjuk, organisasi dapat mencegah kesalahan konfigurasi yang tidak disengaja atau perubahan yang tidak sah sambil tetap memungkinkan fleksibilitas bagi pengembang untuk menerapkan kebijakan keamanan khusus aplikasi.

Pendekatan ini memperkuat prinsip hak istimewa paling sedikit sambil memastikan bahwa strategi segmentasi jaringan tetap konsisten, aman, dan selaras dengan kebijakan organisasi.

Solusi sistem lama dan pihak ketiga

Azure Network Policy Manager (NPM)

Azure Network Policy Manager (NPM) adalah solusi warisan untuk memberlakukan kebijakan jaringan Kubernetes pada AKS. Saat kami terus mengembangkan susunan perangkat jaringan kami, kami berniat untuk segera menghentikan penggunaan NPM.

Kami sangat merekomendasikan semua pelanggan beralih ke Kebijakan Jaringan Cilium, yang memberikan performa, skalabilitas, dan keamanan yang lebih baik melalui penegakan berbasis eBPF. Cilium adalah masa depan kebijakan jaringan di AKS dan menawarkan alternatif yang lebih fleksibel dan kaya fitur untuk NPM.

Dukungan NetworkPolicy untuk simpul Windows

AKS tidak mendukung Kubernetes NetworkPolicy untuk node Windows secara langsung. Untuk mengaktifkan kebijakan jaringan untuk beban kerja Windows, Anda dapat menggunakan Calico untuk simpul Windows, yang diintegrasikan ke dalam AKS untuk menyederhanakan penyebaran. Anda dapat mengaktifkannya menggunakan --network-policy calico bendera saat membuat kluster.

Microsoft tidak mempertahankan gambar Calico yang digunakan dalam integrasi ini. Dukungan kami terbatas untuk memastikan Calico terintegrasi dengan benar dengan AKS dan fungsi seperti yang diharapkan dalam platform. Setiap masalah yang terkait dengan bug hulu Calico, permintaan fitur, atau pemecahan masalah di luar integrasi AKS harus diarahkan ke komunitas sumber terbuka Calico atau Tigera, pengelola Calico.

Calico open source – Solusi pihak ketiga

Calico open source adalah solusi pihak ketiga yang banyak digunakan untuk memberlakukan kebijakan jaringan Kubernetes. Ini mendukung simpul Linux dan Windows dan menyediakan kemampuan jaringan dan keamanan tingkat lanjut, termasuk penegakan kebijakan jaringan, identitas beban kerja, dan enkripsi.

Meskipun Calico terintegrasi dengan AKS untuk kebijakan jaringan Windows (--network-policy calico), Calico tetap menjadi proyek sumber terbuka yang dikelola oleh Tigera. Microsoft tidak mempertahankan gambar Calico dan memberikan dukungan terbatas yang berfokus pada memastikan integrasi yang tepat dengan AKS. Untuk pemecahan masalah tingkat lanjut, permintaan fitur, atau masalah di luar integrasi AKS, sebaiknya hubungi komunitas sumber terbuka Calico atau Tigera.

Untuk simpul Linux, kami sangat menyarankan untuk menggunakan Cilium untuk penegakan kebijakan jaringan. Untuk simpul Windows, sebaiknya gunakan Calico.

Kesimpulan

Kebijakan jaringan adalah bagian mendasar dari keamanan Kubernetes, memungkinkan organisasi mengontrol arus lalu lintas, menerapkan isolasi beban kerja, dan mengurangi permukaan serangan. Seiring berkembangnya lingkungan cloud-native, hanya mengandalkan kebijakan Lapisan 3/4 dasar tidak lagi cukup. Solusi tingkat lanjut, seperti pemfilteran Lapisan 7 dan kebijakan berbasis FQDN, memberikan keamanan dan fleksibilitas terperinci yang diperlukan untuk melindungi aplikasi modern.

Dengan mengikuti praktik terbaik termasuk model zero-trust, microsegmentation, dan mengadopsi solusi yang dapat diskalakan seperti tim Cilium terkelola Azure dapat meningkatkan keamanan sambil menjaga efisiensi operasional. Karena jaringan Kubernetes terus berkembang, mengadopsi pendekatan modern yang digerakkan oleh pengamatan akan menjadi kunci untuk mengamankan beban kerja secara efektif.