🥇Perkenalan kana Kabijakan Jaringan Kubernetes pikeun Profesional Kaamanan

Catetan. narjamahkeun.: Panulis artikel, Reuven Harrison, boga leuwih 20 taun pangalaman dina ngembangkeun software, sarta ayeuna teh CTO jeung ko-pangadeg Tufin, hiji parusahaan nu nyiptakeun solusi manajemén kawijakan kaamanan. Bari anjeunna nempo kawijakan jaringan Kubernetes salaku alat anu cukup kuat pikeun segmentation jaringan dina klaster a, anjeunna ogé yakin yén maranéhna teu jadi gampang pikeun nerapkeun dina prakna. Bahan ieu (rada voluminous) dimaksudkeun pikeun ningkatkeun kasadaran spesialis ngeunaan masalah ieu sareng ngabantosan aranjeunna nyiptakeun konfigurasi anu diperyogikeun.

Kiwari, seueur perusahaan beuki milih Kubernetes pikeun ngajalankeun aplikasina. Minat kana parangkat lunak ieu kacida luhurna sahingga aya anu nyebat Kubernetes "sistem operasi énggal pikeun pusat data." Saeutik demi saeutik, Kubernetes (atanapi k8s) mimiti ditanggap salaku bagian kritis bisnis, anu meryogikeun organisasi prosés bisnis anu dewasa, kalebet kaamanan jaringan.

Pikeun professional kaamanan anu bingung ku gawé bareng Kubernetes, wahyu nyata bisa jadi kawijakan standar platform: ngidinan sagalana.

Pituduh ieu bakal ngabantosan anjeun ngartos struktur internal kawijakan jaringan; ngartos kumaha aranjeunna béda ti aturan pikeun firewalls biasa. Éta ogé bakal nutupan sababaraha pitfalls sareng masihan saran pikeun ngabantosan aplikasi aman dina Kubernetes.

Kawijakan jaringan Kubernetes

Mékanisme kawijakan jaringan Kubernetes ngamungkinkeun anjeun pikeun ngatur interaksi aplikasi anu dipasang dina platform dina lapisan jaringan (katilu dina modél OSI). Kawijakan jaringan kakurangan sababaraha fitur canggih tina firewall modern, sapertos penegak OSI Layer 7 sareng deteksi ancaman, tapi aranjeunna nyayogikeun tingkat dasar kaamanan jaringan anu mangrupikeun titik awal anu saé.

Kawijakan jaringan ngadalikeun komunikasi antara pods

Beban gawé di Kubernetes disebarkeun ka sakuliah pods, anu diwangun ku hiji atawa leuwih wadah anu disebarkeun babarengan. Kubernetes napelkeun unggal pod hiji alamat IP nu bisa diasupan ti pods séjén. Kawijakan jaringan Kubernetes netepkeun hak aksés pikeun grup pods dina cara anu sami sareng grup kaamanan dina méga dianggo pikeun ngadalikeun aksés ka instansi mesin virtual.

Nangtukeun Kawijakan Jaringan

Sapertos sumberdaya Kubernetes anu sanés, kawijakan jaringan ditetepkeun dina YAML. Dina conto di handap, aplikasi balance aksés ka 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

(Catetan. narjamahkeun.: Potret layar ieu, sapertos sadayana anu sami, diciptakeun sanés nganggo alat Kubernetes asli, tapi nganggo alat Tufin Orca, anu dikembangkeun ku perusahaan panulis tulisan asli sareng anu disebatkeun dina tungtung bahan.)

Pikeun nangtukeun kawijakan jaringan anjeun sorangan, anjeun peryogi pangaweruh dasar ngeunaan YAML. Basa ieu dumasar kana indentasi (ditetepkeun ku spasi tinimbang tab). Unsur indented milik unsur indented pangcaketna luhureun eta. Hiji elemen daptar anyar dimimitian ku hyphen a, kabéh elemen séjén boga formulir konci-nilai.

Saanggeus ngajelaskeun kawijakan di YAML, make kubectlpikeun nyiptakeunana dina kluster:

kubectl create -f policy.yaml

Spésifikasi Kawijakan Jaringan

Spésifikasi kawijakan jaringan Kubernetes ngawengku opat elemen:

podSelector: nangtukeun pods kapangaruhan ku kawijakan ieu (target) - diperlukeun;
policyTypes: nunjukkeun naon jenis kawijakan anu kaasup dina ieu: ingress na / atawa egress - pilihan, tapi kuring nyarankeun eksplisit nangtukeun eta dina sagala hal;
ingress: ngahartikeun diwenangkeun asup lalulintas keur sasaran pods - pilihan;
egress: ngahartikeun diwenangkeun kaluar lalulintas ti pods target nyaeta pilihan.

Conto dicokot tina situs web Kubernetes (kuring ngaganti role dina app), nunjukkeun kumaha sadayana opat unsur dianggo:

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

Punten dicatet yén sadaya opat unsur henteu kedah dilebetkeun. Ieu ngan wajib podSelector, parameter séjén bisa dipaké sakumaha dipikahoyongna.

Upami anjeun ngaleungitkeun policyTypes, kawijakan bakal diinterpretasi saperti kieu:

Sacara standar, éta dianggap yén éta ngahartikeun sisi ingress. Upami kawijakan henteu sacara eksplisit nyatakeun ieu, sistem bakal nganggap yén sadaya lalu lintas dilarang.
Paripolah di sisi egress bakal ditangtukeun ku ayana atawa henteuna parameter egress pakait.

Pikeun ngahindarkeun kasalahan kuring nyarankeun salawasna nyieun eksplisit policyTypes.

Numutkeun logika luhur, lamun parameter ingress jeung / atawa egress disingkahkeun, kawijakan bakal mungkir sadaya lalulintas (tingali "Stripping Aturan" handap).

Kabijakan standar nyaéta Ngidinan

Upami teu aya kawijakan anu ditetepkeun, Kubernetes ngamungkinkeun sadaya lalu lintas sacara standar. Kabéh pods bisa kalawan bébas tukeur informasi diantara sorangan. Ieu sigana kontraintuitif tina sudut pandang kaamanan, tapi émut yén Kubernetes asalna dirancang ku pamekar pikeun ngaktipkeun interoperabilitas aplikasi. kawijakan jaringan ditambahkeun engké.

Ruang ngaran

Ruang ngaran nyaéta mékanisme kolaborasi Kubernetes. Éta dirancang pikeun ngasingkeun lingkungan logis tina unggal anu sanés, sedengkeun komunikasi antara rohangan diidinan sacara standar.

Kawas sabagéan ageung komponén Kubernetes, kawijakan jaringan hirup dina spasi ngaran husus. Dina blok metadata anjeun tiasa netepkeun ruang mana kawijakan éta milik:

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

Lamun ngaranspasi teu dieusian sacara eksplisit dina metadata, sistem bakal ngagunakeun ngaranspasi dieusian dina kubectl (sacara standar. namespace=default):

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

Abdi nyarankeun tangtukeun namespace sacara eksplisit, iwal mun nuju nulis kawijakan anu nargétkeun sababaraha spasi ngaran sakaligus.

Nu utama unsur podSelector dina kawijakan bakal milih pods ti namespace nu kawijakan milik (eta ditolak aksés ka pods ti namespace sejen).

Nya kitu, podSelectors dina blok asup jeung kaluar ngan bisa milih pods ti namespace sorangan, iwal tangtu anjeun ngagabungkeun aranjeunna kalayan namespaceSelector (ieu bakal dibahas dina bagian "Saring ku namespaces sareng pods").

Kawijakan Ngaran Aturan

Ngaran kawijakan unik dina spasi ngaran anu sarua. Henteu tiasa aya dua kawijakan anu nami anu sami dina rohangan anu sami, tapi tiasa aya kawijakan anu nami anu sami dina rohangan anu béda. Ieu mangpaat nalika anjeun hoyong nerapkeun deui kawijakan anu sami dina sababaraha rohangan.

Kuring utamana resep salah sahiji metodeu ngaran. Ieu diwangun ku ngagabungkeun ngaran spasi ngaran jeung pods target. Salaku conto:

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

Labél

Anjeun tiasa ngagantelkeun labél khusus ka objék Kubernetes, sapertos pods sareng namespaces. Label (labél - tags) sarua jeung tag dina awan. Kabijakan jaringan Kubernetes nganggo labél pikeun milih polongnu aranjeunna nerapkeun:

podSelector:
  matchLabels:
    role: db

… atawa spasi ngarannu aranjeunna nerapkeun. Conto ieu milih sadaya pods dina rohangan ngaran sareng labél anu cocog:

namespaceSelector:
  matchLabels:
    project: myproject

Hiji caution: nalika ngagunakeun namespaceSelector pastikeun rohangan ngaran anu anjeun pilih ngandung labél anu leres. Sadar yén diwangun-di namespaces kayaning default и kube-system, sacara standar teu ngandung labél.

Anjeun tiasa nambihan labél ka rohangan sapertos kieu:

kubectl label namespace default namespace=default

Dina waktu nu sarua, ngaranspasi dina bagian metadata kedah ngarujuk kana nami rohangan anu saleresna, sanés labélna:

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

Sumber jeung tujuan

Kawijakan firewall diwangun ku aturan sareng sumber sareng tujuan. Kawijakan jaringan Kubernetes ditetepkeun pikeun udagan - sakumpulan polong anu diterapkeun - teras netepkeun aturan pikeun lalu lintas asup sareng/atanapi kaluar. Dina conto urang, udagan kawijakan bakal sadayana pods dina namespace default kalawan labél jeung konci app jeung hartina 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 dina kawijakan ieu, muka lalulintas asup ka pods target. Dina basa sejen, ingress mangrupa sumber jeung udagan téh tujuan pakait. Kitu ogé, kaluar téh tujuan jeung udagan téh sumber na.

Ieu sarua jeung dua aturan firewall: Ingress → Target; Tujuan → Kaluar.

Egress sareng DNS (penting!)

Ku ngawatesan lalu lintas kaluar, nengetan husus ka DNS - Kubernetes ngagunakeun jasa ieu pikeun peta jasa ka alamat IP. Salaku conto, kawijakan di handap ieu moal jalan sabab anjeun henteu ngijinkeun aplikasina balance aksés 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

Anjeun tiasa ngalereskeunana ku muka aksés ka 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 panungtungan to kosong, sarta ku kituna teu langsung milih kabéh pods dina sakabéh namespaces, ngidinan balance kirimkeun pamundut DNS ka layanan Kubernetes anu luyu (biasana dijalankeun dina rohangan kube-system).

pendekatan ieu jalan, kumaha oge overly permisif jeung teu aman, sabab ngamungkinkeun queries DNS diarahkeun ka luar klaster.

Anjeun tiasa ningkatkeun éta dina tilu léngkah berturut-turut.

1. Ngidinan queries DNS wungkul di jero klaster ku nambahkeun 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. Ngidinan queries DNS dina namespace wungkul kube-system.

Jang ngalampahkeun ieu anjeun kudu nambahkeun labél ka namespace nu kube-system: kubectl label namespace kube-system namespace=kube-system - jeung nulis eta handap dina kawijakan ngagunakeun 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. jalma paranoid bisa balik malah salajengna jeung ngawatesan queries DNS ka layanan DNS husus di kube-system. Bagian "Saring ku namespaces AND pods" bakal ngabejaan Anjeun kumaha carana ngahontal ieu.

Pilihan séjén nyaéta pikeun ngabéréskeun DNS dina tingkat ngaranspasi. Dina hal ieu, éta henteu kedah dibuka pikeun unggal jasa:

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 sadaya pods dina namespace.

pertandingan kahiji jeung urutan aturan

Dina firewalls konvensional, lampah (Ngidinan atanapi mungkir) dina pakét ditangtukeun ku aturan munggaran nu satisfies. Dina Kubernetes, urutan kawijakan henteu masalah.

Sacara standar, nalika teu aya kawijakan anu disetel, komunikasi antara pods diidinan sareng aranjeunna tiasa bebas tukeur inpormasi. Sakali anjeun ngawitan ngarumuskeun kawijakan, unggal pod kapangaruhan ku sahanteuna salah sahijina jadi terasing nurutkeun disjunction (logis OR) tina sakabeh kawijakan nu dipilih eta. Pod anu henteu kapangaruhan ku kawijakan naon waé tetep kabuka.

Anjeun tiasa ngarobah kabiasaan ieu ngagunakeun aturan stripping.

Aturan stripping ("Deny")

Kawijakan firewall biasana nolak lalulintas anu henteu diidinan sacara eksplisit.

Teu aya aksi mungkir dina Kubernetes, kumaha oge, pangaruh sarupa bisa dihontal ku kawijakan biasa (permisif) ku milih grup kosong tina pods sumber (ingress):

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

Kabijakan ieu milih sadaya pods dina rohangan ngaran sareng ngantepkeun asupna teu ditangtukeun, nolak sadaya lalu lintas anu asup.

Dina cara anu sami, anjeun tiasa ngabatesan sadaya lalu lintas kaluar tina rohangan ngaran:

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

Catet yén kabijakan tambahan naon waé anu ngamungkinkeun lalu lintas kana polong dina rohangan ngaran bakal diutamakeun tina aturan ieu (sarupa jeung nambahkeun hiji ngidinan aturan saméméh aturan mungkir dina konfigurasi firewall).

Ngidinan sadayana (Any-Any-Any-Allow)

Pikeun nyieun kawijakan Ngidinan Sadaya, anjeun kedah nambihan kabijakan Deny di luhur kalayan unsur kosong ingress:

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

Hal ieu ngamungkinkeun aksés ti kabéh pods dina sakabéh namespaces (jeung sakabeh IP) kana sagala pod di namespace default. Paripolah ieu diaktipkeun sacara standar, janten biasana henteu kedah didefinisikeun deui. Nanging, sakapeung anjeun kedah nganonaktipkeun samentawis sababaraha idin khusus pikeun ngadiagnosa masalah.

Aturan bisa narrowed handap pikeun ngidinan aksés ngan ka set husus tina pods (app:balance) dina spasi ngaran 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 di handap ieu ngamungkinkeun sadaya lalu lintas asup sareng kaluar, kalebet aksés ka IP mana waé di luar klaster:

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

Ngagabungkeun sababaraha Kawijakan

Kawijakan digabungkeun ngagunakeun OR logis dina tilu tingkatan; Unggal idin pod diatur saluyu sareng disjunction sadaya kawijakan anu mangaruhanana:

1. Di sawah from и to Tilu jinis elemen tiasa ditetepkeun (sadayana digabungkeun nganggo OR):

namespaceSelector - milih sakabéh spasi ngaran;
podSelector - milih pods;
ipBlock — milih subnet.

Leuwih ti éta, jumlah unsur (malah idéntik) dina subsections from/to teu kawates. Sakabéh éta bakal digabungkeun ku OR logis.

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 jero bagian kawijakan ingress tiasa gaduh seueur unsur from (digabungkeun ku OR logis). Nya kitu, bagian egress bisa ngawengku loba elemen to (ogé digabungkeun ku 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. kawijakan béda ogé digabungkeun jeung logis OR

Tapi nalika ngagabungkeun aranjeunna, aya hiji watesan nunjuk Chris Cooney: Kubernetes ngan bisa ngagabungkeun kawijakan jeung béda policyTypes (Ingress atawa Egress). Kawijakan anu nangtukeun ingress (atawa egress) bakal silih nimpa.

Hubungan antara ngaranspasi

Sacara standar, babagi inpormasi antara spasi ngaran diidinan. Ieu bisa dirobah ku ngagunakeun kawijakan mungkir anu bakal ngawatesan lalulintas kaluar jeung/atawa asup kana namespace (tingali "Stripping Aturan" luhur).

Sakali anjeun meungpeuk aksés ka namespace (tingali "Aturan Stripping" di luhur), anjeun tiasa ngadamel pengecualian kana kabijakan nolak ku ngawenangkeun sambungan tina rohangan ngaran khusus nganggo 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

Hasilna, sadaya pods dina namespace default bakal boga aksés ka pods postgres dina spasi ngaran database. Tapi kumaha upami anjeun hoyong muka aksés ka postgres ngan pods husus dina namespace default?

Nyaring dumasar spasi ngaran jeung pods

Kubernetes versi 1.11 jeung nu leuwih luhur ngidinan Anjeun pikeun ngagabungkeun operator namespaceSelector и podSelector ngagunakeun logika AND. Sigana mah kieu:

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

Naha ieu diinterpretasi salaku AND tinimbang biasa OR?

Catet éta podSelector teu dimimitian ku hyphen a. Dina YAML ieu hartina éta podSelector jeung nangtung hareupeunana namespaceSelector tingal unsur daptar anu sami. Ku alatan éta, aranjeunna digabungkeun jeung logis AND.

Nambahkeun hyphen sateuacanna podSelector bakal ngakibatkeun mecenghulna unsur daptar anyar, nu bakal digabungkeun jeung hiji saméméhna namespaceSelector ngagunakeun logika OR.

Pikeun milih pods kalawan labél husus dina sakabéh spasi ngaran, lebetkeun 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

Sababaraha labél gawé bareng I

Aturan pikeun firewall kalawan sababaraha objék (host, jaringan, grup) digabungkeun ngagunakeun OR logis. Aturan di handap bakal tiasa dianggo upami sumber pakét cocog Host_1 OR Host_2:

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

Sabalikna, dina Kubernetes rupa-rupa labél di podSelector atawa namespaceSelector digabungkeun sareng logika AND. Contona, aturan di handap ieu bakal milih pods anu gaduh dua labél, role=db И version=v2:

podSelector:
  matchLabels:
    role: db
    version: v2

Logika anu sami manglaku ka sadaya jinis operator: pamilih target kawijakan, pamilih pod, sareng pamilih namespace.

Subnet sareng alamat IP (IPBlocks)

Firewalls nganggo VLAN, alamat IP, sareng subnet pikeun ngabagi jaringan.

Dina Kubernetes, alamat IP ditugaskeun ka pods sacara otomatis sareng tiasa sering robih, janten labél dianggo pikeun milih pods sareng namespaces dina kawijakan jaringan.

Subnet (ipBlocks) dipaké nalika ngatur sambungan asup (ingress) atawa kaluar (egress) éksternal (Kalér-Selatan). Contona, kawijakan ieu muka ka sadaya pods ti namespace default aksés ka 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

Pamilih pod kosong dina conto ieu hartosna "pilih sadaya pods dina namespace".

Kawijakan ieu ngan ngamungkinkeun aksés ka 8.8.8.8; aksés ka IP séjén dilarang. Janten, intina, anjeun parantos ngablokir aksés kana layanan DNS Kubernetes internal. Upami anjeun masih hoyong muka éta, tunjukkeun ieu sacara eksplisit.

Biasana ipBlocks и podSelectors saling ekslusif, sabab alamat IP internal pods teu dipaké di ipBlocks. Ku nuduhkeun IP pods internal, anjeun sabenerna bakal ngidinan sambungan ka / ti pods kalawan alamat ieu. Dina prakna, anjeun moal terang alamat IP mana anu dianggo, naha éta henteu kedah dianggo pikeun milih pods.

Salaku conto kontra, kawijakan di handap ieu kalebet sadayana IP sahingga ngamungkinkeun aksés ka sadaya pods anu sanés:

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

Anjeun tiasa muka aksés ngan ka IP éksternal, teu kaasup alamat IP internal tina pods. Contona, upami subnet pod anjeun 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

Palabuhan jeung protokol

Biasana pods ngadangukeun hiji port. Ieu ngandung harti yén anjeun ngan saukur teu bisa nangtukeun nomer port dina kawijakan jeung ninggalkeun sagalana salaku standar. Nanging, disarankeun pikeun ngadamel kawijakan sabisa-bisa, janten dina sababaraha kasus anjeun masih tiasa netepkeun palabuhan:

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

Catet yén pamilih ports manglaku ka sadaya elemen dina blok to atawa from, nu ngandung. Pikeun nangtukeun palabuhan béda pikeun susunan elemen béda, pamisah ingress atawa egress kana sababaraha subsections kalawan to atawa from sareng dina unggal ngadaptar palabuhan anjeun:

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:

Upami anjeun ngaleungitkeun definisi port lengkep (ports), ieu hartina sakabéh protokol jeung sakabéh palabuhan;
Upami anjeun ngaleungitkeun definisi protokol (protocol), ieu hartina TCP;
Upami anjeun ngaleungitkeun definisi port (port), ieu hartosna sadaya palabuhan.

Prakték pangsaéna: Tong ngandelkeun nilai standar, tangtukeun naon anu anjeun peryogikeun sacara eksplisit.

Punten dicatet yén anjeun kedah nganggo palabuhan pod, sanés palabuhan jasa (langkung seueur ngeunaan ieu dina paragraf salajengna).

Naha kawijakan ditetepkeun pikeun pods atanapi jasa?

Ilaharna, pods di Kubernetes silih aksés ngaliwatan layanan - pangimbang beban virtual anu alihan lalu lintas ka pods anu ngalaksanakeun jasa éta. Anjeun tiasa mikir yén kawijakan jaringan ngadalikeun aksés ka jasa, tapi ieu sanés masalahna. Kawijakan jaringan Kubernetes dianggo dina palabuhan pod, sanés palabuhan jasa.

Contona, upami layanan ngadangukeun port 80, tapi alihan lalulintas ka port 8080 tina pods na, anjeun kudu nangtukeun persis 8080 dina kawijakan jaringan.

Mékanisme sapertos kitu kedah dianggap suboptimal: upami struktur internal jasa (palabuhan dimana pods ngadangukeun) robih, kawijakan jaringan kedah diropéa.

Pendekatan arsitéktur anyar nganggo Service Mesh (contona, tingali ngeunaan Istio di handap - kira-kira transl.) ngidinan Anjeun pikeun Cope jeung masalah ieu.

Naha perlu ngadaptar duanana Ingress sareng Egress?

Jawaban pondokna nyaéta enya, supados pod A tiasa komunikasi sareng pod B, éta kedah diidinan nyiptakeun sambungan kaluar (kanggo ieu anjeun kedah ngonpigurasikeun kawijakan egress), sareng pod B kedah tiasa nampi sambungan anu asup ( pikeun ieu, sasuai, anjeun peryogi kawijakan ingress). kawijakan).

Nanging, dina prakna, anjeun tiasa ngandelkeun kabijakan standar pikeun ngamungkinkeun sambungan dina hiji atanapi dua arah.

Lamun sababaraha pod-sumber bakal dipilih ku hiji atawa leuwih ngaléos-politisi, larangan nu ditumpukeun dina eta bakal ditangtukeun ku disjunction maranéhanana. Dina hal ieu, anjeun bakal kedah sacara eksplisit ngidinan sambungan ka pod -ka nu alamatna. Lamun pod teu dipilih ku kawijakan mana wae, lalulintas kaluar na (egress) diwenangkeun sacara standar.

Nya kitu, nasib polong téhalamatna, dipilih ku hiji atawa leuwih ingress-politikus, bakal ditangtukeun ku disjunction maranéhna. Dina hal ieu, anjeun kudu sacara eksplisit ngidinan pikeun nampa lalulintas ti pod sumber. Upami pod henteu dipilih ku kawijakan naon waé, sadaya lalu lintas asup pikeun éta diidinan sacara standar.

Tempo Stateful atanapi Stateless handap.

Log

Kabijakan jaringan Kubernetes teu tiasa log lalu lintas. Hal ieu ngajadikeun hésé nangtukeun naha kawijakan jalan sakumaha dimaksudkeun jeung greatly complicates analisis kaamanan.

Kontrol lalu lintas ka jasa éksternal

Kawijakan jaringan Kubernetes teu ngidinan Anjeun pikeun nangtukeun ngaran domain mumpuni pinuh (DNS) dina bagian kaluar. Kanyataan ieu nyababkeun kasulitan anu signifikan nalika nyobian ngawatesan lalu lintas ka tujuan éksternal anu henteu gaduh alamat IP tetep (sapertos aws.com).

Cék Kabijakan

Firewalls bakal ngingetkeun Anjeun atawa malah nolak narima kawijakan salah. Kubernetes ogé ngalakukeun sababaraha verifikasi. Nalika netepkeun kawijakan jaringan ngaliwatan kubectl, Kubernetes tiasa nyatakeun yén éta henteu leres sareng nampik nampi éta. Dina kasus anu sanés, Kubernetes bakal nyandak kawijakan sareng ngeusian éta kalayan detil anu leungit. Éta tiasa ditingali nganggo paréntah:

kubernetes get networkpolicy <policy-name> -o yaml

Émut yén sistem validasi Kubernetes henteu salah sareng tiasa sono sababaraha jinis kasalahan.

Palaksanaan

Kubernetes teu nerapkeun kawijakan jaringan sorangan, tapi ngan hiji gateway API nu delegates karya penegak burdenous kana sistem kaayaan disebut Container Networking Interface (CNI). Netepkeun kawijakan dina klaster Kubernetes tanpa nangtukeun CNI luyu sarua jeung nyieun kawijakan dina server manajemén firewall tanpa lajeng masang aranjeunna dina firewalls. Terserah anjeun pikeun mastikeun yén anjeun gaduh CNI anu santun atanapi, dina kasus platform Kubernetes, hosted dina awan. (anjeun tiasa ningali daptar panyadia di dieu - kira-kira. trans.), aktipkeun kawijakan jaringan anu bakal nyetél CNI pikeun anjeun.

Catet yén Kubernetes moal ngingetkeun anjeun upami anjeun nyetél kabijakan jaringan tanpa asisten CNI anu cocog.

Stateful atanapi Stateless?

Kabéh Kubernetes CNIs Kuring geus encountered mangrupakeun stateful (contona, Calico ngagunakeun Linux Ubuntu conntrack). Hal ieu ngamungkinkeun pod pikeun nampa réspon dina sambungan TCP eta ngagagas tanpa kudu ngadegkeun deui. Nanging, kuring henteu terang ngeunaan standar Kubernetes anu bakal ngajamin kaayaan.

Manajemén Sarat jeung Kaayaan Kaamanan Canggih

Ieu sababaraha cara pikeun ningkatkeun palaksanaan kawijakan kaamanan di Kubernetes:

Pola arsitéktur Service Mesh nganggo wadah sidecar pikeun nyayogikeun telemétri rinci sareng kontrol lalu lintas dina tingkat jasa. Salaku conto urang tiasa nyandak Istio.
Sababaraha padagang CNI parantos ngalegaan alatna pikeun ngalangkungan kawijakan jaringan Kubernetes.
Tufin Orca Nyadiakeun pisibilitas sareng otomatisasi kawijakan jaringan Kubernetes.

Paket Tufin Orca ngatur kabijakan jaringan Kubernetes (sareng sumber tina screenshot di luhur).

informasi tambahan

kacindekan

Kawijakan jaringan Kubernetes nawiskeun set alat anu saé pikeun ngabagi klaster, tapi aranjeunna henteu intuitif sareng gaduh seueur subtleties. Kusabab pajeulitna ieu, kuring yakin seueur kawijakan klaster anu aya nyaéta buggy. Solusi anu mungkin pikeun masalah ieu kalebet ngajadikeun otomatis definisi kawijakan atanapi nganggo alat segmentasi anu sanés.

Abdi ngarepkeun pituduh ieu ngabantosan ngabéréskeun sababaraha patarosan sareng ngabéréskeun masalah anu anjeun tiasa patepang.

PS ti penerjemah

Baca ogé dina blog urang:

"Balik deui ka microservices sareng Istio": bagian 1 (perkenalan kana fitur utama), bagian 2 (routing, kontrol lalulintas), bagian 3 (kaamanan);
"Panduan Gambar pikeun Jaringan di Kubernetes": bagian 1 jeung 2 (model jaringan, jaringan overlay), bagian 3 (jasa sareng pamrosésan lalu lintas);
«Docker sareng Kubernetes dina lingkungan sénsitip kaamanan";
«9 Prakték Pangalusna pikeun Kaamanan Kubernetes";
«11 Cara pikeun (Henteu) Janten Korban Hack Kubernetes".

sumber: www.habr.com

Perkenalan kana Kabijakan Jaringan Kubernetes pikeun Profesional Kaamanan