Catatan perev. : Penulis artikel - Reuven Harrison - memiliki lebih dari 20 tahun pengalaman dalam pengembangan perangkat lunak, dan hari ini adalah direktur teknis dan salah satu pendiri Tufin, sebuah perusahaan yang menciptakan solusi manajemen kebijakan keamanan. Mempertimbangkan kebijakan jaringan Kubernetes sebagai alat yang cukup kuat untuk segmentasi jaringan dalam sebuah cluster, ia percaya bahwa mereka tidak begitu mudah untuk diterapkan dalam praktik. Materi ini (agak banyak) dirancang untuk meningkatkan pengetahuan spesialis dalam hal ini dan membantu mereka dalam membuat konfigurasi yang diperlukan. Saat ini, banyak perusahaan semakin memilih Kubernetes untuk menjalankan aplikasi mereka. Ketertarikan pada perangkat lunak ini sangat tinggi sehingga beberapa orang menyebut Kubernetes "sistem operasi pusat data baru." Secara bertahap, Kubernetes (atau k8s) mulai dianggap sebagai bagian penting dari bisnis, yang membutuhkan organisasi proses bisnis yang matang, termasuk keamanan jaringan.
Untuk para profesional keamanan yang bingung karena bekerja dengan Kubernetes, kebijakan default platform ini mungkin merupakan penemuan nyata: biarkan semuanya.
Panduan ini akan membantu Anda memahami struktur internal kebijakan jaringan; Pahami perbedaannya dari aturan untuk firewall biasa. Beberapa jebakan juga akan dijelaskan dan rekomendasi akan diberikan yang akan membantu melindungi aplikasi di Kubernetes.
Kebijakan Jaringan Kubernetes
Mekanisme kebijakan jaringan Kubernetes memungkinkan Anda untuk mengontrol interaksi aplikasi yang digunakan pada platform di tingkat jaringan (yang ketiga dalam model OSI). Kebijakan jaringan tidak memiliki beberapa fitur canggih firewall modern, seperti pemantauan OSI tingkat 7 dan deteksi ancaman, tetapi mereka memberikan tingkat dasar keamanan jaringan, yang merupakan titik awal yang baik.
Kebijakan jaringan mengontrol komunikasi antar pod
Beban kerja Kubernet didistribusikan di seluruh pod yang terdiri dari satu atau lebih kontainer yang digunakan bersama. Kubernetes memberi setiap pod alamat IP yang dapat diakses dari pod lainnya. Kebijakan jaringan Kubernetes menetapkan izin untuk grup pod dengan cara yang sama seperti grup keamanan di cloud digunakan untuk mengontrol akses ke mesin virtual virtual.
Menentukan Kebijakan Jaringan
Seperti sumber daya Kubernet lainnya, kebijakan jaringan diatur dalam YAML. Pada contoh di bawah ini,
balance diberikan akses ke
postgres :
apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: default.postgres namespace: default spec: podSelector: matchLabels: app: postgres ingress: - from: - podSelector: matchLabels: app: balance policyTypes: - Ingress
( Catatan : tangkapan layar ini, seperti semua tangkapan layar serupa berikutnya, tidak dibuat menggunakan alat asli Kubernetes, tetapi menggunakan alat Tufin Orca, yang dikembangkan oleh penulis artikel asli dan disebutkan di akhir artikel.)Menentukan kebijakan jaringan Anda sendiri akan membutuhkan pengetahuan dasar YAML. Bahasa ini didasarkan pada lekukan (ditentukan oleh spasi, bukan tab). Elemen indentasi milik elemen indentasi terdekat di atasnya. Item daftar baru dimulai dengan tanda hubung, semua item lainnya
bernilai kunci .
Setelah mendeskripsikan kebijakan dalam YAML, gunakan
kubectl untuk membuatnya di cluster:
kubectl create -f policy.yaml
Spesifikasi Kebijakan Jaringan
Spesifikasi Kebijakan Jaringan Kubernetes mencakup empat elemen:
podSelector : mendefinisikan pod yang dipengaruhi oleh kebijakan (sasaran) ini - wajib;policyTypes : menunjukkan jenis kebijakan apa yang termasuk dalam ini: masuk dan / atau keluar - opsional, namun, saya sarankan Anda mendaftar secara eksplisit dalam semua kasus;ingress : menentukan lalu lintas masuk yang diizinkan ke pod target - opsional;egress : menentukan lalu lintas keluar yang diizinkan dari pod target - opsional.
Contoh yang dipinjam dari situs web Kubernetes (saya mengganti
role dengan
app ) menunjukkan bagaimana keempat elemen digunakan:
apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: test-network-policy namespace: default spec: podSelector: # <<< matchLabels: app: db policyTypes: # <<< - Ingress - Egress ingress: # <<< - from: - ipBlock: cidr: 172.17.0.0/16 except: - 172.17.1.0/24 - namespaceSelector: matchLabels: project: myproject - podSelector: matchLabels: role: frontend ports: - protocol: TCP port: 6379 egress: # <<< - to: - ipBlock: cidr: 10.0.0.0/24 ports: - protocol: TCP port: 5978
Harap dicatat bahwa keempat elemen bersifat opsional. Hanya
podSelector yang
podSelector , parameter lain dapat digunakan sesuai keinginan.
Jika Anda menghilangkan
policyTypes , kebijakan tersebut akan ditafsirkan sebagai berikut:
- Secara default, diasumsikan bahwa itu mendefinisikan sisi masuknya. Jika kebijakan tidak secara eksplisit menunjukkan hal ini, sistem akan mempertimbangkan bahwa semua lalu lintas dilarang.
- Perilaku di sisi jalan keluar akan ditentukan oleh ada atau tidak adanya parameter jalan keluar yang sesuai.
Untuk menghindari kesalahan, saya sarankan untuk
selalu secara eksplisit menentukan policyTypes .
Sesuai dengan logika di atas, jika
egress ingress dan / atau
egress dihilangkan, kebijakan akan melarang semua lalu lintas (lihat "Aturan pengupasan" di bawah).
Kebijakan default adalah mengizinkan
Jika tidak ada kebijakan yang ditentukan, Kubernetes secara default memungkinkan semua lalu lintas. Semua pod bebas bertukar informasi satu sama lain. Dari sudut pandang keamanan, ini mungkin tampak berlawanan dengan intuisi, tetapi ingat bahwa Kubernet awalnya dibuat oleh pengembang untuk memastikan interoperabilitas aplikasi. Kebijakan jaringan ditambahkan kemudian.
Ruang nama
Ruang nama adalah mekanisme kolaboratif Kubernetes. Mereka dirancang untuk mengisolasi lingkungan logis dari satu sama lain, sementara pertukaran data antar ruang diizinkan secara default.
Seperti kebanyakan komponen Kubernetes, kebijakan jaringan berada di namespace tertentu. Di blok
metadata , Anda bisa menentukan ruang mana kebijakan itu milik:
apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: test-network-policy namespace: my-namespace # <<< spec: ...
Jika namespace tidak ditulis secara eksplisit dalam metadata, sistem akan menggunakan namespace yang ditentukan dalam kubectl (secara default
namespace=default ):
kubectl apply -n my-namespace -f namespace.yaml
Saya merekomendasikan
secara eksplisit menentukan namespace kecuali Anda menulis kebijakan yang ditujukan untuk beberapa namespace sekaligus.
Elemen
podSelector utama dalam suatu kebijakan akan memilih pod dari namespace yang dimiliki kebijakan tersebut (ditolak akses ke pod dari namespace lain).
Demikian pula, podSelector
dalam blok masuk dan keluar dapat memilih pod hanya dari namespace mereka, kecuali, jika Anda menggabungkannya dengan
namespaceSelector (ini akan dibahas di bagian “Memfilter menurut namespace dan pod”) .
Aturan Penamaan Kebijakan
Nama kebijakan unik dalam satu ruang nama. Mungkin tidak ada dua kebijakan dengan nama yang sama dalam satu ruang, tetapi mungkin ada kebijakan dengan nama yang sama di ruang yang berbeda. Ini berguna ketika Anda ingin menerapkan kembali kebijakan yang sama di beberapa ruang.
Saya terutama menyukai satu cara penamaan. Ini terdiri dalam menggabungkan nama namespace dengan pod target. Sebagai contoh:
apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: default.postgres # <<< namespace: default spec: podSelector: matchLabels: app: postgres ingress: - from: - podSelector: matchLabels: app: admin policyTypes: - Ingress
Label
Label khusus dapat dilampirkan ke objek Kubernetes, seperti pod dan ruang nama. Label adalah setara dengan tag di cloud. Kebijakan jaringan Kubernetes menggunakan label untuk memilih
pod yang mereka terapkan:
podSelector: matchLabels: role: db
... atau
ruang nama yang mereka terapkan. Dalam contoh ini, semua pod di ruang nama dengan label yang sesuai dipilih:
namespaceSelector: matchLabels: project: myproject
Satu peringatan: ketika menggunakan
namespaceSelector pastikan namespaceSelector Anda pilih berisi label yang Anda inginkan . Ingatlah bahwa ruang nama
default seperti
default dan
kube-system tidak mengandung label secara default.
Anda dapat menambahkan label ke spasi sebagai berikut:
kubectl label namespace default namespace=default
Dalam kasus ini, namespace di bagian
metadata harus merujuk ke nama sebenarnya dari spasi, dan bukan ke label:
apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: test-network-policy namespace: default # <<< spec: ...
Sumber dan Tujuan
Kebijakan untuk firewall terdiri dari aturan dengan sumber dan tujuan. Kebijakan jaringan Kubernetes didefinisikan untuk tujuan - satu set pod yang menerapkannya, dan kemudian menetapkan aturan untuk lalu lintas masuk (masuk) dan / atau keluar (keluar). Dalam contoh kami, target kebijakan adalah semua pod di namespace
default dengan label dengan kunci
app dan nilai
db :
apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: test-network-policy namespace: default spec: podSelector: matchLabels: app: db # <<< policyTypes: - Ingress - Egress ingress: - from: - ipBlock: cidr: 172.17.0.0/16 except: - 172.17.1.0/24 - namespaceSelector: matchLabels: project: myproject - podSelector: matchLabels: role: frontend ports: - protocol: TCP port: 6379 egress: - to: - ipBlock: cidr: 10.0.0.0/24 ports: - protocol: TCP port: 5978
ingress dalam kebijakan ini membuka lalu lintas masuk ke pod target. Dengan kata lain, masuknya adalah sumber, dan target adalah penerima yang tepat. Demikian pula, jalan keluar adalah target, dan target adalah sumbernya.
Ini sama dengan dua aturan untuk firewall: Ingress → Target; Sasaran → Jalan keluar.Egress dan DNS (penting!)
Ketika membatasi lalu lintas keluar,
perhatikan DNS - Kubernetes menggunakan layanan ini untuk memetakan layanan ke alamat IP. Misalnya, kebijakan berikut tidak akan berfungsi karena Anda tidak mengizinkan aplikasi
balance mengakses DNS:
apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: default.balance namespace: default spec: podSelector: matchLabels: app: balance egress: - to: - podSelector: matchLabels: app: postgres policyTypes: - Egress
Anda dapat memperbaikinya dengan membuka akses ke layanan DNS:
apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: default.balance namespace: default spec: podSelector: matchLabels: app: balance egress: - to: - podSelector: matchLabels: app: postgres - to: # <<< ports: # <<< - protocol: UDP # <<< port: 53 # <<< policyTypes: - Egress
Elemen terakhir ke kosong, dan karena itu secara tidak langsung memilih
semua pod di semua ruang nama , memungkinkan
balance mengirim permintaan DNS ke layanan Kubernetes yang sesuai (biasanya bekerja di ruang
kube-system kubus).
Pendekatan ini berfungsi, tetapi
terlalu permisif dan tidak aman , karena memungkinkan Anda untuk mengarahkan permintaan DNS di luar cluster.
Anda dapat meningkatkannya dalam tiga langkah berturut-turut.
1. Izinkan permintaan DNS hanya
di dalam cluster dengan menambahkan
namespaceSelector :
apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: default.balance namespace: default spec: podSelector: matchLabels: app: balance egress: - to: - podSelector: matchLabels: app: postgres - to: - namespaceSelector: {} # <<< ports: - protocol: UDP port: 53 policyTypes: - Egress
2. Izinkan permintaan DNS hanya di namespace
kube-system .
Untuk melakukan ini, tambahkan label ke
kubectl label namespace kube-system namespace=kube-system kube-system kubectl label namespace kube-system namespace=kube-system :
kubectl label namespace kube-system namespace=kube-system - dan daftarkan dalam kebijakan menggunakan
namespaceSelector :
apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: default.balance namespace: default spec: podSelector: matchLabels: app: balance egress: - to: - podSelector: matchLabels: app: postgres - to: - namespaceSelector: # <<< matchLabels: # <<< namespace: kube-system # <<< ports: - protocol: UDP port: 53 policyTypes: - Egress
3. Paranoid dapat melangkah lebih jauh dan membatasi permintaan DNS ke layanan DNS tertentu di
kube-system . Di bagian "Saring berdasarkan ruang nama & polong", kami akan menjelaskan cara mencapai ini.
Pilihan lain adalah menyelesaikan DNS di tingkat namespace. Dalam hal ini, tidak perlu dibuka untuk setiap layanan:
apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: default.dns namespace: default spec: podSelector: {} # <<< egress: - to: - namespaceSelector: {} ports: - protocol: UDP port: 53 policyTypes: - Egress
podSelector kosong memilih semua pod di namespace.
Pertandingan pertama dan aturan pesanan
Dalam firewall biasa, tindakan ("Izinkan" atau "Tolak") untuk suatu paket ditentukan oleh aturan pertama yang dipenuhi.
Di Kubernetes, urutan kebijakan tidak relevan.Secara default, ketika kebijakan tidak disetel, komunikasi antar pod diperbolehkan dan mereka dapat bertukar informasi secara bebas. Segera setelah Anda mulai merumuskan kebijakan, setiap polong yang dipengaruhi oleh setidaknya satu dari mereka menjadi terisolasi sesuai dengan disjungsi (logis ATAU) dari semua kebijakan yang telah memilihnya. Pod tidak terpengaruh oleh kebijakan apa pun tetap terbuka.
Anda dapat mengubah perilaku ini menggunakan aturan stripping.
Aturan pengupasan (Tolak)
Kebijakan firewall umumnya melarang lalu lintas yang tidak sah secara eksplisit.
Kubernetes tidak memiliki tindakan penolakan , namun, efek yang sama dapat dicapai dengan kebijakan reguler (memungkinkan) dengan memilih grup pod sumber kosong (masuk):
apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: deny-all namespace: default spec: podSelector: {} policyTypes: - Ingress
Kebijakan ini memilih semua pod di namespace dan membiarkan masuknya tidak terdefinisi, memblokir semua lalu lintas masuk.
Demikian pula, Anda dapat membatasi semua lalu lintas keluar dari namespace:
apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: deny-all-egress namespace: default spec: podSelector: {} policyTypes: - Egress
Perhatikan bahwa
kebijakan tambahan apa pun yang memungkinkan lalu lintas ke pod di namespace akan didahulukan dari aturan ini (mirip dengan menambahkan aturan perbolehkan atas aturan penolakan dalam konfigurasi firewall).
Allow All (Any-Any-Any-Allow)
Untuk membuat kebijakan Allow All, Anda harus menambahkan kebijakan larangan di atas dengan elemen
ingress kosong:
apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-all namespace: default spec: podSelector: {} ingress: # <<< - {} # <<< policyTypes: - Ingress
Ini memungkinkan akses dari
semua pod di semua namespace (dan semua IP) ke pod apa saja di namespace default . Perilaku ini diaktifkan secara default, jadi biasanya tidak perlu didefinisikan lebih lanjut. Namun, kadang-kadang mungkin perlu untuk sementara menonaktifkan beberapa izin khusus untuk mendiagnosis masalah.
Aturan dapat dipersempit dan diizinkan akses hanya ke
kumpulan pod tertentu (
app:balance ) di namespace
default :
apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-all-to-balance namespace: default spec: podSelector: matchLabels: app: balance ingress: - {} policyTypes: - Ingress
Kebijakan berikut memungkinkan semua lalu lintas masuk dan keluar, termasuk akses ke IP apa pun di luar cluster:
apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-all spec: podSelector: {} ingress: - {} egress: - {} policyTypes: - Ingress - Egress
Menggabungkan banyak kebijakan
Kebijakan digabungkan menggunakan logika ATAU pada tiga tingkatan; izin setiap pod diatur sesuai dengan disjungsi semua kebijakan yang mempengaruhinya:
1. Di bidang
from dan
to , Anda dapat menentukan tiga jenis elemen (semuanya digabungkan menggunakan OR):
namespaceSelector - memilih seluruh namespace;podSelector - memilih pod;ipBlock - memilih subnet.
Pada saat yang sama, jumlah elemen (bahkan sama) di
from /
to subbagian tidak terbatas. Semuanya akan dikombinasikan dengan logika OR.
apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: default.postgres namespace: default spec: ingress: - from: - podSelector: matchLabels: app: indexer - podSelector: matchLabels: app: admin podSelector: matchLabels: app: postgres policyTypes: - Ingress
2. Di dalam kebijakan, bagian
ingress dapat memiliki banyak elemen (dikombinasikan dengan logika OR). Demikian pula, bagian
egress dapat menyertakan banyak elemen (juga digabungkan dengan klausa):
apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: default.postgres namespace: default spec: ingress: - from: - podSelector: matchLabels: app: indexer - from: - podSelector: matchLabels: app: admin podSelector: matchLabels: app: postgres policyTypes: - Ingress
3. Berbagai kebijakan juga digabungkan dengan logika OR
Tetapi ketika menggabungkan mereka, ada satu batasan yang
ditunjukkan Chris Cooney : Kubernetes hanya dapat menggabungkan kebijakan dengan berbagai
policyTypes kebijakan (
Ingress atau
Egress ). Kebijakan yang menentukan masuknya (atau keluar) akan saling menimpa.
Hubungan antara ruang nama
Secara default, pertukaran informasi antara ruang nama diizinkan. Ini dapat diubah menggunakan kebijakan penghalang yang membatasi lalu lintas keluar dan / atau masuk ke namespace (lihat "Aturan pengupasan" di atas).
Dengan memblokir akses ke namespace (lihat "Aturan Stripping" di atas), Anda dapat membuat pengecualian terhadap kebijakan restriktif dengan mengizinkan koneksi dari namespace tertentu menggunakan
namespaceSelector :
apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: database.postgres namespace: database spec: podSelector: matchLabels: app: postgres ingress: - from: - namespaceSelector: # <<< matchLabels: namespace: default policyTypes: - Ingress
Akibatnya, semua pod di namespace
default akan memiliki akses ke pod
postgres di namespace
database . Tetapi bagaimana jika Anda ingin membuka akses ke
postgres hanya ke pod tertentu di namespace
default ?
Saring berdasarkan ruang nama & pod
Kubernetes versi 1.11 dan lebih tinggi memungkinkan Anda untuk menggabungkan
namespaceSelector dan operator
podSelector menggunakan logis I. Sepertinya ini:
apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: database.postgres namespace: database spec: podSelector: matchLabels: app: postgres ingress: - from: - namespaceSelector: matchLabels: namespace: default podSelector: # <<< matchLabels: app: admin policyTypes: - Ingress
Mengapa ini ditafsirkan sebagai DAN bukannya OR biasa?
Perhatikan bahwa
podSelector tidak dimulai dengan tanda hubung. Dalam YAML, ini berarti
podSelector dan
namespaceSelector berdiri di depannya merujuk ke item daftar yang sama. Oleh karena itu, mereka dikombinasikan oleh I. logis
Menambahkan tanda hubung di depan
podSelector akan menghasilkan item daftar baru yang akan dikombinasikan dengan
namespaceSelector sebelumnya menggunakan OR logis.
Untuk memilih pod dengan label tertentu
di semua ruang nama , masukkan ruang
namespaceSelector kosong:
apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: database.postgres namespace: database spec: podSelector: matchLabels: app: postgres ingress: - from: - namespaceSelector: {} podSelector: matchLabels: app: admin policyTypes: - Ingress
Beberapa label digabungkan dengan AND
Aturan untuk firewall dengan banyak objek (host, jaringan, grup) digabungkan menggunakan OR logis. Aturan berikut akan berfungsi jika sumber paket cocok dengan
Host_1 OR
Host_2 :
| Source | Destination | Service | Action | | ----------------------------------------| | Host_1 | Subnet_A | HTTPS | Allow | | Host_2 | | | | | ----------------------------------------|
Sebaliknya, di Kubernetes, berbagai label di
podSelector atau
namespaceSelector digabungkan oleh logis I. Misalnya, aturan berikut akan memilih pod yang memiliki kedua label,
role=db DAN
version=v2 :
podSelector: matchLabels: role: db version: v2
Logika yang sama berlaku untuk semua jenis operator: pemilih tujuan kebijakan, pemilih pod, dan pemilih namespace.
Subnet dan Alamat IP (IPBlocks)
Firewall menggunakan VLAN, alamat IP, dan subnet untuk mengelompokkan jaringan.
Di Kubernetes, alamat IP ditetapkan untuk pod secara otomatis dan dapat sering berubah, sehingga label digunakan untuk memilih pod dan ruang nama dalam kebijakan jaringan.
ipBlocks (
ipBlocks ) digunakan untuk mengontrol koneksi eksternal (Utara-Selatan) inbound (ingress) atau outbound (egress). Misalnya, kebijakan ini memberikan semua pod dari akses namespace
default ke layanan Google DNS:
apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: egress-dns namespace: default spec: podSelector: {} policyTypes: - Egress egress: - to: - ipBlock: cidr: 8.8.8.8/32 ports: - protocol: UDP port: 53
Pemilih pod kosong dalam contoh ini berarti "pilih semua pod di namespace."
Kebijakan ini hanya menyediakan akses ke 8.8.8.8; akses ke IP lain ditolak. Dengan demikian, pada dasarnya, Anda memblokir akses ke layanan DNS internal Kubernetes. Jika Anda masih ingin membukanya, tentukan secara eksplisit.
Biasanya
ipBlocks dan
podSelectors saling eksklusif, karena alamat IP internal pod tidak digunakan di
ipBlocks .
Dengan menentukan
pod IP internal , Anda sebenarnya akan mengizinkan koneksi ke / dari pod dengan alamat ini. Dalam praktiknya, Anda tidak akan tahu alamat IP mana yang akan digunakan, itulah sebabnya mereka tidak boleh digunakan untuk memilih pod.
Sebagai contoh tandingan, kebijakan berikut mencakup semua IP dan, karenanya, memungkinkan akses ke semua pod lainnya:
apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: egress-any namespace: default spec: podSelector: {} policyTypes: - Egress egress: - to: - ipBlock: cidr: 0.0.0.0/0
Anda dapat membuka akses hanya ke IP eksternal dengan mengecualikan alamat IP internal pod. Misalnya, jika subnet pod Anda adalah 10.16.0.0/14:
apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: egress-any namespace: default spec: podSelector: {} policyTypes: - Egress egress: - to: - ipBlock: cidr: 0.0.0.0/0 except: - 10.16.0.0/14
Port dan Protokol
Biasanya pod mendengarkan pada satu port. Ini berarti bahwa Anda dapat dengan mudah menghilangkan nomor port dalam kebijakan dan membiarkan semuanya sebagai default. Namun, disarankan agar kebijakan dibuat seketat mungkin, sehingga dalam beberapa kasus Anda masih dapat menentukan port:
apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: default.postgres namespace: default spec: ingress: - from: - podSelector: matchLabels: app: indexer - podSelector: matchLabels: app: admin ports: # <<< - port: 443 # <<< protocol: TCP # <<< - port: 80 # <<< protocol: TCP # <<< podSelector: matchLabels: app: postgres policyTypes: - Ingress
Perhatikan bahwa pemilih
ports berlaku untuk semua elemen di blok
to atau
from yang dikandungnya. Untuk menentukan port berbeda untuk set elemen yang berbeda,
ingress atau
egress ke beberapa subbagian dengan
to atau
from dan daftarkan port Anda di masing-masing:
apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: default.postgres namespace: default spec: ingress: - from: - podSelector: matchLabels: app: indexer ports: # <<< - port: 443 # <<< protocol: TCP # <<< - from: - podSelector: matchLabels: app: admin ports: # <<< - port: 80 # <<< protocol: TCP # <<< podSelector: matchLabels: app: postgres policyTypes: - Ingress
Port default berfungsi:
- Jika Anda sepenuhnya menghilangkan definisi port, ini berarti semua protokol dan semua port;
- Jika Anda menghilangkan definisi protokol, itu berarti TCP;
- Jika Anda menghilangkan definisi port, ini berarti semua port.
Praktik terbaik: jangan mengandalkan nilai default, tentukan apa yang Anda butuhkan secara eksplisit.
Harap dicatat bahwa perlu menggunakan porta pod, bukan layanan (lebih lanjut tentang ini pada paragraf berikutnya).
Apakah kebijakan ditentukan untuk pod atau layanan?
Biasanya pod di Kubernet menghubungi satu sama lain melalui layanan - penyeimbang beban virtual yang mengalihkan lalu lintas ke pod yang mengimplementasikan layanan. Anda mungkin berpikir bahwa kebijakan jaringan mengontrol akses ke layanan, tetapi ini tidak benar.
Kebijakan jaringan Kubernetes bekerja dengan port pod, bukan layanan., 80- , 8080 pod', 8080.
: ( pod') .
Service Mesh
(, . Istio — . .) .
Ingress, Egress?
— , pod pod' , ( egress-), pod ( , , ingress-).
, .
pod-
egress -, . pod'-
. pod - , (egress) .
pod'-
,
ingress -, . pod'-. pod - , (ingress) .
. «Stateful Stateless» .
Kubernetes . , , .
Kubernetes (DNS) egress. , IP- ( aws.com).
. Kubernetes . kubectl Kubernetes , , . Kubernetes . :
kubernetes get networkpolicy <policy-name> -o yaml
, Kubernetes .
Kubernetes , API-, , Container Networking Interface (CNI). Kubernetes CNI . CNI , Kubernetes,
( — . .) , , CNI .
, Kubernetes , CNI.
Stateful Stateless?
CNI Kubernetes, , (, Calico Linux conntrack). pod' TCP- . Kubernetes, (statefulness).
Kubernetes:
- Service Mesh sidecar- . Istio .
- CNI , Kubernetes.
- Tufin Orca Kubernetes.
Tufin Orca Kubernetes ( , ).
Kesimpulan
Kubernetes , . , - . .
, , .
PS dari penerjemah
Baca juga di blog kami: