შესავალი Kubernetes ქსელის პოლიტიკაში უსაფრთხოების პროფესიონალებისთვის

Შენიშვნა. თარგმნა: სტატიის ავტორს, რეუვენ ჰარისონს, აქვს 20 წელზე მეტი გამოცდილება პროგრამული უზრუნველყოფის შემუშავებაში და დღეს არის ტუფინის CTO და თანადამფუძნებელი, კომპანია, რომელიც ქმნის უსაფრთხოების პოლიტიკის მართვის გადაწყვეტილებებს. მიუხედავად იმისა, რომ იგი განიხილავს Kubernetes ქსელის პოლიტიკას, როგორც საკმაოდ მძლავრ ინსტრუმენტს კლასტერში ქსელის სეგმენტაციისთვის, ის ასევე თვლის, რომ მათი გამოყენება არც ისე ადვილია პრაქტიკაში. ეს მასალა (საკმაოდ მოცულობითი) მიზნად ისახავს გააუმჯობესოს სპეციალისტების ცნობიერება ამ საკითხის შესახებ და დაეხმაროს მათ შექმნან საჭირო კონფიგურაციები.

დღეს ბევრი კომპანია სულ უფრო ხშირად ირჩევს Kubernetes-ს მათი აპლიკაციების გასაშვებად. ამ პროგრამული უზრუნველყოფის მიმართ ინტერესი იმდენად მაღალია, რომ ზოგიერთი კუბერნეტსს „ახალ ოპერაციულ სისტემას მონაცემთა ცენტრისთვის“ უწოდებს. თანდათანობით, Kubernetes (ან k8s) იწყებს აღქმას, როგორც ბიზნესის კრიტიკულ ნაწილად, რომელიც მოითხოვს სექსუალურ ბიზნეს პროცესების ორგანიზებას, მათ შორის ქსელის უსაფრთხოებას.

უსაფრთხოების პროფესიონალებისთვის, რომლებიც გაკვირვებულები არიან Kubernetes-თან მუშაობით, რეალური აღმოჩენა შეიძლება იყოს პლატფორმის ნაგულისხმევი პოლიტიკა: ყველაფრის დაშვება.

ეს სახელმძღვანელო დაგეხმარებათ გაიგოთ ქსელის პოლიტიკის შიდა სტრუქტურა; გაიგეთ, თუ როგორ განსხვავდებიან ისინი ჩვეულებრივი ფეიერვოლების წესებისგან. ის ასევე დაფარავს ზოგიერთ ხარვეზს და უზრუნველყოფს რეკომენდაციებს Kubernetes-ზე აპლიკაციების უსაფრთხოებაში დასახმარებლად.

Kubernetes ქსელის პოლიტიკა

Kubernetes ქსელის პოლიტიკის მექანიზმი საშუალებას გაძლევთ მართოთ პლატფორმაზე განლაგებული აპლიკაციების ურთიერთქმედება ქსელის ფენაზე (მესამე OSI მოდელში). ქსელის პოლიტიკას აკლია თანამედროვე ფეიერვოლების ზოგიერთი მოწინავე მახასიათებელი, როგორიცაა OSI Layer 7 აღსრულება და საფრთხის ამოცნობა, მაგრამ ისინი უზრუნველყოფენ ქსელის უსაფრთხოების საბაზისო დონეს, რაც კარგი საწყისი წერტილია.

ქსელის პოლიტიკა აკონტროლებს კომუნიკაციებს პოდებს შორის

Kubernetes-ში დატვირთვები ნაწილდება პოდებზე, რომლებიც შედგება ერთი ან მეტი კონტეინერისგან, რომლებიც განლაგებულია ერთად. Kubernetes თითოეულ პოდს ანიჭებს IP მისამართს, რომელიც ხელმისაწვდომია სხვა პოდებიდან. Kubernetes ქსელის პოლიტიკა ადგენს წვდომის უფლებებს პოდების ჯგუფებისთვის, ისევე, როგორც უსაფრთხოების ჯგუფები ღრუბელში გამოიყენება ვირტუალური მანქანების ინსტანციებზე წვდომის გასაკონტროლებლად.

ქსელის პოლიტიკის განსაზღვრა

Kubernetes-ის სხვა რესურსების მსგავსად, ქსელის პოლიტიკა მითითებულია YAML-ში. ქვემოთ მოცემულ მაგალითში, აპლიკაცია balance წვდომა 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

(Შენიშვნა. თარგმნა: ეს სკრინშოტი, ისევე როგორც ყველა შემდგომი მსგავსი, შეიქმნა არა მშობლიური Kubernetes ინსტრუმენტების გამოყენებით, არამედ Tufin Orca ინსტრუმენტის გამოყენებით, რომელიც შეიქმნა ორიგინალური სტატიის ავტორის კომპანიის მიერ და რომელიც ნახსენებია მასალის ბოლოს.)

საკუთარი ქსელის პოლიტიკის დასადგენად, დაგჭირდებათ YAML-ის საბაზისო ცოდნა. ეს ენა დაფუძნებულია შეწევაზე (მითითებულია ინტერვალით და არა ჩანართებით). ჩაღრმავებული ელემენტი მიეკუთვნება მის ზემოთ არსებულ უახლოეს ელემენტს. სიის ახალი ელემენტი იწყება დეფისით, ყველა სხვა ელემენტს აქვს ფორმა გასაღები-მნიშვნელობა.

YAML-ში პოლიტიკის აღწერის შემდეგ გამოიყენეთ კუბექტლიშექმნათ იგი კლასტერში:

kubectl create -f policy.yaml

ქსელის პოლიტიკის სპეციფიკაცია

Kubernetes ქსელის პოლიტიკის სპეციფიკაცია მოიცავს ოთხ ელემენტს:

1. podSelector: განსაზღვრავს პოდებს, რომლებიც გავლენას ახდენს ამ პოლიტიკაზე (მიზნები) - საჭიროა;
2. policyTypes: მიუთითებს, თუ რა ტიპის პოლიტიკა შედის მასში: შესვლა ან/და გასვლა - არჩევითია, მაგრამ გირჩევთ ყველა შემთხვევაში ცალსახად მიუთითოთ იგი;
3. ingress: განსაზღვრავს დაშვებულს შემომავალი ტრაფიკი სამიზნე პოდებში არჩევითია;
4. egress: განსაზღვრავს დაშვებულს გამავალი სამიზნე პოდებიდან ტრაფიკი არჩევითია.

მაგალითი აღებულია Kubernetes ვებსაიტიდან (მე შევცვალე role on app), გვიჩვენებს, თუ როგორ გამოიყენება ოთხივე ელემენტი:

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

გთხოვთ გაითვალისწინოთ, რომ ოთხივე ელემენტი არ უნდა იყოს ჩართული. ეს მხოლოდ სავალდებულოა podSelector, სხვა პარამეტრების გამოყენება შესაძლებელია სურვილისამებრ.

თუ გამოტოვებთ policyTypes, პოლიტიკა განიმარტება შემდეგნაირად:

• ნაგულისხმევად, ვარაუდობენ, რომ ის განსაზღვრავს შემოსვლის მხარეს. თუ პოლიტიკაში ეს ცალსახად არ არის ნათქვამი, სისტემა ჩათვლის, რომ ყველა მოძრაობა აკრძალულია.
• გასვლის მხარეს ქცევა განისაზღვრება შესაბამისი გასვლის პარამეტრის არსებობით ან არარსებობით.

შეცდომების თავიდან ასაცილებლად გირჩევთ ყოველთვის გამოხატეთ იგი policyTypes.

ზემოაღნიშნული ლოგიკის მიხედვით თუ პარამეტრები ingress და / ან egress გამოტოვებული, პოლიტიკა უარყოფს ყველა ტრაფიკს (იხ. „მოხსნის წესი“ ქვემოთ).

ნაგულისხმევი პოლიტიკა არის დაშვება

თუ პოლიტიკა არ არის განსაზღვრული, Kubernetes ნებას რთავს ყველა ტრაფიკს ნაგულისხმევად. ყველა პოდს შეუძლია თავისუფლად გაცვალოს ინფორმაცია ერთმანეთთან. ეს შეიძლება ჩანდეს წინააღმდეგობრივი უსაფრთხოების თვალსაზრისით, მაგრამ გახსოვდეთ, რომ Kubernetes თავდაპირველად შეიქმნა დეველოპერების მიერ აპლიკაციების თავსებადობის გასააქტიურებლად. ქსელის წესები მოგვიანებით დაემატა.

სახელთა სივრცეები

სახელების სივრცე არის Kubernetes თანამშრომლობის მექანიზმი. ისინი შექმნილია ლოგიკური გარემოს ერთმანეთისგან იზოლირებისთვის, ხოლო სივრცეებს ​​შორის კომუნიკაცია დაშვებულია ნაგულისხმევად.

Kubernetes-ის კომპონენტების უმეტესობის მსგავსად, ქსელის პოლიტიკა ცხოვრობს კონკრეტულ სახელთა სივრცეში. ბლოკში metadata შეგიძლიათ მიუთითოთ რომელ სივრცეს ეკუთვნის პოლიტიკა:

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

თუ სახელთა სივრცე ცალსახად არ არის მითითებული მეტამონაცემებში, სისტემა გამოიყენებს kubectl-ში მითითებულ სახელთა სივრცეს (ნაგულისხმევად namespace=default):

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

ვურჩევ მკაფიოდ მიუთითეთ სახელთა სივრცე, თუ თქვენ არ წერთ პოლიტიკას, რომელიც მიზნად ისახავს რამდენიმე სახელთა სივრცეს ერთდროულად.

ძირითადი ელემენტი podSelector პოლიტიკაში შეარჩევს პოდებს სახელთა სივრციდან, რომელსაც ეს პოლიტიკა ეკუთვნის (აკრძალულია სხვა სახელთა სივრცის პოდებზე წვდომა).

ანალოგიურად, podSelectors შეღწევისა და გასვლის ბლოკებში შეუძლია მხოლოდ პოდლების შერჩევა საკუთარი სახელების სივრციდან, თუ რა თქმა უნდა არ დააკავშირებთ მათ namespaceSelector (ეს განხილული იქნება განყოფილებაში „გაფილტვრა სახელთა სივრცის და განყოფილებების მიხედვით“).

პოლიტიკის დასახელების წესები

პოლიტიკის სახელები უნიკალურია იმავე სახელთა სივრცეში. არ შეიძლება იყოს ორი პოლიტიკის ერთი და იგივე სახელი ერთსა და იმავე სივრცეში, მაგრამ შეიძლება იყოს იგივე სახელის პოლიტიკა სხვადასხვა სივრცეში. ეს სასარგებლოა, როდესაც გსურთ იგივე პოლიტიკის ხელახლა გამოყენება მრავალ სივრცეში.

განსაკუთრებით მომწონს დასახელების ერთ-ერთი მეთოდი. იგი შედგება სახელთა სივრცის სახელის სამიზნე პოდებთან გაერთიანებისგან. Მაგალითად:

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

ეტიკეტები

თქვენ შეგიძლიათ მიამაგროთ მორგებული ეტიკეტები Kubernetes-ის ობიექტებს, როგორიცაა pods და namespaces. ეტიკეტები (ეტიკეტები - ტეგები) არის ღრუბელში არსებული ტეგების ექვივალენტი. Kubernetes ქსელის პოლიტიკა იყენებს ლეიბლებს ასარჩევად ლობიოებირომელზეც ისინი მიმართავენ:

podSelector:
  matchLabels:
    role: db

… ან სახელთა სივრცეებირომელსაც მიმართავენ. ეს მაგალითი ირჩევს სახელთა სივრცის ყველა ნაწილს შესაბამისი ეტიკეტებით:

namespaceSelector:
  matchLabels:
    project: myproject

ერთი სიფრთხილე: გამოყენებისას namespaceSelector დარწმუნდით, რომ თქვენს მიერ არჩეული სახელების სივრცე შეიცავს სწორ ეტიკეტს. გაითვალისწინეთ, რომ ჩაშენებული სახელების სივრცეები, როგორიცაა default и kube-system, ნაგულისხმევად არ შეიცავს ეტიკეტებს.

თქვენ შეგიძლიათ დაამატოთ ეტიკეტი ასეთ სივრცეში:

kubectl label namespace default namespace=default

ამავდროულად, სახელთა სივრცე განყოფილებაში metadata უნდა ეხებოდეს სივრცის რეალურ სახელს და არა ეტიკეტს:

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

წყარო და დანიშნულება

Firewall-ის პოლიტიკა შედგება წესებისგან წყაროებითა და დანიშნულებით. Kubernetes-ის ქსელის პოლიტიკა განისაზღვრება სამიზნეებისთვის - პოდების ნაკრებისთვის, რომლებზეც ისინი ვრცელდება - და შემდეგ ადგენენ წესებს შეღწევისა და/ან გასვლის ტრაფიკისთვის. ჩვენს მაგალითში, პოლიტიკის სამიზნე იქნება სახელთა სივრცეში არსებული ყველა განყოფილება default ეტიკეტით გასაღებით app და მნიშვნელობა db:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: test-network-policy
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: db   # <<<
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from:
    - ipBlock:
        cidr: 172.17.0.0/16
        except:
        - 172.17.1.0/24
    - namespaceSelector:
        matchLabels:
          project: myproject
    - podSelector:
        matchLabels:
          role: frontend
    ports:
    - protocol: TCP
      port: 6379
  egress:
  - to:
    - ipBlock:
        cidr: 10.0.0.0/24
    ports:
    - protocol: TCP
      port: 5978

ქვესექცია ingress ამ პოლიტიკაში, ხსნის შემომავალ ტრაფიკს სამიზნე პოდებში. სხვა სიტყვებით რომ ვთქვათ, შესვლა არის წყარო და სამიზნე არის შესაბამისი დანიშნულება. ანალოგიურად, გამოსვლა არის დანიშნულება და სამიზნე არის მისი წყარო.

ეს უდრის ორი firewall წესის: Ingress → Target; მიზანი → გამოსვლა.

Egress და DNS (მნიშვნელოვანია!)

გამავალი ტრაფიკის შეზღუდვით, განსაკუთრებული ყურადღება მიაქციეთ DNS-ს - Kubernetes იყენებს ამ სერვისს სერვისების IP მისამართებზე გამოსახულების მიზნით. მაგალითად, შემდეგი წესები არ იმუშავებს, რადგან თქვენ არ დაუშვით აპლიკაცია balance 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 სერვისზე წვდომის გახსნით:

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

ბოლო ელემენტი to ცარიელია და ამიტომ ირიბად ირჩევს ყველა ჯიში ყველა სახელთა სივრცეში, საშუალებას იძლევა balance გაგზავნეთ DNS მოთხოვნები შესაბამის Kubernetes სერვისში (ჩვეულებრივ, მუშაობს სივრცეში kube-system).

ეს მიდგომა მუშაობს, თუმცა ზედმეტად მისაღები და დაუცველი, რადგან ის იძლევა DNS მოთხოვნების მიმართულებას კლასტერის გარეთ.

თქვენ შეგიძლიათ გააუმჯობესოთ ის სამი თანმიმდევრული ნაბიჯით.

1. მხოლოდ DNS მოთხოვნების დაშვება ფარგლებში დაჯგუფება დამატებით 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. დაუშვით DNS მოთხოვნები მხოლოდ სახელთა სივრცეში kube-system.

ამისათვის თქვენ უნდა დაამატოთ ლეიბლი სახელთა სივრცეში kube-system: kubectl label namespace kube-system namespace=kube-system - და ჩაწერეთ პოლიტიკის გამოყენებით 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. პარანოიდ ადამიანებს შეუძლიათ კიდევ უფრო შორს წავიდნენ და შეზღუდონ DNS მოთხოვნები კონკრეტულ DNS სერვისზე kube-system. განყოფილება „გაფილტვრა სახელთა სივრცისა და განყოფილებების მიხედვით“ გეტყვით, როგორ მიაღწიოთ ამას.

კიდევ ერთი ვარიანტია DNS-ის გადაჭრა სახელთა სივრცის დონეზე. ამ შემთხვევაში, არ იქნება საჭირო თითოეული სერვისის გახსნა:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default.dns
  namespace: default
spec:
  podSelector: {} # <<<
  egress:
  - to:
    - namespaceSelector: {}
    ports:
    - protocol: UDP
      port: 53
  policyTypes:
  - Egress

ცარიელი podSelector ირჩევს სახელთა სივრცეში არსებულ ყველა პოდს.

პირველი მატჩი და წესების თანმიმდევრობა

ჩვეულებრივ ფეიერვოლებში მოქმედება (დაშვება ან უარყოფა) პაკეტზე განისაზღვრება პირველი წესით, რომელსაც იგი აკმაყოფილებს. Kubernetes-ში პოლიტიკის თანმიმდევრობას მნიშვნელობა არ აქვს.

ნაგულისხმევად, როდესაც წესები არ არის დაყენებული, პოდებს შორის კომუნიკაცია დაშვებულია და მათ შეუძლიათ თავისუფლად გაცვალონ ინფორმაცია. მას შემდეგ რაც დაიწყებთ პოლიტიკის ფორმულირებას, თითოეული პოდი, რომელიც გავლენას ახდენს მინიმუმ ერთ-ერთ მათგანზე, იზოლირებულია ყველა იმ პოლიტიკის განცალკევების (ლოგიკური OR) მიხედვით, რომლებმაც ის შეარჩიეს. პოდლები, რომლებსაც არ ეხება რაიმე პოლიტიკა, ღია რჩება.

თქვენ შეგიძლიათ შეცვალოთ ეს ქცევა მოხსნის წესის გამოყენებით.

მოხსნის წესი ("უარი")

Firewall-ის პოლიტიკა ჩვეულებრივ უარყოფს ნებისმიერ ტრაფიკს, რომელიც აშკარად არ არის დაშვებული.

კუბერნეტესში არ არსებობს უარმყოფელი მოქმედებათუმცა, მსგავსი ეფექტის მიღწევა შესაძლებელია რეგულარული (ნებადართული) პოლიტიკით, წყაროს პოდურების ცარიელი ჯგუფის არჩევით:

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

ეს პოლიტიკა ირჩევს ყველა განყოფილებას სახელთა სივრცეში და ტოვებს შემოსვლას განუსაზღვრელად, უარყოფს ყველა შემომავალ ტრაფიკს.

ანალოგიურად, შეგიძლიათ შეზღუდოთ ყველა გამავალი ტრაფიკი სახელების სივრციდან:

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

გაითვალისწინეთ, რომ ნებისმიერი დამატებითი პოლიტიკა, რომელიც საშუალებას აძლევს ტრაფიკს პოდებში სახელების სივრცეში, უპირატესობას ანიჭებს ამ წესს (მსგავსია დაშვების წესის დამატებისას, სანამ უარყოფის წესს დავუმატებთ firewall-ის კონფიგურაციას).

ყველაფრის დაშვება (Any-Any-Any-Allow)

ყველა დაშვების პოლიტიკის შესაქმნელად, თქვენ უნდა შეავსოთ ზემოთ მოყვანილი უარყოფის პოლიტიკა ცარიელი ელემენტით ingress:

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

ის იძლევა წვდომის საშუალებას ყველა pods ყველა სახელთა სივრცეში (და ყველა IP) ნებისმიერ პოდში სახელთა სივრცეში default. ეს ქცევა ჩართულია ნაგულისხმევად, ამიტომ, როგორც წესი, არ საჭიროებს შემდგომ განსაზღვრას. თუმცა, ზოგჯერ შეიძლება დაგჭირდეთ გარკვეული კონკრეტული ნებართვების დროებით გამორთვა პრობლემის დიაგნოსტიკისთვის.

წესი შეიძლება შევიწროვდეს მხოლოდ მასზე წვდომის დასაშვებად ბუშტების კონკრეტული ნაკრები (app:balance) სახელთა სივრცეში default:

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

შემდეგი პოლიტიკა საშუალებას აძლევს ყველა შემოსასვლელ და გასვლას ტრაფიკს, მათ შორის წვდომას ნებისმიერ IP-ზე კლასტერის გარეთ:

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

მრავალი პოლიტიკის შერწყმა

პოლიტიკები გაერთიანებულია ლოგიკური OR-ის გამოყენებით სამ დონეზე; თითოეული პოდის ნებართვები დაყენებულია ყველა პოლიტიკის განცალკევების შესაბამისად, რომელიც გავლენას ახდენს მასზე:

1. მინდვრებში from и to სამი ტიპის ელემენტი შეიძლება განისაზღვროს (ყველა მათგანი გაერთიანებულია OR-ის გამოყენებით):

• namespaceSelector — ირჩევს მთელ სახელთა სივრცეს;
• podSelector — ირჩევს წიპწებს;
• ipBlock — ირჩევს ქვექსელს.

უფრო მეტიც, ელემენტების რაოდენობა (თუნდაც იდენტური) ქვესექციებში from/to არ არის შეზღუდული. ყველა მათგანი გაერთიანდება ლოგიკური 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. პოლიტიკის განყოფილების შიგნით ingress შეიძლება ჰქონდეს ბევრი ელემენტი from (შერწყმულია ლოგიკური OR-ით). ანალოგიურად, განყოფილება egress შეიძლება შეიცავდეს ბევრ ელემენტს to (ასევე გაერთიანებულია დისიუნქციით):

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. სხვადასხვა პოლიტიკა ასევე შერწყმულია ლოგიკურ OR-თან

მაგრამ მათი გაერთიანებისას არსებობს ერთი შეზღუდვა აღნიშნა კრის კუნი: Kubernetes-ს შეუძლია მხოლოდ პოლიტიკის შერწყმა სხვადასხვასთან policyTypes (Ingress ან Egress). შეღწევის (ან გასვლის) განმსაზღვრელი პოლიტიკა ერთმანეთს გადაწერს.

სახელთა სივრცეებს ​​შორის ურთიერთობა

ნაგულისხმევად, ინფორმაციის გაზიარება სახელთა სივრცეებს ​​შორის დაშვებულია. ეს შეიძლება შეიცვალოს უარყოფის პოლიტიკის გამოყენებით, რომელიც შეზღუდავს გამავალი და/ან შემომავალი ტრაფიკს სახელთა სივრცეში (იხ. ზემოთ „გაშლის წესი“).

მას შემდეგ, რაც დაბლოკავთ წვდომას სახელთა სივრცეში (იხილეთ ზემოთ „მოხსნის წესი“), შეგიძლიათ დაუშვათ გამონაკლისები უარყოფის პოლიტიკაში, დაუშვით კავშირები კონკრეტული სახელების სივრციდან გამოყენებით 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

შედეგად, ყველა pods in namespace default ექნება წვდომა პოდებზე postgres სახელთა სივრცეში database. მაგრამ რა მოხდება, თუ გსურთ წვდომის გახსნა postgres სახელთა სივრცეში მხოლოდ კონკრეტული კვანძები default?

გაფილტვრა სახელთა სივრცისა და განყოფილებების მიხედვით

Kubernetes 1.11 და უფრო მაღალი ვერსია საშუალებას გაძლევთ დააკავშიროთ ოპერატორები namespaceSelector и podSelector ლოგიკური AND-ის გამოყენებით. ასე გამოიყურება:

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

რატომ არის ეს ინტერპრეტირებული როგორც AND ჩვეულებრივი OR-ის ნაცვლად?

გთხოვთ გაითვალისწინოთ, რომ podSelector დეფისით არ იწყება. YAML-ში ეს ნიშნავს იმას podSelector და მის წინ იდგა namespaceSelector მიმართეთ იმავე სიის ელემენტს. აქედან გამომდინარე, ისინი გაერთიანებულია ლოგიკურ AND-თან.

მანამდე დეფისის დამატება podSelector გამოიწვევს სიის ახალი ელემენტის გაჩენას, რომელიც გაერთიანდება წინასთან namespaceSelector ლოგიკური OR-ის გამოყენებით.

კონკრეტული ეტიკეტის მქონე ღეროების შესარჩევად ყველა სახელთა სივრცეში, შეიყვანეთ ცარიელი 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

მრავალი ლეიბლი აერთიანებს I-ს

Firewall-ის წესები მრავალი ობიექტით (ჰოსტები, ქსელები, ჯგუფები) გაერთიანებულია ლოგიკური OR-ის გამოყენებით. შემდეგი წესი იმუშავებს, თუ პაკეტის წყარო ემთხვევა Host_1 OR Host_2:

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

პირიქით, კუბერნეტებში სხვადასხვა ეტიკეტებია podSelector ან namespaceSelector შერწყმულია ლოგიკურ AND-თან. მაგალითად, შემდეგი წესი შეარჩევს პოდებს, რომლებსაც აქვთ ორივე ლეიბლი, role=db И version=v2:

podSelector:
  matchLabels:
    role: db
    version: v2

იგივე ლოგიკა ვრცელდება ყველა ტიპის ოპერატორებზე: პოლიტიკის სამიზნე სელექტორები, პოდ სელექტორები და სახელების სივრცის სელექტორები.

ქვექსელები და IP მისამართები (IPBlocks)

Firewalls იყენებს VLAN-ებს, IP მისამართებს და ქვექსელებს ქსელის სეგმენტირებისთვის.

Kubernetes-ში IP მისამართები ენიჭება პოდებს ავტომატურად და შეიძლება ხშირად შეიცვალოს, ამიტომ ლეიბლები გამოიყენება ქსელის პოლიტიკაში პოდებისა და სახელების ასარჩევად.

ქვექსელები (ipBlocks) გამოიყენება შემომავალი (შესვლა) ან გამავალი (გამოსვლა) გარე (ჩრდილოეთ-სამხრეთის) კავშირების მართვისას. მაგალითად, ეს პოლიტიკა იხსნება სახელთა სივრცის ყველა პოდისთვის default წვდომა 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

ცარიელი pod ამომრჩეველი ამ მაგალითში ნიშნავს "აირჩიე ყველა განყოფილება სახელთა სივრცეში".

ეს პოლიტიკა მხოლოდ 8.8.8.8-ზე წვდომის საშუალებას იძლევა; ნებისმიერი სხვა IP-ზე წვდომა აკრძალულია. ასე რომ, არსებითად, თქვენ დაბლოკეთ წვდომა შიდა Kubernetes DNS სერვისზე. თუ ჯერ კიდევ გსურთ მისი გახსნა, მიუთითეთ ეს პირდაპირ.

ჩვეულებრივ ipBlocks и podSelectors ურთიერთგამომრიცხავია, რადგან პოდების შიდა IP მისამართები არ გამოიყენება ipBlocks. მითითებით შიდა IP pods, თქვენ რეალურად დაუშვებთ კავშირებს ამ მისამართებით პოდებთან/დან. პრაქტიკაში, თქვენ არ გეცოდინებათ რომელი IP მისამართი გამოიყენოთ, რის გამოც ისინი არ უნდა გამოიყენოთ პოდების შესარჩევად.

როგორც საპირისპირო მაგალითი, შემდეგი პოლიტიკა მოიცავს ყველა IP-ს და, შესაბამისად, იძლევა წვდომას ყველა სხვა პოდზე:

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

თქვენ შეგიძლიათ გახსნათ წვდომა მხოლოდ გარე IP-ებზე, პოდების შიდა IP მისამართების გამოკლებით. მაგალითად, თუ თქვენი pod-ის ქვექსელი არის 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

პორტები და პროტოკოლები

როგორც წესი, pods უსმენენ ერთ პორტს. ეს ნიშნავს, რომ თქვენ უბრალოდ შეგიძლიათ არ მიუთითოთ პორტის ნომრები პოლიტიკაში და დატოვოთ ყველაფერი ნაგულისხმევად. თუმცა, რეკომენდირებულია პოლიტიკის მაქსიმალურად შემზღუდველი, ასე რომ ზოგიერთ შემთხვევაში მაინც შეგიძლიათ მიუთითოთ პორტები:

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

გაითვალისწინეთ, რომ სელექტორი ports ვრცელდება ბლოკის ყველა ელემენტზე to ან from, რომელიც შეიცავს. ელემენტების სხვადასხვა ნაკრებისთვის სხვადასხვა პორტების დასაზუსტებლად, გაყავით ingress ან egress რამდენიმე ქვესექციად ერთად to ან from და თითოეულ რეგისტრაციაში თქვენი პორტები:

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

ნაგულისხმევი პორტის ოპერაცია:

• თუ მთლიანად გამოტოვებთ პორტის განმარტებას (ports), ეს ნიშნავს ყველა პროტოკოლს და ყველა პორტს;
• თუ გამოტოვებთ პროტოკოლის განმარტებას (protocol), ეს ნიშნავს TCP;
• თუ გამოტოვებთ პორტის განმარტებას (port), ეს ნიშნავს ყველა პორტს.

საუკეთესო პრაქტიკა: ნუ დაეყრდნობით ნაგულისხმევ მნიშვნელობებს, პირდაპირ მიუთითეთ რა გჭირდებათ.

გთხოვთ, გაითვალისწინოთ, რომ თქვენ უნდა გამოიყენოთ პოდ პორტები და არა სერვისის პორტები (დაწვრილებით ამის შესახებ შემდეგ აბზაცში).

არის თუ არა განსაზღვრული წესები პოდებისთვის ან სერვისებისთვის?

როგორც წესი, Kubernetes-ის პოდები ერთმანეთზე წვდებიან სერვისის საშუალებით - ვირტუალური დატვირთვის ბალანსერი, რომელიც გადამისამართებს ტრაფიკს პოდებზე, რომლებიც ახორციელებენ სერვისს. შეიძლება ფიქრობთ, რომ ქსელის პოლიტიკა აკონტროლებს სერვისებზე წვდომას, მაგრამ ეს ასე არ არის. Kubernetes ქსელის პოლიტიკა მუშაობს პოდ პორტებზე და არა სერვისის პორტებზე.

მაგალითად, თუ სერვისი უსმენს 80-ე პორტს, მაგრამ გადამისამართებს ტრაფიკს მისი პოდების 8080-ე პორტზე, ზუსტად 8080 უნდა იყოს მითითებული ქსელის პოლიტიკაში.

ასეთი მექანიზმი უნდა ჩაითვალოს არაოპტიმალურად: თუ სერვისის შიდა სტრუქტურა (რომლის პორტები უსმენენ) შეიცვლება, ქსელის პოლიტიკა უნდა განახლდეს.

ახალი არქიტექტურული მიდგომა Service Mesh-ის გამოყენებით (მაგალითად, ისტიოს შესახებ იხილეთ ქვემოთ - დაახლ. თარგმანი.) საშუალებას გაძლევთ გაუმკლავდეთ ამ პრობლემას.

აუცილებელია თუ არა დარეგისტრირება Ingress და Egress?

მოკლე პასუხი არის დიახ, იმისათვის, რომ პოდ A-მ დაუკავშირდეს პოდ B-ს, მას უნდა მიეცეს გამავალი კავშირის შექმნის უფლება (ამისთვის საჭიროა გასვლის პოლიტიკის კონფიგურაცია), ხოლო pod B-ს უნდა შეეძლოს შემომავალი კავშირის მიღება ( ამისათვის, შესაბამისად, გჭირდებათ შემოსვლის პოლიტიკა).

თუმცა, პრაქტიკაში, შეგიძლიათ დაეყრდნოთ ნაგულისხმევ პოლიტიკას, რათა დაუშვათ კავშირები ერთი ან ორივე მიმართულებით.

თუ რომელიმე ჯიშის-წყარო შერჩეული იქნება ერთი ან მეტი გამოსვლა-პოლიტიკოსებო, მასზე დაწესებული შეზღუდვები მათი განცალკევებით განისაზღვრება. ამ შემთხვევაში, თქვენ უნდა დაუშვათ კავშირი პოდთან -ადრესატთან. თუ პოდი არ არის არჩეული რომელიმე პოლიტიკით, მისი გამავალი (გასული) ტრაფიკი ნაგულისხმევად დაშვებულია.

ანალოგიურად, ბედი არის podადრესატი, შერჩეული ერთი ან მეტის მიერ ingress-პოლიტიკოსებს მათი განხეთქილება განსაზღვრავს. ამ შემთხვევაში, თქვენ ცალსახად უნდა მისცეთ მას ტრაფიკის მიღების უფლება წყაროს პოდიდან. თუ პოდი არ არის არჩეული რომელიმე პოლიტიკის მიერ, მისთვის ყველა შემოსული ტრაფიკი ნაგულისხმევად დაშვებულია.

იხილეთ სახელმწიფო ან მოქალაქეობის არმქონე ქვემოთ.

ჟურნალები

Kubernetes ქსელის პოლიტიკას არ შეუძლია ტრაფიკის აღრიცხვა. ეს ართულებს იმის დადგენას, მუშაობს თუ არა პოლიტიკა დანიშნულებისამებრ და მნიშვნელოვნად ართულებს უსაფრთხოების ანალიზს.

გარე სერვისების ტრაფიკის კონტროლი

Kubernetes ქსელის პოლიტიკა არ გაძლევთ საშუალებას მიუთითოთ სრულად კვალიფიციური დომენის სახელი (DNS) egress სექციებში. ეს ფაქტი იწვევს მნიშვნელოვან დისკომფორტს, როდესაც ცდილობს შეზღუდოს ტრაფიკი გარე მიმართულებებზე, რომლებსაც არ აქვთ ფიქსირებული IP მისამართი (როგორიცაა aws.com).

პოლიტიკის შემოწმება

Firewalls გაგაფრთხილებთ ან თუნდაც უარს იტყვით არასწორი პოლიტიკის მიღებაზე. Kubernetes ასევე აკეთებს გადამოწმებას. Kubectl-ის საშუალებით ქსელის პოლიტიკის დაყენებისას, Kubernetes-მა შეიძლება განაცხადოს, რომ ის არასწორია და უარი თქვას მის მიღებაზე. სხვა შემთხვევაში, Kubernetes მიიღებს პოლიტიკას და შეავსებს მას დაკარგული დეტალებით. მათი ნახვა შესაძლებელია ბრძანების გამოყენებით:

kubernetes get networkpolicy <policy-name> -o yaml

გაითვალისწინეთ, რომ Kubernetes-ის ვალიდაციის სისტემა არ არის უტყუარი და შესაძლოა გამოტოვოს ზოგიერთი სახის შეცდომები.

შესრულების

Kubernetes არ ახორციელებს თავად ქსელის პოლიტიკას, მაგრამ არის მხოლოდ API კარიბჭე, რომელიც გადასცემს კონტროლის ტვირთს ფუძემდებლურ სისტემაზე, რომელსაც ეწოდება კონტეინერის ქსელის ინტერფეისი (CNI). Kubernetes-ის კლასტერზე პოლიტიკის დაყენება შესაბამისი CNI-ის მინიჭების გარეშე იგივეა, რაც პოლიტიკის შექმნა firewall-ის მენეჯმენტის სერვერზე, შემდეგ კი მათი დაინსტალირების გარეშე. თქვენზეა დამოკიდებული, უზრუნველყოთ, რომ გქონდეთ ღირსეული CNI ან, Kubernetes პლატფორმების შემთხვევაში, ღრუბელში განთავსებული. (შეგიძლიათ იხილოთ პროვაიდერების სია აქ - დაახლ. ტრანს.), ჩართეთ ქსელის პოლიტიკა, რომელიც დაგიყენებთ CNI-ს.

გაითვალისწინეთ, რომ Kubernetes არ გაგაფრთხილებთ, თუ დააყენებთ ქსელის პოლიტიკას შესაბამისი დამხმარე CNI-ის გარეშე.

სახელმწიფოებრივი თუ მოქალაქეობის არმქონე?

ყველა Kubernetes CNI, რომელიც მე შევხვდი, არის სახელმწიფო (მაგალითად, Calico იყენებს Linux conntrack-ს). ეს საშუალებას აძლევს პოდს მიიღოს პასუხები მის მიერ წამოწყებულ TCP კავშირზე მისი ხელახლა დაყენების გარეშე. თუმცა, მე არ ვიცი Kubernetes-ის სტანდარტი, რომელიც უზრუნველყოფს სახელმწიფოებრიობის გარანტიას.

უსაფრთხოების პოლიტიკის გაფართოებული მენეჯმენტი

აქ არის რამდენიმე გზა უსაფრთხოების პოლიტიკის აღსრულების გასაუმჯობესებლად Kubernetes-ში:

1. Service Mesh არქიტექტურული ნიმუში იყენებს გვერდითა კონტეინერებს, რათა უზრუნველყოს დეტალური ტელემეტრია და მოძრაობის კონტროლი მომსახურების დონეზე. მაგალითად შეგვიძლია ავიღოთ ისტიო.
2. CNI-ის ზოგიერთმა მომწოდებელმა გააფართოვა თავისი ხელსაწყოები Kubernetes-ის ქსელის პოლიტიკის მიღმა.
3. ტუფინ ორკა უზრუნველყოფს Kubernetes ქსელის პოლიტიკის ხილვადობას და ავტომატიზაციას.

Tufin Orca პაკეტი მართავს Kubernetes ქსელის პოლიტიკას (და არის ზემოთ მოცემული ეკრანის ანაბეჭდების წყარო).

დამატებითი ინფორმაცია

• აჰმეტ ალპ ბალკანის მიერ GKE-დან მომზადებული ქსელური პოლიტიკის მაგალითები;
• დოკუმენტაცია ოფიციალური Kubernetes ვებსაიტიდან;
• კუბერნეტის ქსელის მოდელის გზამკვლევი;
• სკრიპტი ქსელის პოლიტიკის შესამოწმებლად.

დასკვნა

Kubernetes ქსელის პოლიტიკა გვთავაზობს ინსტრუმენტების კარგ კომპლექტს კლასტერების სეგმენტაციისთვის, მაგრამ ისინი არ არიან ინტუიციური და აქვთ ბევრი დახვეწილობა. ამ სირთულის გამო, მე მჯერა, რომ ბევრი არსებული კლასტერული პოლიტიკა უაზროა. ამ პრობლემის შესაძლო გადაწყვეტილებები მოიცავს პოლიტიკის დეფინიციების ავტომატიზაციას ან სხვა სეგმენტაციის ინსტრუმენტების გამოყენებას.

ვიმედოვნებ, რომ ეს სახელმძღვანელო დაგეხმარებათ გარკვეული კითხვების გარკვევაში და პრობლემების მოგვარებაში, რომლებიც შეიძლება შეგხვდეთ.

PS მთარგმნელისგან

ასევე წაიკითხეთ ჩვენს ბლოგზე:

• "უბრუნდი მიკროსერვისებს Istio-სთან ერთად": ნაწილი 1 (ძირითადი მახასიათებლების შესავალი), ნაწილი 2 (მარშრუტიზაცია, მოძრაობის კონტროლი), ნაწილი 3 (უსაფრთხოება);
• "ილუსტრირებული გზამკვლევი ქსელში Kubernetes-ში": ნაწილები 1 და 2 (ქსელის მოდელი, გადაფარვის ქსელები), ნაწილი 3 (მომსახურება და ტრაფიკის დამუშავება);
• «Docker და Kubernetes უსაფრთხოებისადმი მგრძნობიარე გარემოში";
• «9 საუკეთესო პრაქტიკა Kubernetes უსაფრთხოებისთვის";
• «11 გზა, რათა (არ) გახდე კუბერნეტის ჰაკის მსხვერპლი".

წყარო: www.habr.com