Pambuka kanggo Kabijakan Jaringan Kubernetes kanggo Profesional Keamanan

Cathetan. nerjemahake.: Penulis artikel kasebut, Reuven Harrison, duwe pengalaman luwih saka 20 taun ing pangembangan piranti lunak, lan saiki dadi CTO lan co-founder Tufin, perusahaan sing nggawe solusi manajemen kebijakan keamanan. Nalika dheweke ndeleng kabijakan jaringan Kubernetes minangka alat sing cukup kuat kanggo segmentasi jaringan ing kluster, dheweke uga percaya yen ora gampang dileksanakake ing praktik. Materi iki (cukup akeh) dimaksudake kanggo nambah kesadaran spesialis babagan masalah iki lan mbantu nggawe konfigurasi sing dibutuhake.

Saiki, akeh perusahaan sing tambah akeh milih Kubernetes kanggo mbukak aplikasi. Kapentingan ing piranti lunak iki dhuwur banget nganti sawetara sing nyebut Kubernetes "sistem operasi anyar kanggo pusat data." Mboko sithik, Kubernetes (utawa k8s) wiwit dianggep minangka bagean kritis bisnis, sing mbutuhake organisasi proses bisnis sing diwasa, kalebu keamanan jaringan.

Kanggo profesional keamanan sing bingung nggarap Kubernetes, wahyu nyata bisa dadi kabijakan standar platform: ngidini kabeh.

Pandhuan iki bakal mbantu sampeyan ngerti struktur internal kabijakan jaringan; ngerti carane padha beda-beda saka aturan kanggo firewalls biasa. Iki uga bakal nutupi sawetara pitfalls lan menehi rekomendasi kanggo mbantu ngamanake aplikasi ing Kubernetes.

Kawicaksanan jaringan Kubernetes

Mekanisme kabijakan jaringan Kubernetes ngidini sampeyan ngatur interaksi aplikasi sing dipasang ing platform ing lapisan jaringan (sing katelu ing model OSI). Kawicaksanan jaringan kurang sawetara fitur canggih saka firewall modern, kayata penegakan OSI Layer 7 lan deteksi ancaman, nanging nyedhiyakake tingkat keamanan jaringan dhasar sing minangka titik wiwitan sing apik.

Kawicaksanan jaringan ngontrol komunikasi antarane pods

Beban kerja ing Kubernetes disebarake ing polong, sing kalebu siji utawa luwih wadhah sing dipasang bebarengan. Kubernetes menehi alamat IP saben pod sing bisa diakses saka pod liyane. Kawicaksanan jaringan Kubernetes nyetel hak akses kanggo klompok pods kanthi cara sing padha karo grup keamanan ing awan digunakake kanggo ngontrol akses menyang mesin virtual.

Nemtokake Kabijakan Jaringan

Kaya sumber daya Kubernetes liyane, kabijakan jaringan ditemtokake ing YAML. Ing conto ing ngisor iki, aplikasi balance akses menyang 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

(Cathetan. nerjemahake.: gambar iki, kaya kabeh sing padha sabanjure, digawe ora nggunakake alat Kubernetes asli, nanging nggunakake alat Tufin Orca, sing dikembangake dening perusahaan penulis artikel asli lan kasebut ing pungkasan materi.)

Kanggo nemtokake kabijakan jaringan sampeyan dhewe, sampeyan butuh kawruh dhasar babagan YAML. Basa iki adhedhasar indentasi (ditemtokake spasi tinimbang tab). Unsur indentasi kalebu unsur indentasi paling cedhak ing ndhuwur. Elemen dhaptar anyar diwiwiti kanthi tanda hubung, kabeh unsur liyane duwe wujud kunci-nilai.

Sawise diterangake kabijakan ing YAML, gunakake kubectlkanggo nggawe ing kluster:

kubectl create -f policy.yaml

Spesifikasi Kebijakan Jaringan

Spesifikasi kabijakan jaringan Kubernetes kalebu papat unsur:

1. podSelector: nemtokake polong sing kena pengaruh kebijakan iki (target) - dibutuhake;
2. policyTypes: nuduhake jinis kawicaksanan apa sing kalebu ing iki: ingress lan / utawa egress - opsional, nanging aku menehi saran kanthi tegas nemtokake ing kabeh kasus;
3. ingress: nemtokake diijini mlebu lalu lintas menyang target pods - opsional;
4. egress: nemtokake diijini metu lalu lintas saka polong target opsional.

Conto dijupuk saka situs web Kubernetes (aku ngganti role ing app), nuduhake carane kabeh papat unsur digunakake:

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

Elinga yen kabeh papat unsur ora kudu dilebokake. Iku mung wajib podSelector, paramèter liyane bisa digunakake kaya sing dikarepake.

Yen sampeyan ngilangi policyTypes, kebijakan kasebut bakal diinterpretasikake kaya ing ngisor iki:

• Kanthi gawan, dianggep nemtokake sisih ingress. Yen kabijakan kasebut ora nyatakake kanthi jelas, sistem bakal nganggep yen kabeh lalu lintas dilarang.
• Prilaku ing sisih egress bakal ditemtokake dening anane utawa ora ana parameter egress sing cocog.

Kanggo ngindhari kesalahan aku nyaranake tansah nggawe eksplisit policyTypes.

Miturut logika ndhuwur, yen paramèter ingress lan / utawa egress tilar, kabijakan bakal nolak kabeh lalu lintas (ndeleng "Aturan Stripping" ing ngisor iki).

Kabijakan standar yaiku Allow

Yen ora ana kabijakan sing ditetepake, Kubernetes ngidini kabeh lalu lintas minangka standar. Kabeh pods bisa bebas ijol-ijolan informasi ing antarane awake dhewe. Iki bisa uga katon counterintuitive saka perspektif keamanan, nanging elinga yen Kubernetes wiwitane dirancang dening pangembang kanggo ngaktifake interoperabilitas aplikasi. Kabijakan jaringan ditambahake mengko.

Spasi jeneng

Namespaces minangka mekanisme kolaborasi Kubernetes. Padha dirancang kanggo ngisolasi lingkungan logis saka saben liyane, nalika komunikasi antarane spasi diijini minangka standar.

Kaya umume komponen Kubernetes, kabijakan jaringan urip ing ruang jeneng tartamtu. Ing blok metadata sampeyan bisa nemtokake papan ngendi kabijakan kasebut kalebu:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: test-network-policy
  namespace: my-namespace  # <<<
spec:
...

Yen spasi jeneng ora ditemtokake sacara eksplisit ing metadata, sistem bakal nggunakake spasi jeneng sing ditemtokake ing kubectl (kanthi standar namespace=default):

kubectl apply -n my-namespace -f namespace.yaml

Aku nyaranake nemtokake namespace kanthi eksplisit, kajaba sampeyan nulis kabijakan sing nargetake sawetara ruang jeneng bebarengan.

Utama unsur podSelector ing kawicaksanan bakal milih pods saka namespace sing kabijakan belongs (iku ditolak akses kanggo pods saka namespace liyane).

Kajaba iku, podSelectors ing ingress lan egress pamblokiran mung bisa milih pods saka namespace dhewe, kajaba mesthi sampeyan gabungke karo namespaceSelector (iki bakal dibahas ing bagean "Saring miturut ruang jeneng lan pod").

Aturan Jeneng Kebijakan

Jeneng kebijakan unik ing papan jeneng sing padha. Ora bisa ana rong kawicaksanan kanthi jeneng sing padha ing papan sing padha, nanging bisa uga ana kawicaksanan kanthi jeneng sing padha ing papan sing beda. Iki migunani yen sampeyan pengin nglamar maneh kabijakan sing padha ing pirang-pirang spasi.

Aku utamané seneng salah siji saka cara jeneng. Iku kasusun saka nggabungake jeneng namespace karo polong target. Tuladhane:

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

Sampeyan bisa masang label khusus menyang obyek Kubernetes, kayata pod lan ruang jeneng. Label (labels - tags) padha karo tag ing méga. Kabijakan jaringan Kubernetes nggunakake label kanggo milih polongsing ditrapake:

podSelector:
  matchLabels:
    role: db

… utawa spasi jenengsing padha ditrapake. Conto iki milih kabeh pod ing ruang jeneng kanthi label sing cocog:

namespaceSelector:
  matchLabels:
    project: myproject

Siji ati-ati: nalika nggunakake namespaceSelector priksa manawa spasi jeneng sing sampeyan pilih ngemot label sing bener. Elinga yen spasi jeneng sing dibangun kayata default и kube-system, kanthi gawan ora ngemot label.

Sampeyan bisa nambah label menyang spasi kaya iki:

kubectl label namespace default namespace=default

Ing wektu sing padha, namespace ing bagean kasebut metadata kudu ngrujuk marang jeneng spasi sing nyata, dudu label:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: test-network-policy
  namespace: default   # <<<
spec:
...

Sumber lan tujuan

Kabijakan firewall kalebu aturan karo sumber lan tujuan. Kawicaksanan jaringan Kubernetes ditetepake kanggo target - sakumpulan pod sing ditrapake - banjur nyetel aturan kanggo lalu lintas mlebu lan/utawa egress. Ing conto kita, target kabijakan bakal kabeh pods ing namespace default karo label karo tombol app lan makna 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

Subbagian ingress ing kabijakan iki, mbukak lalu lintas mlebu menyang polong target. Ing tembung liya, ingress minangka sumber lan target minangka tujuan sing cocog. Kajaba iku, egress minangka tujuan lan target minangka sumber.

Iki padha karo rong aturan firewall: Ingress → Target; Goal → Egress.

Egress lan DNS (penting!)

Kanthi mbatesi lalu lintas metu, mbayar manungsa waé khusus kanggo DNS - Kubernetes nggunakake layanan iki kanggo peta layanan menyang alamat IP. Contone, kabijakan ing ngisor iki ora bisa digunakake amarga sampeyan ora ngidini aplikasi kasebut balance akses 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

Sampeyan bisa ndandani kanthi mbukak akses menyang 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

Unsur pungkasan to kosong, lan mulane ora langsung milih kabeh pods ing kabeh namespaces, ngidini balance ngirim pitakon DNS menyang layanan Kubernetes sing cocog (biasane mlaku ing spasi kube-system).

Pendekatan iki bisa digunakake, nanging kebacut permisif lan ora aman, amarga ngidini pitakon DNS diarahake ing njaba kluster.

Sampeyan bisa nambah ing telung langkah berturut-turut.

1. Mung ngidini pitakon DNS ing njero kluster kanthi nambah 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. Ngidini pitakon DNS mung ing ruang jeneng kube-system.

Kanggo nindakake iki, sampeyan kudu nambah label menyang namespace kube-system: kubectl label namespace kube-system namespace=kube-system - lan nulis ing kawicaksanan nggunakake 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. Wong paranoid bisa luwih maju lan mbatesi pitakon DNS menyang layanan DNS tartamtu ing kube-system. Bagean "Saring miturut ruang jeneng lan pods" bakal menehi pitutur marang sampeyan carane entuk iki.

Pilihan liyane kanggo ngatasi DNS ing tingkat namespace. Ing kasus iki, ora perlu dibukak kanggo saben 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

Kosong podSelector milih kabeh pods ing namespace.

Pertandhingan pisanan lan urutan aturan

Ing firewalls konvensional, tumindak (Allow utawa Deny) ing paket ditemtokake dening aturan pisanan sing marem. Ing Kubernetes, urutan kabijakan ora dadi masalah.

Kanthi gawan, nalika ora ana kawicaksanan sing disetel, komunikasi antarane pods diidini lan bisa kanthi bebas ngganti informasi. Sawise sampeyan miwiti ngrumusake kawicaksanan, saben pod sing kena pengaruh paling ora salah sijine bakal diisolasi miturut disjunction (logis UTAWA) kabeh kabijakan sing dipilih. Pod sing ora kena pengaruh kebijakan apa wae tetep mbukak.

Sampeyan bisa ngganti prilaku iki nggunakake aturan stripping.

Aturan Stripping ("Deny")

Kabijakan firewall biasane nolak lalu lintas sing ora diidini kanthi jelas.

Ora ana tumindak sing ditolak ing KubernetesNanging, efek sing padha bisa digayuh kanthi kabijakan biasa (permisif) kanthi milih klompok polong sumber (ingress):

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

Kabijakan iki milih kabeh pods ing namespace lan ninggalake ingress undefined, nolak kabeh lalu lintas mlebu.

Kanthi cara sing padha, sampeyan bisa mbatesi kabeh lalu lintas metu saka ruang jeneng:

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

Wigati dicathet sembarang kawicaksanan tambahan ngidini lalu lintas menyang pods ing namespace bakal njupuk precedence saka aturan iki (padha nambahake aturan ngidini sadurunge aturan nolak ing konfigurasi firewall).

Ngidini kabeh (Any-Any-Any-Allow)

Kanggo nggawe kabijakan Allow All, sampeyan kudu nambah kabijakan Deny ing ndhuwur kanthi unsur kosong ingress:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-all
  namespace: default
spec:
  podSelector: {}
  ingress: # <<<
  - {}     # <<<
  policyTypes:
  - Ingress

Iku ngidini akses saka kabeh pod ing kabeh namespaces (lan kabeh IP) menyang sembarang pod ing namespace default. Prilaku iki diaktifake kanthi gawan, mula biasane ora perlu ditetepake maneh. Nanging, kadhangkala sampeyan bisa uga kudu mateni sawetara ijin khusus kanggo diagnosa masalah.

Aturan bisa narrowed mudhun kanggo ngidini akses mung kanggo pesawat tartamtu saka pods (app:balance) ing papan jeneng default:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-all-to-balance
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: balance
  ingress: 
  - {}
  policyTypes:
  - Ingress

Kabijakan ing ngisor iki ngidini kabeh lalu lintas mlebu lan metu, kalebu akses menyang IP apa wae ing njaba kluster:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-all
spec:
  podSelector: {}
  ingress:
  - {}
  egress:
  - {}
  policyTypes:
  - Ingress
  - Egress

Nggabungke Multiple Kawicaksanan

Kawicaksanan digabungake nggunakake logis UTAWA ing telung tingkat; Saben ijin pod disetel sesuai karo disjunction kabeh kabijakan sing mengaruhi:

1. Ing sawah from и to Telung jinis unsur bisa ditetepake (kabeh digabungake nggunakake OR):

• namespaceSelector - milih kabeh namespace;
• podSelector - milih polong;
• ipBlock — milih subnet.

Kajaba iku, jumlah unsur (malah padha) ing subbagian from/to ora winates. Kabeh mau bakal digabungake kanthi logis UTAWA.

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. Nang bagean privasi ingress bisa duwe akeh unsur from (digabungake karo OR logis). Kajaba iku, bagean egress bisa kalebu akeh unsur to (uga digabungake kanthi disjunction):

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. Kawicaksanan sing beda-beda uga digabungake karo UTAWA logis

Nanging nalika gabungke, ana siji watesan nuding Chris Cooney: Kubernetes mung bisa gabungke kawicaksanan karo beda policyTypes (Ingress utawa Egress). Kabijakan sing nemtokake ingress (utawa egress) bakal nimpa saben liyane.

Hubungan antarane spasi jeneng

Kanthi gawan, nuduhake informasi antarane spasi jeneng diijini. Iki bisa diganti kanthi nggunakake kabijakan nolak sing bakal mbatesi lalu lintas sing metu lan / utawa mlebu menyang ruang jeneng (pirsani "Aturan Stripping" ing ndhuwur).

Sawise sampeyan wis mblokir akses menyang namespace (ndeleng "Aturan Stripping" ing ndhuwur), sampeyan bisa nggawe pangecualian kanggo kabijakan nolak kanthi ngidini sambungan saka namespace tartamtu nggunakake 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

Akibaté, kabeh pods ing namespace default bakal duwe akses menyang pods postgres ing namespace database. Nanging apa yen sampeyan pengin mbukak akses menyang postgres mung pods tartamtu ing namespace default?

Nyaring miturut namespaces lan pods

Kubernetes versi 1.11 lan luwih dhuwur ngidini sampeyan nggabungake operator namespaceSelector и podSelector nggunakake logika AND. Iku katon kaya iki:

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

Napa iki diinterpretasikake minangka AND tinimbang UTAWA biasa?

elinga yen podSelector ora diwiwiti nganggo tanda hubung. Ing YAML iki tegese podSelector lan ngadeg ing ngarepe namespaceSelector deleng unsur dhaftar padha. Mulane, digabungake karo logika AND.

Nambahake tandha hubung sadurunge podSelector bakal nyebabake munculna unsur dhaptar anyar, sing bakal digabung karo sing sadurunge namespaceSelector nggunakake logika OR.

Kanggo milih polong kanthi label tartamtu ing kabeh spasi jeneng, ketik kosong namespaceSelector:

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

Akeh label gabung karo I

Aturan kanggo firewall karo macem-macem obyek (host, jaringan, grup) digabungake nggunakake UTAWA logis. Aturan ing ngisor iki bakal bisa digunakake yen sumber paket cocog Host_1 Utawa Host_2:

| Source | Destination | Service | Action |
| ----------------------------------------|
| Host_1 | Subnet_A    | HTTPS   | Allow  |
| Host_2 |             |         |        |
| ----------------------------------------|

Kosok baline, ing Kubernetes macem-macem label ing podSelector utawa namespaceSelector digabungake karo logika AND. Contone, aturan ing ngisor iki bakal milih pod sing duwe label loro, role=db И version=v2:

podSelector:
  matchLabels:
    role: db
    version: v2

Logika sing padha ditrapake kanggo kabeh jinis operator: pamilih target kebijakan, pamilih pod, lan pamilih namespace.

Subnet lan alamat IP (IPBlocks)

Firewall nggunakake VLAN, alamat IP, lan subnet kanggo ngetung jaringan.

Ing Kubernetes, alamat IP ditugasake menyang pods kanthi otomatis lan bisa kerep diganti, mula label digunakake kanggo milih pods lan namespaces ing kabijakan jaringan.

Subnet (ipBlocks) digunakake nalika ngatur sambungan mlebu (ingress) utawa metu (egress) eksternal (Utara-Kidul). Contone, kabijakan iki mbukak kanggo kabeh pods saka namespace default akses menyang layanan DNS Google:

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 ing conto iki tegese "pilih kabeh pod ing ruang jeneng."

Kabijakan iki mung ngidini akses menyang 8.8.8.8; akses menyang IP liyane dilarang. Dadi, intine, sampeyan wis mblokir akses menyang layanan DNS Kubernetes internal. Yen sampeyan isih pengin mbukak, tandhani kanthi jelas.

biasane ipBlocks и podSelectors eksklusif, amarga alamat IP internal pods ora digunakake ing ipBlocks. Kanthi nuduhake IP pod internal, sampeyan bener bakal ngidini sambungan menyang/saka pods karo alamat iki. Ing praktik, sampeyan ora bakal ngerti alamat IP sing bakal digunakake, mula ora bisa digunakake kanggo milih pods.

Minangka conto kontra, kabijakan ing ngisor iki nyakup kabeh IP lan mula ngidini akses menyang kabeh pod liyane:

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

Sampeyan mung bisa mbukak akses menyang IP eksternal, ora kalebu alamat IP internal pods. Contone, yen subnet pod sampeyan 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 lan protokol

Biasane pods ngrungokake siji port. Iki tegese sampeyan ora bisa nemtokake nomer port ing kabijakan lan ninggalake kabeh minangka standar. Nanging, disaranake nggawe kabijakan minangka mbatesi, saengga ing sawetara kasus sampeyan isih bisa nemtokake 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

Elinga yen pamilih ports ditrapake kanggo kabeh unsur ing pemblokiran to utawa from, kang ngandhut. Kanggo nemtokake port beda kanggo set unsur beda, pamisah ingress utawa egress dadi sawetara subbagian karo to utawa from lan ing saben ndhaptar port sampeyan:

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

Operasi port standar:

• Yen sampeyan ngilangi definisi port kanthi lengkap (ports), iki tegese kabeh protokol lan kabeh port;
• Yen sampeyan ngilangi definisi protokol (protocol), iki tegese TCP;
• Yen sampeyan ngilangi definisi port (port), iki tegese kabeh port.

Praktek paling apik: Aja ngandelake nilai standar, nemtokake apa sing sampeyan butuhake kanthi jelas.

Elinga yen sampeyan kudu nggunakake port pod, dudu port layanan (liyane babagan iki ing paragraf sabanjure).

Apa kabijakan ditetepake kanggo pod utawa layanan?

Biasane, pods ing Kubernetes ngakses saben liyane liwat layanan - imbangan beban virtual sing ngarahake lalu lintas menyang pods sing ngetrapake layanan kasebut. Sampeyan bisa uga mikir yen kabijakan jaringan ngontrol akses menyang layanan, nanging ora kaya ngono. Kabijakan jaringan Kubernetes bisa digunakake ing port pod, dudu port layanan.

Contone, yen layanan ngrungokake port 80, nanging ngarahake lalu lintas menyang port 8080 saka pods, sampeyan kudu nemtokake persis 8080 ing kabijakan jaringan.

Mekanisme kasebut kudu dianggep suboptimal: yen struktur internal layanan (port sing dirungokake) diganti, kabijakan jaringan kudu dianyari.

Pendekatan arsitektur anyar nggunakake Service Mesh (contone, deleng babagan Istio ing ngisor iki - kira-kira transl.) ngijini sampeyan kanggo ngrampungake karo masalah iki.

Apa kudu ndhaptar Ingress lan Egress?

Jawaban singkat ya, supaya pod A bisa komunikasi karo pod B, kudu diijini nggawe sambungan metu (kanggo iki sampeyan kudu ngatur kabijakan egress), lan pod B kudu bisa nampa sambungan sing mlebu ( kanggo iki, miturut, sampeyan kudu kawicaksanan ingress).

Nanging, ing laku, sampeyan bisa ngandelake kabijakan standar kanggo ngidini sambungan ing siji utawa loro arah.

Yen sawetara pod-sumber bakal dipilih dening siji utawa luwih nglanggar-politisi, Watesan dileksanakake ing bakal ditemtokake dening disjunction sing. Ing kasus iki, sampeyan kudu kanthi tegas ngidini sambungan menyang pod -marang sing dituju. Yen pod ora dipilih miturut kabijakan apa wae, lalu lintas metu (egress) diijini kanthi gawan.

Semono uga nasib polongalamate, dipilih dening siji utawa luwih ingress-politisi, bakal ditemtokake dening disjunction sing. Ing kasus iki, sampeyan kudu kanthi tegas ngidini nampa lalu lintas saka pod sumber. Yen polong ora dipilih miturut kabijakan apa wae, kabeh lalu lintas ingress diidini kanthi gawan.

Waca Stateful utawa Stateless ngisor.

Log

Kabijakan jaringan Kubernetes ora bisa nyathet lalu lintas. Iki nggawe angel kanggo nemtokake manawa ana kabijakan bisa digunakake kaya sing dikarepake lan nyebabake analisa keamanan.

Kontrol lalu lintas menyang layanan eksternal

Kabijakan jaringan Kubernetes ora ngidini sampeyan nemtokake jeneng domain (DNS) kanthi lengkap ing bagean egress. Kasunyatan iki nyebabake rasa ora nyaman nalika nyoba mbatesi lalu lintas menyang tujuan eksternal sing ora duwe alamat IP tetep (kayata aws.com).

Priksa Kebijakan

Firewall bakal ngelingake sampeyan utawa malah ora gelem nampa kabijakan sing salah. Kubernetes uga nindakake sawetara verifikasi. Nalika nyetel kabijakan jaringan liwat kubectl, Kubernetes bisa nyatakake yen iku salah lan ora gelem nampa. Ing kasus liyane, Kubernetes bakal njupuk kabijakan lan ngisi rincian sing ilang. Padha bisa dideleng nggunakake printah:

kubernetes get networkpolicy <policy-name> -o yaml

Elinga yen sistem validasi Kubernetes ora salah lan bisa uga ilang sawetara jinis kesalahan.

Kaleksanan

Kubernetes ora ngleksanakake kabijakan jaringan dhewe, nanging mung minangka gateway API sing ngirimake beban kontrol menyang sistem dhasar sing diarani Container Networking Interface (CNI). Nyetel kawicaksanan ing kluster Kubernetes tanpa nemtokake CNI sing cocog iku padha karo nggawe kawicaksanan ing server manajemen firewall tanpa banjur nginstal ing firewall. Terserah sampeyan kanggo mesthekake yen sampeyan duwe CNI sing layak utawa, ing kasus platform Kubernetes, di-host ing méga (sampeyan bisa ndeleng dhaptar panyedhiya kene - kira-kira. trans.), ngaktifake kabijakan jaringan sing bakal nyetel CNI kanggo sampeyan.

Elinga yen Kubernetes ora bakal ngelingake yen sampeyan nyetel kabijakan jaringan tanpa bantuan CNI sing cocog.

Stateful utawa Stateless?

Kabeh Kubernetes CNIs aku wis ditemoni stateful (contone, Calico nggunakake Linux conntrack). Iki ngidini pod nampa respon ing sambungan TCP sing diwiwiti tanpa kudu nggawe maneh. Nanging, aku ora ngerti standar Kubernetes sing bakal njamin status.

Manajemen Kebijakan Keamanan Lanjut

Mangkene sawetara cara kanggo nambah penegakan kabijakan keamanan ing Kubernetes:

1. Pola arsitektur Service Mesh nggunakake wadhah sidecar kanggo nyedhiyakake telemetri lan kontrol lalu lintas sing rinci ing tingkat layanan. Minangka conto kita bisa njupuk Istio.
2. Sawetara vendor CNI wis ngluwihi alat kanggo ngluwihi kabijakan jaringan Kubernetes.
3. Tufin Orca Nyedhiyakake visibilitas lan otomatisasi kabijakan jaringan Kubernetes.

Paket Tufin Orca ngatur kabijakan jaringan Kubernetes (lan minangka sumber gambar ing ndhuwur).

informasi tambahan

• Conto kabijakan jaringan sing disiapake dening Ahmet Alp Balkan saka GKE;
• Dokumentasi saka situs web resmi Kubernetes;
• Pandhuan kanggo Model Jaringan Kubernetes;
• Skrip kanggo mriksa kabijakan jaringan.

kesimpulan

Kawicaksanan jaringan Kubernetes nawakake macem-macem alat sing apik kanggo segmentasi klompok, nanging ora intuisi lan duwe akeh subtleties. Amarga kerumitan iki, aku pracaya akeh kawicaksanan cluster ana buggy. Solusi sing bisa kanggo masalah iki kalebu ngotomatisasi definisi kebijakan utawa nggunakake alat segmentasi liyane.

Muga-muga pandhuan iki mbantu ngrampungake sawetara pitakonan lan ngrampungake masalah sing bisa sampeyan temoni.

PS saka penerjemah

Waca uga ing blog kita:

• "Bali menyang microservices karo Istio": bagean 1 (pambuka kanggo fitur utama), bagean 2 (rute, kontrol lalu lintas), Part 3 (Keamanan);
• "Pandhuan Ilustrasi kanggo Jaringan ing Kubernetes": bagean 1 lan 2 (model jaringan, jaringan overlay), bagean 3 (layanan lan pangolahan lalu lintas);
• «Docker lan Kubernetes ing lingkungan sing nuntut keamanan";
• «9 Praktek Paling Apik kanggo Keamanan Kubernetes";
• «11 Cara kanggo (Ora) Dadi Korban Hack Kubernetes".

Source: www.habr.com