🥇Təhlükəsizlik Peşəkarları üçün Kubernetes Şəbəkə Siyasətlərinə Giriş

Qeyd. tərcümə.: Məqalənin müəllifi Reuven Harrison proqram təminatının işlənib hazırlanmasında 20 ildən artıq təcrübəyə malikdir və bu gün təhlükəsizlik siyasətinin idarə edilməsi həllərini yaradan Tufin şirkətinin texniki direktoru və həmtəsisçisidir. O, Kubernetes şəbəkə siyasətlərini klasterdə şəbəkə seqmentasiyası üçün kifayət qədər güclü vasitə kimi nəzərdən keçirsə də, onların praktikada həyata keçirilməsinin o qədər də asan olmadığına inanır. Bu material (kifayət qədər həcmli) mütəxəssislərin bu məsələ ilə bağlı məlumatlılığını artırmaq və onlara lazımi konfiqurasiyaları yaratmağa kömək etmək üçün nəzərdə tutulub.

Bu gün bir çox şirkət tətbiqlərini idarə etmək üçün getdikcə daha çox Kubernetes-i seçir. Bu proqram təminatına maraq o qədər yüksəkdir ki, bəziləri Kubernetes-i “məlumat mərkəzi üçün yeni əməliyyat sistemi” adlandırırlar. Tədricən Kubernetes (və ya k8s) şəbəkə təhlükəsizliyi də daxil olmaqla, yetkin biznes proseslərinin təşkilini tələb edən biznesin kritik hissəsi kimi qəbul edilməyə başlayır.

Kubernetes ilə işləməkdən çaş-baş qalan təhlükəsizlik mütəxəssisləri üçün əsl kəşf platformanın standart siyasəti ola bilər: hər şeyə icazə verin.

Bu təlimat sizə şəbəkə siyasətlərinin daxili strukturunu anlamağa kömək edəcək; adi firewalllar üçün qaydalardan nə ilə fərqləndiyini anlayın. O, həmçinin bəzi tələləri əhatə edəcək və Kubernetes-də tətbiqlərin təhlükəsizliyini təmin etmək üçün tövsiyələr verəcək.

Kubernetes şəbəkə siyasətləri

Kubernetes şəbəkə siyasəti mexanizmi sizə şəbəkə səviyyəsində platformada yerləşdirilmiş proqramların qarşılıqlı əlaqəsini idarə etməyə imkan verir (OSI modelində üçüncü). Şəbəkə siyasətlərində OSI Layer 7 tətbiqi və təhlükənin aşkarlanması kimi müasir firewallların bəzi qabaqcıl xüsusiyyətləri yoxdur, lakin onlar yaxşı başlanğıc nöqtəsi olan şəbəkə təhlükəsizliyinin əsas səviyyəsini təmin edir.

Şəbəkə siyasətləri podlar arasında əlaqəni idarə edir

Kubernetes-də iş yükləri birlikdə yerləşdirilən bir və ya daha çox konteynerdən ibarət podlar arasında paylanır. Kubernetes hər bir poda digər podlardan əldə edilə bilən bir IP ünvanı təyin edir. Kubernetes şəbəkə siyasətləri buluddakı təhlükəsizlik qruplarının virtual maşın nümunələrinə girişi idarə etmək üçün istifadə edildiyi kimi pod qrupları üçün giriş hüquqlarını təyin edir.

Şəbəkə Siyasətlərinin Müəyyənləşdirilməsi

Digər Kubernetes resursları kimi, şəbəkə siyasətləri YAML-də müəyyən edilir. Aşağıdakı nümunədə tətbiq balance Giriş 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

(Qeyd. tərcümə.: bu ekran görüntüsü, bütün sonrakı oxşarlar kimi, yerli Kubernetes alətlərindən istifadə edilməklə deyil, orijinal məqalənin müəllifinin şirkəti tərəfindən hazırlanmış və materialın sonunda qeyd olunan Tufin Orca alətindən istifadə etməklə yaradılmışdır.)

Öz şəbəkə siyasətinizi müəyyən etmək üçün sizə YAML haqqında əsas bilik lazımdır. Bu dil girintiyə əsaslanır (tablar deyil, boşluqlarla müəyyən edilir). Girintili element yuxarıdakı ən yaxın girintili elementə aiddir. Yeni siyahı elementi tire ilə başlayır, bütün digər elementlər formaya malikdir açar-dəyər.

YAML-də siyasəti təsvir etdikdən sonra istifadə edin kubectlonu klasterdə yaratmaq üçün:

kubectl create -f policy.yaml

Şəbəkə Siyasətinin Spesifikasiyası

Kubernetes şəbəkə siyasətinin spesifikasiyası dörd elementdən ibarətdir:

podSelector: bu siyasətin təsir etdiyi podları müəyyən edir (hədəflər) - tələb olunur;
policyTypes: buna hansı siyasət növlərinin daxil edildiyini göstərir: giriş və/və ya çıxış - isteğe bağlıdır, lakin bütün hallarda bunu açıq şəkildə göstərməyi tövsiyə edirəm;
ingress: icazə verilən müəyyən edir gələn hədəf podlara trafik isteğe bağlıdır;
egress: icazə verilən müəyyən edir gedən hədəf podlardan gələn trafik isteğe bağlıdır.

Nümunə Kubernetes veb saytından götürülmüşdür (mən əvəz etdim role haqqında app), bütün dörd elementin necə istifadə edildiyini göstərir:

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

Nəzərə alın ki, bütün dörd element daxil edilməməlidir. Bu, yalnız məcburidir podSelector, digər parametrlərdən istəsəniz istifadə oluna bilər.

Əgər buraxsanız policyTypes, siyasət aşağıdakı kimi şərh ediləcək:

Varsayılan olaraq, onun giriş tərəfini müəyyən etdiyi güman edilir. Əgər siyasət bunu açıq şəkildə ifadə etmirsə, sistem bütün trafikin qadağan olunduğunu güman edəcək.
Çıxış tərəfindəki davranış müvafiq çıxış parametrinin olması və ya olmaması ilə müəyyən ediləcək.

Səhvlərin qarşısını almaq üçün tövsiyə edirəm həmişə açıq-aydın edin policyTypes.

Yuxarıdakı məntiqə görə, əgər parametrlər ingress və / və ya egress buraxılmışsa, siyasət bütün trafiki rədd edəcək (aşağıdakı "Sıxılma Qaydası"na baxın).

Defolt siyasət İcazə verin

Heç bir siyasət müəyyən edilmədikdə, Kubernetes defolt olaraq bütün trafikə icazə verir. Bütün podlar öz aralarında sərbəst məlumat mübadiləsi edə bilərlər. Bu, təhlükəsizlik baxımından ziddiyyətli görünə bilər, lakin unutmayın ki, Kubernetes əvvəlcə proqramların qarşılıqlı işləməsini təmin etmək üçün tərtibatçılar tərəfindən hazırlanmışdır. Şəbəkə siyasətləri sonradan əlavə edildi.

Ad boşluqları

Ad məkanları Kubernetes əməkdaşlıq mexanizmidir. Onlar məntiqi mühitləri bir-birindən təcrid etmək üçün nəzərdə tutulub, halbuki boşluqlar arasında əlaqə default olaraq icazə verilir.

Əksər Kubernetes komponentləri kimi şəbəkə siyasətləri də xüsusi ad məkanında yaşayır. Blokda metadata siyasətin hansı məkana aid olduğunu təyin edə bilərsiniz:

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

Əgər ad sahəsi metadatada açıq şəkildə göstərilməyibsə, sistem kubectl-də göstərilən ad sahəsindən istifadə edəcək (standart olaraq namespace=default):

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

Mən məsləhət görürəm ad sahəsini açıq şəkildə göstərin, eyni anda birdən çox ad sahəsini hədəfləyən siyasət yazmırsınızsa.

Əsas element podSelector siyasətdə siyasətin aid olduğu ad məkanından podları seçəcək (başqa ad məkanından podlara giriş qadağandır).

Eynilə, podSelectors giriş və çıxış bloklarında yalnız öz ad məkanından podları seçə bilər, əlbəttə ki, siz onları birləşdirməyincə namespaceSelector (bu, “Ad boşluqları və podlar üzrə filtrasiya” bölməsində müzakirə olunacaq).

Siyasət Adlandırma Qaydaları

Siyasət adları eyni ad məkanında unikaldır. Eyni məkanda eyni adlı iki siyasət ola bilməz, lakin fərqli məkanlarda eyni adlı siyasətlər ola bilər. Bu, eyni siyasəti bir neçə məkanda yenidən tətbiq etmək istədiyiniz zaman faydalıdır.

Adlandırma üsullarından birini xüsusilə bəyənirəm. O, ad sahəsi adını hədəf podlarla birləşdirməkdən ibarətdir. Misal üçün:

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

Etiketlər

Siz podlar və ad boşluqları kimi Kubernetes obyektlərinə fərdi etiketlər əlavə edə bilərsiniz. Etiketlər (yazıları - teqlər) buluddakı teqlərin ekvivalentidir. Kubernetes şəbəkə siyasətləri seçmək üçün etiketlərdən istifadə edir qabıqlarmüraciət etdikləri:

podSelector:
  matchLabels:
    role: db

... və ya ad boşluqlarımüraciət etdikləri. Bu nümunə ad boşluqlarındakı bütün podları müvafiq etiketlərlə seçir:

namespaceSelector:
  matchLabels:
    project: myproject

Bir xəbərdarlıq: istifadə edərkən namespaceSelector seçdiyiniz ad boşluqlarının düzgün etiketi ehtiva etdiyinə əmin olun. kimi daxili ad boşluqlarının olduğunu unutmayın default и kube-system, standart olaraq etiketləri ehtiva etmir.

Boşluğa etiket əlavə edə bilərsiniz:

kubectl label namespace default namespace=default

Eyni zamanda bölmədə ad sahəsi metadata etiketə deyil, faktiki məkan adına istinad etməlidir:

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

Mənbə və təyinat

Firewall siyasətləri mənbələr və təyinatları olan qaydalardan ibarətdir. Kubernetes şəbəkə siyasətləri bir hədəf üçün müəyyən edilir - onların tətbiq olunduğu podlar dəsti - və sonra giriş və/və ya çıxış trafiki üçün qaydalar təyin edir. Bizim nümunəmizdə siyasətin hədəfi ad məkanındakı bütün podlar olacaq default açarı olan etiketlə app və məna 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

Alt bölmə ingress bu siyasətdə, daxil olan trafiki hədəf podlara açır. Başqa sözlə, giriş mənbə, hədəf isə müvafiq təyinatdır. Eynilə, çıxış hədəf, hədəf isə onun mənbəyidir.

Bu, iki firewall qaydalarına bərabərdir: Giriş → Hədəf; Məqsəd → Çıxış.

Çıxış və DNS (vacib!)

Gedən trafiki məhdudlaşdırmaqla, DNS-ə xüsusi diqqət yetirin - Kubernetes bu xidmətdən xidmətlərin IP ünvanlarını xəritələşdirmək üçün istifadə edir. Məsələn, tətbiqə icazə vermədiyiniz üçün aşağıdakı siyasət işləməyəcək balance giriş 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

DNS xidmətinə girişi açmaqla bunu düzəldə bilərsiniz:

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

Son element to boşdur və buna görə də dolayı yolla seçir bütün ad boşluqlarında bütün podlar, imkan verir balance DNS sorğularını müvafiq Kubernetes xidmətinə göndərin (adətən boşluqda işləyir kube-system).

Bununla belə, bu yanaşma işləyir həddindən artıq icazə verən və etibarsız, çünki o, DNS sorğularını klasterdən kənara yönəltməyə imkan verir.

Siz onu üç ardıcıl addımda təkmilləşdirə bilərsiniz.

1. Yalnız DNS sorğularına icazə verin daxilində əlavə edərək klaster 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. Yalnız ad məkanında DNS sorğularına icazə verin kube-system.

Bunu etmək üçün ad sahəsinə etiket əlavə etməlisiniz kube-system: kubectl label namespace kube-system namespace=kube-system - və istifadə edərək siyasətə yazın namespaceSelector:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default.balance
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: balance
  egress:
  - to:
    - podSelector:
        matchLabels:
          app: postgres
  - to:
    - namespaceSelector:         # <<<
        matchLabels:             # <<<
          namespace: kube-system # <<<
    ports:
    - protocol: UDP
      port: 53
  policyTypes:
  - Egress

3. Paranoid insanlar daha da irəli gedə və DNS sorğularını müəyyən bir DNS xidmətinə məhdudlaşdıra bilər kube-system. “Ad boşluqlarına və podlara görə süzgəcdən keçir” bölməsi sizə buna necə nail olmağı izah edəcək.

Başqa bir seçim DNS-i ad sahəsi səviyyəsində həll etməkdir. Bu halda, onun hər bir xidmət üçün açılmasına ehtiyac olmayacaq:

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

Boş podSelector ad məkanındakı bütün podları seçir.

İlk matç və qayda qaydası

Adi firewalllarda paketdəki hərəkət (İcazə verin və ya rədd et) onun təmin etdiyi birinci qayda ilə müəyyən edilir. Kubernetesdə siyasətlərin sırası əhəmiyyət kəsb etmir.

Defolt olaraq, heç bir siyasət təyin edilmədikdə, podlar arasında əlaqəyə icazə verilir və onlar sərbəst məlumat mübadiləsi edə bilərlər. Siyasətləri formalaşdırmağa başladıqdan sonra onlardan ən azı birinin təsir etdiyi hər bir pod onu seçmiş bütün siyasətlərin ayrılmasına (məntiqi OR) uyğun olaraq təcrid olunur. Heç bir siyasətdən təsirlənməyən podlar açıq qalır.

Soyma qaydasından istifadə edərək bu davranışı dəyişə bilərsiniz.

Soyma qaydası (“Rədd et”)

Firewall siyasətləri adətən açıq şəkildə icazə verilməyən hər hansı trafiki rədd edir.

Kubernetes-də heç bir inkar hərəkəti yoxdur, lakin oxşar effekti adi (icazə verən) siyasətlə boş mənbə podları (giriş) qrupunu seçməklə əldə etmək olar:

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

Bu siyasət ad məkanındakı bütün podları seçir və girişi qeyri-müəyyən edir, bütün gələn trafiki rədd edir.

Bənzər şəkildə, ad sahəsindən bütün gedən trafiki məhdudlaşdıra bilərsiniz:

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

Xahiş edirik unutmayın ad məkanında podlara trafikə icazə verən hər hansı əlavə siyasətlər bu qaydadan üstün olacaq (firewall konfiqurasiyasında rədd etmə qaydasından əvvəl icazə qaydasının əlavə edilməsinə bənzər).

Hər şeyə icazə verin (Hər şeyə icazə verin)

Hamısına İcazə Ver siyasəti yaratmaq üçün yuxarıdakı Rədd etmə siyasətini boş elementlə tamamlamalısınız ingress:

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

-dən daxil olmaq imkanı verir bütün ad boşluqlarındakı (və bütün İP-lər) bütün podları ad məkanındakı hər hansı poda default. Bu davranış defolt olaraq aktivdir, ona görə də adətən daha çox müəyyən edilməsinə ehtiyac yoxdur. Bununla belə, bəzən problemi müəyyən etmək üçün bəzi xüsusi icazələri müvəqqəti olaraq deaktiv etməlisiniz.

Qayda yalnız daxil olmaq üçün daraldıla bilər xüsusi qabıqlar dəsti (app:balance) ad sahəsində default:

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

Aşağıdakı siyasət bütün giriş və çıxış trafikinə, o cümlədən klasterdən kənar istənilən IP-yə girişə icazə verir:

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

Çoxsaylı Siyasətlərin Birləşdirilməsi

Siyasətlər üç səviyyədə məntiqi OR istifadə edərək birləşdirilir; Hər bir podun icazələri ona təsir edən bütün siyasətlərin ayrılmasına uyğun olaraq təyin edilir:

1. Sahələrdə from и to Üç növ element müəyyən edilə bilər (hamısı OR istifadə edərək birləşdirilir):

namespaceSelector — bütün ad sahəsini seçir;
podSelector — podları seçir;
ipBlock — alt şəbəkə seçir.

Üstəlik, alt bölmələrdəki elementlərin sayı (hətta eyni olanlar). from/to məhdud deyil. Onların hamısı məntiqi OR ilə birləşdiriləcək.

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. Siyasət bölməsinin daxilində ingress çoxlu elementlərə malik ola bilər from (məntiqi OR ilə birləşdirilir). Eynilə, bölmə egress çoxlu elementləri ehtiva edə bilər to (həmçinin disjunksiya ilə birləşdirilir):

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. Müxtəlif siyasətlər də məntiqi OR ilə birləşdirilir

Ancaq onları birləşdirərkən bir məhdudiyyət var işarə etdi Chris Cooney: Kubernetes yalnız siyasətləri fərqli ilə birləşdirə bilər policyTypes (Ingress və ya Egress). Girişi (və ya çıxışı) müəyyən edən siyasətlər bir-birinin üzərinə yazılacaq.

Ad boşluqları arasındakı əlaqə

Varsayılan olaraq, ad boşluqları arasında məlumat mübadiləsinə icazə verilir. Bu, ad məkanına gedən və/yaxud daxil olan trafiki məhdudlaşdıran inkar siyasətindən istifadə etməklə dəyişdirilə bilər (yuxarıda "Sıxılma Qaydası"na baxın).

Ad sahəsinə girişi blokladıqdan sonra (yuxarıda "Sıxılma Qaydası"na baxın) istifadə edərək xüsusi ad məkanından bağlantılara icazə verməklə inkar siyasətinə istisnalar yarada bilərsiniz. 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

Nəticədə adlar sahəsindəki bütün podlar default podlara çıxış əldə edəcək postgres ad məkanında database. Ancaq girişi açmaq istəsəniz nə olacaq postgres adlar sahəsində yalnız xüsusi podlar default?

Ad boşluqlarına və podlara görə süzün

Kubernetes 1.11 və daha yüksək versiya operatorları birləşdirməyə imkan verir namespaceSelector и podSelector məntiqi AND istifadə edərək. Bu belə görünür:

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

Niyə bu adi OR əvəzinə VƏ kimi şərh olunur?

Qeyd edin ki, podSelector tire ilə başlamır. YAML-də bu o deməkdir podSelector və onun qarşısında dayanır namespaceSelector eyni siyahı elementinə istinad edin. Buna görə də onlar məntiqi AND ilə birləşirlər.

Əvvəl tire əlavə etmək podSelector əvvəlki ilə birləşdiriləcək yeni siyahı elementinin yaranması ilə nəticələnəcək namespaceSelector məntiqi OR istifadə edərək.

Müəyyən etiketi olan podları seçmək üçün bütün ad boşluqlarında, boş daxil edin 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

Birdən çox etiket I ilə birləşir

Çoxlu obyektləri (hostlar, şəbəkələr, qruplar) olan firewall qaydaları məntiqi OR istifadə edərək birləşdirilir. Paket mənbəyi uyğun gələrsə, aşağıdakı qayda işləyəcək Host_1 OR Host_2:

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

Əksinə, Kubernetes-də müxtəlif etiketlər podSelector və ya namespaceSelector məntiqi AND ilə birləşdirilir. Məsələn, aşağıdakı qayda hər iki etiketi olan podları seçəcək, role=db И version=v2:

podSelector:
  matchLabels:
    role: db
    version: v2

Eyni məntiq bütün növ operatorlara aiddir: siyasət hədəf seçiciləri, pod seçiciləri və ad sahəsi seçiciləri.

Alt şəbəkələr və IP ünvanları (IPBlocks)

Firewalllar şəbəkəni seqmentləşdirmək üçün VLAN, IP ünvanları və alt şəbəkələrdən istifadə edir.

Kubernetes-də IP ünvanları avtomatik olaraq podlara təyin edilir və tez-tez dəyişə bilər, beləliklə etiketlər şəbəkə siyasətlərində podları və ad boşluqlarını seçmək üçün istifadə olunur.

Alt şəbəkələr (ipBlocks) daxil olan (giriş) və ya çıxan (çıxış) xarici (Şimal-Cənub) əlaqələri idarə edərkən istifadə olunur. Məsələn, bu siyasət ad sahəsindən bütün podlara açılır default Google DNS xidmətinə giriş:

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

Bu nümunədəki boş pod seçicisi "adlar sahəsində bütün podları seçin" deməkdir.

Bu siyasət yalnız 8.8.8.8-ə giriş imkanı verir; hər hansı digər IP-yə giriş qadağandır. Beləliklə, əslində daxili Kubernetes DNS xidmətinə girişi blokladınız. Hələ də onu açmaq istəyirsinizsə, bunu açıq şəkildə göstərin.

Adətən ipBlocks и podSelectors podların daxili IP ünvanları istifadə edilmədiyi üçün bir-birini istisna edir ipBlocks. Göstərməklə daxili IP pods, siz faktiki olaraq bu ünvanlarla podlara/dən bağlantılara icazə verəcəksiniz. Praktikada hansı IP ünvanından istifadə edəcəyinizi bilməyəcəksiniz, buna görə də onlardan podları seçmək üçün istifadə edilməməlidir.

Əks nümunə olaraq, aşağıdakı siyasət bütün İP-ləri əhatə edir və buna görə də bütün digər podlara giriş imkanı verir:

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

Siz podların daxili IP ünvanları istisna olmaqla, yalnız xarici IP-lərə girişi aça bilərsiniz. Məsələn, podunuzun alt şəbəkəsi 10.16.0.0/14-dirsə:

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

Portlar və protokollar

Tipik olaraq, podlar bir portu dinləyir. Bu o deməkdir ki, siz sadəcə olaraq siyasətlərdə port nömrələrini göstərə və hər şeyi standart olaraq tərk edə bilməzsiniz. Bununla belə, siyasətləri mümkün qədər məhdudlaşdırmaq tövsiyə olunur, buna görə də bəzi hallarda hələ də portları təyin edə bilərsiniz:

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

Qeyd edək ki, selektor ports blokun bütün elementlərinə aiddir to və ya from, ehtiva edir. Müxtəlif element dəstləri üçün müxtəlif portları təyin etmək üçün bölün ingress və ya egress ilə bir neçə alt hissəyə bölünür to və ya from və hər birində portlarınızı qeyd edin:

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

Defolt port əməliyyatı:

Əgər port tərifini tamamilə buraxsanız (ports), bu, bütün protokollar və bütün portlar deməkdir;
Protokol tərifini buraxsanız (protocol), bu TCP deməkdir;
Əgər port tərifini buraxsanız (port), bu, bütün portlar deməkdir.

Ən yaxşı təcrübə: Defolt dəyərlərə etibar etməyin, nəyə ehtiyacınız olduğunu açıq şəkildə göstərin.

Nəzərə alın ki, siz xidmət portlarından deyil, pod portlarından istifadə etməlisiniz (bu barədə növbəti paraqrafda daha çox məlumat verin).

Siyasətlər podlar və ya xidmətlər üçün müəyyən edilibmi?

Tipik olaraq, Kubernetes-dəki podlar bir-birinə xidmət vasitəsilə daxil olur - trafiki xidməti həyata keçirən podlara yönləndirən virtual yük balanslaşdırıcısı. Şəbəkə siyasətlərinin xidmətlərə girişi idarə etdiyini düşünə bilərsiniz, lakin bu belə deyil. Kubernetes şəbəkə siyasətləri xidmət portlarında deyil, pod portlarında işləyir.

Məsələn, xidmət 80-ci portu dinləyirsə, lakin trafiki öz podlarının 8080-ci portuna yönləndirirsə, şəbəkə siyasətində tam olaraq 8080 göstərilməlidir.

Belə bir mexanizm suboptimal hesab edilməlidir: xidmətin daxili strukturu (podların dinləndiyi portlar) dəyişərsə, şəbəkə siyasətləri yenilənməli olacaq.

Service Mesh istifadə edərək yeni memarlıq yanaşması (məsələn, aşağıda Istio haqqında baxın - təqribən tərcümə.) bu problemin öhdəsindən gəlməyə imkan verir.

Həm Giriş, həm də Çıxış üçün qeydiyyatdan keçmək lazımdırmı?

Qısa cavab bəli, A podunun B bölməsi ilə əlaqə saxlaması üçün ona gedən əlaqə yaratmağa icazə verilməlidir (bunun üçün çıxış siyasətini konfiqurasiya etməlisiniz) və pod B daxil olan əlaqəni qəbul edə bilməlidir ( bunun üçün, müvafiq olaraq, sizə giriş siyasəti lazımdır).siyasəti).

Bununla belə, praktikada bir və ya hər iki istiqamətdə əlaqələrə icazə vermək üçün standart siyasətə etibar edə bilərsiniz.

Əgər bəzi pod-mənbə bir və ya bir neçə tərəfindən seçiləcək çıxış-Siyasətçilər, ona qoyulan məhdudiyyətlər onların ayrı-seçkiliyi ilə müəyyən ediləcək. Bu halda, podla əlaqəyə açıq şəkildə icazə verməli olacaqsınız -ünvan sahibinə. Pod hər hansı siyasətlə seçilməyibsə, defolt olaraq onun gedən (çıxış) trafikinə icazə verilir.

Eynilə, podun taleyi də belədirünvan sahibi, bir və ya daha çox tərəfindən seçilir giriş-siyasətçilər, onların ayrılığı ilə təyin olunacaq. Bu halda, siz onun mənbə poddan trafik almasına açıq şəkildə icazə verməlisiniz. Pod hər hansı siyasətlə seçilməyibsə, defolt olaraq onun üçün bütün giriş trafikinə icazə verilir.

Aşağıda Dövlət və ya Vətəndaşsız baxın.

Qeydlər

Kubernetes şəbəkə siyasətləri trafiki qeyd edə bilməz. Bu, siyasətin nəzərdə tutulduğu kimi işlədiyini müəyyən etməyi çətinləşdirir və təhlükəsizlik təhlilini xeyli çətinləşdirir.

Xarici xidmətlərə trafikə nəzarət

Kubernetes şəbəkə siyasətləri çıxış bölmələrində tam ixtisaslı domen adını (DNS) təyin etməyə imkan vermir. Bu fakt sabit bir IP ünvanı olmayan (məsələn, aws.com) xarici istiqamətlərə trafiki məhdudlaşdırmağa çalışarkən əhəmiyyətli narahatlığa səbəb olur.

Siyasət Yoxlanışı

Firewalllar sizi xəbərdar edəcək və ya hətta səhv siyasəti qəbul etməkdən imtina edəcək. Kubernetes də bəzi yoxlamalar aparır. kubectl vasitəsilə şəbəkə siyasəti qurarkən, Kubernetes bunun səhv olduğunu bəyan edə və onu qəbul etməkdən imtina edə bilər. Digər hallarda, Kubernetes siyasəti götürəcək və onu çatışmayan detallarla dolduracaq. Bunları əmrdən istifadə etməklə görmək olar:

kubernetes get networkpolicy <policy-name> -o yaml

Nəzərə alın ki, Kubernetes doğrulama sistemi qüsursuz deyil və bəzi xətaları qaçıra bilər.

Icra

Kubernetes şəbəkə siyasətlərini özü həyata keçirmir, sadəcə olaraq Konteyner Şəbəkə İnterfeysi (CNI) adlanan əsas sistemə nəzarət yükünü həvalə edən API şlüzdür. Müvafiq CNI təyin etmədən Kubernetes klasterində siyasətlərin təyin edilməsi, onları firewalllara quraşdırmadan təhlükəsizlik duvarı idarəetmə serverində siyasətlər yaratmaqla eynidir. Layiqli CNI-yə və ya Kubernetes platformalarına gəldikdə, buludda yerləşdiyinizə əmin olmaq sizə bağlıdır. (provayderlərin siyahısına baxa bilərsiniz burada - təqribən. trans.), sizin üçün CNI təyin edəcək şəbəkə siyasətlərini aktivləşdirin.

Nəzərə alın ki, uyğun köməkçi CNI olmadan şəbəkə siyasəti təyin etsəniz, Kubernetes sizə xəbərdarlıq etməyəcək.

Dövlətli yoxsa Vətəndaşsız?

Qarşılaşdığım bütün Kubernetes CNI-ləri vəziyyətlidir (məsələn, Calico Linux conntrack-dən istifadə edir). Bu, podun yenidən qurmadan başlatdığı TCP bağlantısı üzrə cavabları almasına imkan verir. Bununla belə, vəziyyətə zəmanət verəcək Kubernetes standartından xəbərim yoxdur.

Qabaqcıl Təhlükəsizlik Siyasətinin İdarə Edilməsi

Kubernetes-də təhlükəsizlik siyasətinin tətbiqini təkmilləşdirməyin bəzi yolları bunlardır:

Service Mesh memarlıq nümunəsi xidmət səviyyəsində ətraflı telemetriya və trafikə nəzarəti təmin etmək üçün yan vaqon konteynerlərindən istifadə edir. Nümunə olaraq götürə bilərik İstio.
Bəzi CNI satıcıları Kubernetes şəbəkə siyasətlərindən kənara çıxmaq üçün alətlərini genişləndirdilər.
Tufin Orca Kubernetes şəbəkə siyasətlərinin görünməsini və avtomatlaşdırılmasını təmin edir.

Tufin Orca paketi Kubernetes şəbəkə siyasətlərini idarə edir (və yuxarıdakı ekran görüntülərinin mənbəyidir).

Əlavə məlumat

Nəticə

Kubernetes şəbəkə siyasətləri klasterləri seqmentləşdirmək üçün yaxşı alətlər dəsti təklif edir, lakin onlar intuitiv deyil və bir çox incəliklərə malikdir. Bu mürəkkəbliyə görə, bir çox mövcud klaster siyasətinin səhv olduğuna inanıram. Bu problemin mümkün həlli yollarına siyasət təriflərinin avtomatlaşdırılması və ya digər seqmentləşdirmə alətlərinin istifadəsi daxildir.

Ümid edirəm ki, bu təlimat bəzi suallara aydınlıq gətirməyə və qarşılaşa biləcəyiniz problemləri həll etməyə kömək edəcək.

Tərcüməçidən PS

Bloqumuzda da oxuyun:

"Istio ilə mikro xidmətlərə qayıdın": 1-ci hissə (əsas xüsusiyyətlərə giriş), hissə 2 (marşrutlaşdırma, yol hərəkətinə nəzarət), 3-cü hissə (təhlükəsizlik);
"Kubernetes-də Şəbəkə üçün İllüstrasiyalı Bələdçi": hissə 1 və 2 (şəbəkə modeli, üst-üstə düşən şəbəkələr), hissə 3 (xidmətlər və trafikin işlənməsi);
«Təhlükəsizlik tələb edən mühitlərdə Docker və Kubernetes";
«9 Kubernetes Təhlükəsizlik Ən Yaxşı Təcrübələri";
«Kubernetes-də sındırılmağın 11 yolu.

Mənbə: www.habr.com

Təhlükəsizlik Peşəkarları üçün Kubernetes Şəbəkə Siyasətlərinə Giriş