Usa ka Pasiuna sa Mga Patakaran sa Kubernetes Network para sa mga Propesyonal sa Seguridad

Nota. transl.: Ang tagsulat sa artikulo - Reuven Harrison - adunay kapin sa 20 ka tuig nga kasinatian sa software development, ug karon mao ang CTO ug co-founder sa Tufin, usa ka security policy management solutions company. Samtang iyang gikonsiderar ang mga polisiya sa network sa Kubernetes nga adunay igo nga gahum aron mabahin ang network sa usa ka cluster, nagtuo usab siya nga dili kini kadali nga ipatuman sa praktis. Kini nga materyal (labi ka daghan) gituyo aron mapauswag ang kahibalo sa mga espesyalista sa kini nga butang ug tabangan sila sa paghimo sa kinahanglan nga mga pag-configure.

Karon, daghang mga kompanya ang labi nga nagpili sa mga Kubernetes nga magpadagan sa ilang mga aplikasyon. Ang interes niini nga software taas kaayo nga ang uban nagtawag sa Kubernetes nga "ang bag-ong operating system alang sa mga data center." Sa hinay-hinay, ang Kubernetes (o k8s) nagsugod nga nasabtan isip usa ka kritikal nga bahin sa negosyo, nga nagkinahanglan sa organisasyon sa mga hamtong nga proseso sa negosyo, lakip ang seguridad sa network.

Alang sa mga propesyonal sa seguridad nga nalibog sa pagtrabaho kauban ang Kubernetes, ang default nga palisiya sa kini nga plataporma mahimo’g usa ka tinuud nga pagdiskobre: ​​tugoti ang tanan.

Kini nga giya makatabang kanimo nga masabtan ang sulod nga mga buhat sa mga palisiya sa network; masabtan kung unsa sila lahi sa mga lagda alang sa regular nga mga firewall. Maghisgot usab kini bahin sa pipila ka mga lit-ag ug maghatag mga rekomendasyon nga makatabang sa pagpanalipod sa mga aplikasyon sa Kubernetes.

Mga palisiya sa network sa Kubernetes

Ang mekanismo sa polisiya sa network sa Kubernetes nagtugot kanimo sa pagdumala sa interaksyon sa mga aplikasyon nga gipakatap sa plataporma sa layer sa network (ang ikatulo sa modelo sa OSI). Ang mga polisiya sa network kulang sa pipila sa mga advanced nga bahin sa modernong mga firewall, sama sa OSI layer 7 nga kontrol ug pag-ila sa hulga, apan kini naghatag og usa ka sukaranan nga layer sa seguridad sa network nga usa ka maayong punto sa pagsugod.

Ang mga palisiya sa network nagkontrol sa komunikasyon tali sa mga pod

Ang mga workloads sa Kubernetes gipang-apud-apod sa mga pod, nga naglangkob sa usa o daghang mga sudlanan nga gi-deploy nga magkauban. Ang Kubernetes naghatag sa matag pod og IP address nga ma-access gikan sa ubang pods. Ang mga polisiya sa network sa Kubernetes nagtakda og mga permiso sa pag-access alang sa mga grupo sa mga pod sa samang paagi nga gigamit ang mga grupo sa seguridad sa cloud aron makontrol ang pag-access sa mga virtual machine nga mga instances.

Paghubit sa mga Polisiya sa Network

Sama sa ubang mga kapanguhaan sa Kubernetes, ang mga polisiya sa network gitakda sa YAML. Sa pananglitan sa ubos, ang aplikasyon balance nagbukas sa access sa 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

(Nota. transl.: kini nga screenshot, sama sa tanan nga nagsunod nga susama nga mga screenshot, wala gihimo gamit ang lumad nga Kubernetes nga mga himan, apan gamit ang Tufin Orca tool, nga gimugna sa kompanya sa tagsulat sa orihinal nga artikulo ug nga gihisgutan sa katapusan sa materyal.)

Ang sukaranan nga kahibalo sa YAML gikinahanglan aron mahibal-an ang imong kaugalingon nga palisiya sa network. Kini nga lengguwahe gibase sa indentation (gipiho sa mga espasyo, dili mga tab). Ang indented nga elemento iya sa pinakaduol nga indented nga elemento sa ibabaw niini. Ang bag-ong elemento sa lista nagsugod sa usa ka hyphen, ang tanan nga ubang mga elemento anaa sa porma yawe nga bili.

Human ihulagway ang polisiya sa YAML, gamita kubectlsa paghimo niini sa cluster:

kubectl create -f policy.yaml

Detalye sa Patakaran sa Network

Ang detalye sa polisiya sa network sa Kubernetes naglakip sa upat ka elemento:

1. podSelector: naghubit sa mga pod nga apektado niini nga polisiya (mga target) - gikinahanglan;
2. policyTypes: nagpaila kung unsa nga mga matang sa mga palisiya ang gilakip niini nga usa: pagsulod ug / o paggawas - opsyonal, apan girekomendar nako nga klaro nga ipiho kini sa tanan nga mga kaso;
3. ingress: gihubit gitugotan nagsingabot trapiko sa target pods - opsyonal;
4. egress: gihubit gitugotan mogawas Ang trapiko gikan sa mga target pod kay opsyonal.

Usa ka pananglitan nga gihulam gikan sa Kubernetes site (gipulihan nako role sa app), nagpakita kon sa unsang paagi gigamit ang tanang upat ka elemento:

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

Timan-i nga dili kinahanglan nga ilakip ang tanan nga upat ka mga elemento. Gikinahanglan lamang kini podSelector, ang nahabilin nga mga parametro mahimong magamit kung gusto.

Kung atong laktawan policyTypes, ang polisiya pagahubadon ingon sa mosunod:

• Gituohan nga default ang paghubit sa bahin sa pagsulod. Kung ang palisiya dili klaro nga nagpakita niini, ang sistema maghunahuna nga ang tanan nga trapiko gidili.
• Ang kinaiya sa egress nga bahin matino pinaagi sa presensya o pagkawala sa katugbang nga egress parameter.

Aron malikayan ang mga sayup, girekomenda ko kanunay nga klaro policyTypes.

Sumala sa lohika sa ibabaw, kung ang mga parameter ingress ug / o egress wala iapil, ang polisiya maglimud sa tanang trapiko (tan-awa ang "Sweep Rule" sa ubos).

Default nga palisiya - pagtugot

Kung walay mga palisiya nga gihubit, gitugotan sa Kubernetes ang tanan nga trapiko pinaagi sa default. Ang tanan nga mga pod mahimong gawasnon nga magbayloay og impormasyon sa usag usa. Gikan sa usa ka punto sa seguridad, kini ingon og counterintuitive, apan hinumdomi nga ang Kubernetes orihinal nga gimugna sa mga developers nga adunay tumong sa paghimo sa mga aplikasyon nga interoperable. Ang mga polisiya sa network gidugang sa ulahi.

Mga namespace

Ang mga namespace mao ang mekanismo sa kolaborasyon sa Kubernetes. Gidisenyo kini aron ihimulag ang lohikal nga mga palibot gikan sa usag usa, samtang gitugotan ang komunikasyon tali sa mga wanang pinaagi sa default.

Sama sa kadaghanan sa mga sangkap sa Kubernetes, ang mga palisiya sa network nagpuyo sa usa ka piho nga namespace. Sa block metadata mahimo nimong ipiho kung asa nga luna ang polisiya iya sa:

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

Kung ang namespace dili klaro nga gipiho sa metadata, ang sistema mogamit sa namespace nga gipiho sa kubectl (default namespace=default):

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

Gisugyot ko ipiho ang namespace nga klaro, gawas kung nagsulat ka usa ka palisiya nga nagpunting sa daghang mga namespace sa usa ka higayon.

Main elemento podSelector sa polisiya magpili og mga pod gikan sa namespace diin ang polisiya nahisakop (kini walay access sa pods gikan sa laing namespace).

Sa susama, podSelectors sa ingress ug egress blocks makapili ra pod ug mga pod gikan sa ilang kaugalingong namespace, gawas kung, siyempre, imong isagol sila namespaceSelector (Kini pagahisgutan sa seksyon nga "Pagsala pinaagi sa mga namespace ug pod").

Mga Lagda sa Pagngalan sa Polisiya

Ang mga ngalan sa polisiya talagsaon sulod sa samang namespace. Dili mahimo nga duha ka mga polisiya nga adunay parehas nga ngalan sa parehas nga wanang, apan adunay mga palisiya nga parehas nga ngalan sa lainlaing mga wanang. Mapuslanon kini kung gusto nimo i-apply pag-usab ang parehas nga palisiya sa daghang mga wanang.

Ganahan ko sa usa sa mga paagi sa pagngalan. Naglangkob kini sa paghiusa sa ngalan sa namespace sa mga target nga pod. Pananglitan:

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

Mga label

Ang mga custom nga label mahimong i-attach sa mga butang sa Kubernetes sama sa mga pod ug namespaces. Mga label (mga label tag) mao ang katumbas sa mga tag sa panganod. Ang mga polisiya sa network sa Kubernetes naggamit ug mga label aron makapili mga poddiin sila magamit:

podSelector:
  matchLabels:
    role: db

… o mga namespacediin ilang gipadapat. Kini nga pananglitan nagpili sa tanan nga mga pod sa mga namespace nga adunay parehas nga mga label:

namespaceSelector:
  matchLabels:
    project: myproject

Usa ka caveat: kung gamiton namespaceSelector siguruha nga ang mga namespace nga imong gipili adunay husto nga label. Hibaloi nga ang mga built-in nga namespaces sama sa default и kube-system, wala maglangkob sa mga label nga default.

Mahimo nimong idugang ang usa ka label sa usa ka luna nga sama niini:

kubectl label namespace default namespace=default

Sa kini nga kaso, ang namespace sa seksyon metadata kinahanglan magtumong sa aktuwal nga ngalan sa luna, dili ang label:

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

Tinubdan ug Destinasyon

Ang mga palisiya sa firewall naglangkob sa mga lagda sa gigikanan ug destinasyon. Ang mga polisiya sa network sa Kubernetes gihubit matag target, ang set sa mga pod nga ilang magamit, ug dayon nagtakda og mga lagda alang sa pagsulod ug/o paggawas sa trapiko. Sa among pananglitan, ang target sa palisiya mao ang tanan nga mga pod sa namespace default nga adunay key label app ug kahulogan 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

Subseksiyon ingress sa kini nga palisiya nagbukas sa umaabot nga trapiko sa mga target pod. Sa ato pa, ang pagsulod mao ang gigikanan ug ang target mao ang katugbang nga destinasyon. Sa susama, ang egress mao ang destinasyon, ug ang target mao ang tinubdan niini.

Katumbas kini sa duha ka lagda sa firewall: Ingress → Target; Target → Paggawas.

Egress ug DNS (importante!)

Pagpugong sa paggawas sa trapiko paghatag ug espesyal nga pagtagad sa DNS - Gigamit sa Kubernetes kini nga serbisyo aron mapa ang mga serbisyo sa mga adres sa IP. Pananglitan, ang mosunod nga palisiya dili molihok tungod kay wala nimo gitugotan ang aplikasyon balance access sa 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

Mahimo nimo kini ayohon pinaagi sa pag-abli sa pag-access sa serbisyo sa 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

Katapusan nga elemento to walay sulod, ug busa kini dili direkta nga nagpili tanan pod sa tanang namespaces, pagtugot balance ipadala ang mga pangutana sa DNS sa angay nga serbisyo sa Kubernetes (kasagaran kini nagdagan sa kawanangan kube-system).

Kini nga pamaagi molihok, bisan pa sobra ka permissive ug insecure, tungod kay kini nagtugot kanimo sa pagdirekta sa DNS nga mga pangutana sa gawas sa cluster.

Mahimo nimo kini pauswagon sa tulo ka sunod-sunod nga mga lakang.

1. Tugoti ang mga pangutana sa DNS lamang sa sulod cluster pinaagi sa pagdugang 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. Tugoti ang mga pangutana sa DNS sa namespace lamang kube-system.

Aron mahimo kini, kinahanglan nimo nga idugang ang usa ka label sa namespace kube-system: kubectl label namespace kube-system namespace=kube-system - ug irehistro kini sa polisiya gamit 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. Ang mga paranoid mahimong mopadayon ug mopugong sa mga hangyo sa DNS sa usa ka piho nga serbisyo sa DNS sa kube-system. Ang seksyon nga "Pagsala pinaagi sa Namespaces AND Pods" magpakita kanimo kung giunsa kini makab-ot.

Ang laing kapilian mao ang pagsulbad sa DNS sa lebel sa namespace. Sa kini nga kaso, dili kinahanglan nga ablihan alang sa matag serbisyo:

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

Bakante podSelector mopili sa tanang pod sa namespace.

Unang duwa ug han-ay sa lagda

Sa naandan nga mga firewall, ang aksyon (Allow o Deny) sa usa ka pakete gitino sa una nga lagda nga natagbaw niini. Sa Kubernetes, ang han-ay sa mga palisiya dili igsapayan.

Sa kasagaran, kung walay mga polisiya nga gitakda, ang komunikasyon tali sa mga pod gitugutan ug sila mahimong magbayloay og impormasyon nga gawasnon. Sa diha nga magsugod ka sa paghimo og mga palisiya, ang matag pod nga apektado sa labing menos usa niini mahimong isolated sumala sa disjunction (lohikal O) sa tanan nga mga palisiya nga nagpili niini. Ang mga pod nga wala maapektuhan sa bisan unsang polisiya nagpabiling bukas.

Mahimo nimong usbon kini nga pamatasan gamit ang usa ka lagda sa pagsilhig.

Lagda sa Paglimpyo ("Gidili")

Ang mga polisiya sa firewall kasagarang naglimud sa bisan unsang trapiko nga dili tin-aw nga gitugot.

Ang Kubernetes walay "pagdumili" nga aksyon, apan ang parehas nga epekto mahimong makab-ot sa usa ka normal (permissive) nga palisiya pinaagi sa pagpili sa usa ka walay sulod nga grupo sa mga source pods (ingress):

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

Gipili sa kini nga polisiya ang tanan nga mga pod sa namespace ug gibiyaan ang pagsulod nga wala mahibal-an, nga naglimud sa tanan nga umaabot nga trapiko.

Sa susama, mahimo nimong pugngan ang tanan nga mogawas nga trapiko gikan sa namespace:

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

Palihug hinumdumi kana Ang bisan unsang dugang nga mga palisiya nga nagtugot sa trapiko sa mga pod sa namespace mag-una niini nga lagda (parehas sa pagdugang sa pagtugot nga lagda sa dili pa ang usa ka pagdumili nga lagda sa pagsumpo sa firewall).

Tugoti ang tanan (Bisan-Bisan-Bisan-Bisan-Allow)

Para makahimo ug "Allow All" nga polisiya, kinahanglan nimo nga dugangan ang naa sa ibabaw nga deny policy gamit ang walay sulod nga elemento ingress:

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

Naghatag kini og access sa tanang pod sa tanang namespaces (ug tanang IP) sa bisag unsa pod sa namespace default. Kini nga kinaiya gipalihok pinaagi sa default, mao nga kasagaran dili na kinahanglan nga ipasabut pa. Bisan pa, usahay kinahanglan nga temporaryo nga i-disable ang piho nga mga pagtugot aron masusi ang problema.

Ang lagda mahimong pig-ot aron tugutan lamang ang pag-access usa ka piho nga hugpong sa mga pod (app:balance) sa 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

Ang mosunod nga polisiya nagtugot sa tanang umaabot nga (ingress) UG outgoing (egress) nga trapiko, lakip ang access sa bisan unsang IP gawas sa cluster:

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

Paghiusa sa Daghang Patakaran

Ang mga palisiya lohikal nga gi-OR sa tulo ka lebel; Ang matag permiso sa pod gitakda sumala sa disjunction sa tanang polisiya nga makaapekto niini:

1. Sa kaumahan from и to tulo ka matang sa mga elemento ang mahimong ipasabut (tanan gihiusa sa OR):

• namespaceSelector - gipili ang tibuok namespace;
• podSelector - nagpili sa mga pod;
• ipBlock - nagpili ug subnet.

Sa parehas nga oras, ang gidaghanon sa mga elemento (bisan ang parehas nga mga) sa mga subsection from/to dili limitado. Ang tanan niini ikombinar sa usa ka lohikal nga 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. Sulod sa seksyon sa palisiya ingress mahimong adunay daghang mga elemento from (gihiusa sa lohikal nga OR). Sa susama, seksyon egress mahimong maglakip sa daghang mga elemento to (gihiusa usab sa 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. Ang lain-laing mga palisiya gihiusa usab sa usa ka lohikal nga O

Apan kung kini gihiusa, adunay usa ka pagdili gitudlo Chris Cooney: Ang mga Kubernetes mahimo ra nga maghiusa sa mga palisiya sa lainlain policyTypes (Ingress o Egress). Ang mga palisiya nga naghubit sa ingress (o egress) mag-overwrite sa usag usa.

Relasyon tali sa mga namespace

Sa kasagaran, ang pagbayloay sa impormasyon tali sa mga namespaces gitugotan. Mahimo kining usbon sa usa ka higpit nga palisiya nga nagpugong sa paggawas ug/o umaabot nga trapiko sa namespace (tan-awa ang "Sweep Rule" sa ibabaw).

Pinaagi sa pag-ali sa pag-access sa usa ka namespace (tan-awa ang "Sweep Rule" sa ibabaw), mahimo ka nga maghimo mga eksepsiyon sa palisiya sa pagdumili pinaagi sa pagtugot sa mga koneksyon gikan sa usa ka piho nga namespace nga adunay 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

Ingon usa ka sangputanan, ang tanan nga mga pod sa namespace default makakuha og access sa mga pod postgres sa namespace database. Apan unsa man kung gusto nimo nga ablihan ang pag-access postgres espesipiko lang nga mga pod sa namespace default?

Pagsala pinaagi sa mga namespace ug pod

Ang Kubernetes nga bersyon 1.11 ug pataas nagtugot kanimo sa paghiusa sa mga operator namespaceSelector и podSelector gamit ang lohikal nga AND. Kini tan-awon:

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

Ngano nga kini gihubad nga AND imbes sa naandan nga O?

timan-i nga podSelector wala magsugod sa hyphen. Sa YAML kini nagpasabot nga podSelector ug nagbarog sa iyang atubangan namespaceSelector tan-awa ang parehas nga elemento sa lista. Busa, sila gihiusa sa usa ka lohikal nga AND.

Pagdugang og dash kaniadto podSelector moresulta sa usa ka bag-ong elemento sa lista nga ikombinar sa nauna namespaceSelector gamit ang lohikal nga OR.

Aron mapili ang mga pod nga adunay piho nga label sa tanang namespaces, sulod nga walay sulod 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

Daghang mga label ang gisagol sa AND

Ang mga lagda sa firewall nga adunay daghang mga entidad (mga host, network, grupo) gihiusa gamit ang usa ka lohikal nga O. Ang mosunud nga lagda mobuto kung ang gigikanan sa pakete magkatugma Host_1 O Host_2:

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

Sa kasukwahi, sa Kubernetes lain-laing mga label sa podSelector o namespaceSelector gikombinar sa usa ka lohikal nga AND. Pananglitan, ang mosunod nga lagda mopili sa mga pod nga adunay duha ka label, role=db И version=v2:

podSelector:
  matchLabels:
    role: db
    version: v2

Ang sama nga lohika magamit sa tanang matang sa mga pahayag: mga tigpili sa target sa palisiya, mga tigpili sa pod, ug mga tigpili sa namespace.

Mga subnet ug IP address (IPBlocks)

Ang mga firewall naggamit sa mga VLAN, IP address, ug mga subnet aron mabahin ang usa ka network.

Sa Kubernetes, ang mga IP address awtomatik nga i-assign sa mga pod ug mahimong mausab kanunay, mao nga ang mga label gigamit sa pagpili sa mga pod ug namespace sa mga polisiya sa network.

Mga subnet (ipBlocks) gigamit sa pagdumala sa umaabot (ingress) o outgoing (egress) external (North-South) nga mga koneksyon. Pananglitan, kini nga palisiya nagbukas sa tanan nga mga pod gikan sa namespace default access sa serbisyo sa 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

Ang walay sulod nga pod selector niini nga pananglitan nagpasabot nga "pilia ang tanang pod sa namespace".

Kini nga polisiya nagtugot lamang sa pag-access sa 8.8.8.8; ang pag-access sa bisan unsang ubang IP gidili. Busa, sa esensya, gibabagan nimo ang pag-access sa internal nga serbisyo sa DNS nga Kubernetes. Kung gusto pa nimo nga ablihan kini, ipiho kini nga klaro.

kasagaran ipBlocks и podSelectors managsama nga eksklusibo, tungod kay ang mga internal nga IP adres sa mga pod wala gigamit ipBlocks. Nagtudlo internal nga IP pods, tugotan gyud nimo ang mga koneksyon sa/gikan sa mga pod nga adunay mga adres. Sa praktis, dili nimo mahibal-an kung unsang IP address ang gamiton, mao nga dili nimo kini gamiton sa pagpili sa mga pod.

Isip usa ka counter example, ang mosunod nga polisiya naglakip sa tanang IPs ug busa nagtugot sa access sa tanang ubang pods:

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

Mahimo nimong ablihan ang pag-access sa mga eksternal nga IP, dili apil ang mga internal nga IP adres sa mga pod. Pananglitan, kung ang subnet sa imong pod kay 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

Mga pantalan ug mga Protokol

Kasagaran pod maminaw sa usa ka port. Kini nagpasabot nga mahimo nimong biyaan ang mga numero sa port sa imong mga polisiya ug ibilin ang tanan isip default. Bisan pa, girekomenda nga maghimo mga polisiya nga ingon ka mapig-oton kutob sa mahimo, mao nga sa pipila ka mga kaso mahimo nimong ipiho ang mga pantalan:

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

Timan-i nga ang tigpili ports magamit sa tanang elemento sa block to o from, nga naglangkob sa. Aron ipiho ang lain-laing mga pantalan alang sa lain-laing mga butang set, break ingress o egress ngadto sa pipila ka mga sub-section to o from ug sa matag usa isulat ang imong mga pantalan:

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

Default nga mga pantalan nagtrabaho:

• Kung imong gitangtang ang kahulugan sa mga pantalan sa hingpit (ports), nga nagpasabot sa tanang protocol ug tanang pantalan;
• Kung imong laktawan ang kahulugan sa protocol (protocol), nga nagpasabot TCP;
• Kung imong laktawan ang kahulugan sa pantalan (port), nga nagpasabut sa tanan nga mga pantalan.

Labing Maayong Practice: Ayaw pagsalig sa mga default nga kantidad, ipiho kung unsa ang imong kinahanglan nga klaro.

Timan-i nga kinahanglan nimong gamiton ang mga pod port, dili mga serbisyo (labi pa bahin niini sa sunod nga parapo).

Mga palisiya nga gihubit alang sa mga pod o serbisyo?

Kasagaran, ang mga pod sa Kubernetes nakigsulti sa usag usa pinaagi sa usa ka serbisyo - usa ka virtual load balancer nga nag-redirect sa trapiko sa mga pod nga nagpatuman sa serbisyo. Mahimong maghunahuna ka nga ang mga palisiya sa network nagkontrol sa pag-access sa mga serbisyo, apan dili kana ang kahimtang. Ang mga palisiya sa network sa Kubernetes nagtrabaho sa mga pod port, dili mga serbisyo.

Pananglitan, kung ang usa ka serbisyo maminaw sa port 80, apan mag-redirect sa trapiko sa port 8080 sa mga pod niini, kinahanglan nimong ipiho ang 8080 sa polisiya sa network.

Ang ingon nga mekanismo kinahanglan nga ilhon nga suboptimal: kung ang internal nga aparato sa serbisyo (ang mga pantalan nga naminaw sa mga pods) magbag-o, ang mga palisiya sa network kinahanglan nga i-update.

Bag-ong pamaagi sa arkitektura gamit ang Service Mesh (pananglitan, tan-awa ang bahin sa Istio sa ubos - gibanabana nga transl.) nagtugot kanimo sa pag-atubang niini nga problema.

Kinahanglan ba nga isulat ang Ingress ug Egress?

Ang mubo nga tubag mao ang oo, aron ang pod A makigkomunikar sa pod B, kinahanglan nimo nga tugutan kini nga maghimo usa ka outgoing connection (alang niini kinahanglan nimo nga i-configure ang egress policy), ug ang pod B kinahanglan nga makadawat sa umaabot nga koneksyon. (alang niini, sumala niana, kinahanglan nimo ang ingress- polisiya).

Bisan pa, sa praktis, makasalig ka sa default nga palisiya aron tugutan ang mga koneksyon sa usa o pareho nga direksyon.

Kung pipila ka pod-tinubdan pilion sa usa o daghan pa mogawas-mga politiko, ang mga pagdili nga gipahamtang niini matino pinaagi sa ilang disjunction. Sa kini nga kaso, kinahanglan nimo nga klaro nga tugutan ang koneksyon sa podaddressee. Kung ang usa ka pod wala mapili sa bisan unsang polisiya, ang mogawas (paggawas) nga trapiko kay gitugotan sa default.

Sa susama, ang kapalaran sa pod'a-addresseegipili sa usa o daghan pa ingress-Ang mga polisiya matino pinaagi sa ilang disjunction. Sa kini nga kaso, kinahanglan nimo nga klaro nga tugutan kini nga makadawat og trapiko gikan sa gigikanan nga pod. Kung ang usa ka pod wala mapili sa bisan unsang polisiya, ang tanan nga pagsulod sa trapiko niini gitugutan sa default.

Tan-awa ang "Stateful o Stateless" sa ubos.

Mga troso

Ang mga palisiya sa network sa Kubernetes wala mahibal-an kung giunsa ang pag-log sa trapiko. Kini nagpalisud sa pagtino kung ang usa ka palisiya nagtrabaho sama sa gipaabut ug naghimo sa pagtuki sa seguridad nga lisud kaayo.

Pagkontrol sa trapiko sa mga serbisyo sa gawas

Ang mga polisiya sa network sa Kubernetes wala magtugot kanimo sa pagpiho sa usa ka hingpit nga kwalipikado nga ngalan sa domain (DNS) sa mga seksyon sa paggawas. Kini nga kamatuoran mosangpot sa usa ka mahinungdanon nga kahasol sa pagsulay sa pagpugong sa trapiko ngadto sa gawas nga mga destinasyon nga walay piho nga IP address (sama sa aws.com).

Pagsusi sa Polisiya

Ang mga firewall mopahimangno kanimo o bisan magdumili sa pagdawat sa usa ka sayup nga palisiya. Ang Kubernetes naghimo usab og pipila ka pag-verify. Kung nagbutang ug polisiya sa network pinaagi sa kubectl, ang mga Kubernetes mahimong modeklarar nga ang polisiya dili husto ug magdumili sa pagdawat niini. Sa ubang mga kaso, kuhaon sa Kubernetes ang polisiya ug pun-on kini sa nawala nga mga detalye. Imong makita sila sa sugo:

kubernetes get networkpolicy <policy-name> -o yaml

Hinumdomi nga ang sistema sa validation sa Kubernetes dili masayop ug mahimong masipyat sa pipila ka matang sa mga sayop.

Pagpatay

Ang Kubernetes wala magpatuman sa mga polisiya sa network sa iyang kaugalingon, apan usa lamang ka agianan sa API nga nagbutang sa palas-anon sa pagkontrol sa usa ka nagpahiping sistema nga gitawag og Container Networking Interface (CNI). Ang pagtakda og mga polisiya sa usa ka Kubernetes cluster nga walay pag-assign sa usa ka angay nga CNI susama sa pagtakda sa mga polisiya sa usa ka firewall management server nga walay sunod-sunod nga pagbutang niini sa mga firewall. Anaa kanimo ang pagsiguro nga ikaw adunay usa ka disente nga CNI o, sa kaso sa mga platform sa Kubernetes, gi-host sa panganod (Alang sa listahan sa mga providers tan-awa dinhi - gibanabana. trans.), i-enable ang mga polisiya sa network nga magtakda sa CNI alang kanimo.

Timan-i nga ang Kubernetes dili mopahimangno kanimo kung magtakda ka og polisiya sa network nga wala ang angay nga katabang nga CNI.

Stateful o Stateless?

Ang tanan nga Kubernetes CNIs nga akong nakit-an kay stateful (pananglitan, ang Calico naggamit sa Linux conntrack). Gitugotan niini ang pod nga makadawat mga tubag sa koneksyon sa TCP nga gisugdan niini nga dili kinahanglan nga i-establisar kini pag-usab. Bisan pa, wala ako nahibal-an sa usa ka sumbanan sa Kubernetes nga makagarantiya sa pagka-estado.

Advanced Security Policy Management

Ania ang pipila ka mga paagi aron mapauswag ang kahusayan sa pagpatuman sa palisiya sa seguridad sa Kubernetes:

1. Ang sumbanan sa arkitektura sa Service Mesh naggamit sa mga sidecar aron mahatagan ang detalyado nga telemetry ug pagkontrol sa trapiko sa lebel sa serbisyo. Ingon usa ka pananglitan, mahimo’g makuha sa usa Istio.
2. Ang pipila sa mga tigbaligya sa CNI nagpalapad sa ilang mga himan aron molapas sa mga palisiya sa network sa Kubernetes.
3. Tufin Orca naghatag ug transparency ug automation sa mga polisiya sa network sa Kubernetes.

Ang pakete sa Tufin Orca nagdumala sa mga palisiya sa network sa Kubernetes (ug mao ang gigikanan sa mga screenshot sa ibabaw).

dugang nga impormasyon

• Mga pananglitan sa polisiya sa network nga giandam ni Ahmet Alp Balkan sa GKE;
• Dokumentasyon gikan sa opisyal nga website sa Kubernetes;
• Giya sa modelo sa network sa Kubernetes;
• Script alang sa pagsusi sa mga polisiya sa network.

konklusyon

Ang mga palisiya sa network sa Kubernetes nagtanyag usa ka maayong set sa mga himan alang sa pagbahin sa mga cluster, apan dili kini intuitive ug adunay daghang mga subtlety. Nagtuo ko nga tungod niini nga pagkakomplikado, ang mga palisiya sa daghang mga naglungtad nga mga pungpong buggy. Ang posible nga mga solusyon sa kini nga problema mao ang pag-automate sa mga kahulugan sa palisiya o paggamit sa ubang mga himan sa pagbahin.

Nanghinaut ko nga kini nga giya makatabang sa paghawan sa pipila ka mga pangutana ug pagsulbad sa mga problema nga imong masugatan.

PS gikan sa tighubad

Basaha usab sa among blog:

• "Balik sa microservices uban sa Istio": bahin 1 (pagpaila sa mga nag-unang bahin), bahin 2 (ruta, pagkontrol sa trapiko), bahin 3 (seguridad);
• "Usa ka Gihulagway nga Giya sa Networking sa Kubernetes": bahin 1 ug 2 (modelo sa network, mga overlay nga network), bahin 3 (mga serbisyo ug pagproseso sa trapiko);
• «Docker ug Kubernetes sa mga palibot nga nangayo sa seguridad";
• «9 Kubernetes Security Best Practices";
• «11 Mga Paagi aron (Dili) Ma-hack sa Kubernetes".

Source: www.habr.com