🥇Қауіпсіздік мамандарына арналған Kubernetes желілік саясатына кіріспе

Ескерту. аударма: Мақала авторы - Реувен Харрисон - бағдарламалық жасақтаманы әзірлеуде 20 жылдан астам тәжірибесі бар және бүгінде қауіпсіздік саясатын басқару шешімдерімен айналысатын Tufin компаниясының CTO және тең құрылтайшысы. Ол Kubernetes желілік саясатын желіні кластерге бөлуге жеткілікті күшті деп санайды, сонымен қатар оларды іс жүзінде жүзеге асыру оңай емес деп санайды. Бұл материал (өте көлемді) мамандардың осы мәселе бойынша хабардарлығын арттыруға және оларға қажетті конфигурацияларды жасауға көмектесуге арналған.

Бүгінгі таңда көптеген компаниялар өздерінің қосымшаларын іске қосу үшін Kubernetes-ті көбірек таңдайды. Бұл бағдарламалық жасақтамаға қызығушылықтың жоғары болғаны сонша, кейбіреулер Kubernetes-ті «деректер орталықтарына арналған жаңа операциялық жүйе» деп атайды. Біртіндеп Kubernetes (немесе k8s) жетілген бизнес-процестерді, соның ішінде желілік қауіпсіздікті ұйымдастыруды талап ететін бизнестің маңызды бөлігі ретінде қабылдана бастады.

Kubernetes-пен жұмыс істеу арқылы бас қатырған қауіпсіздік мамандары үшін бұл платформаның әдепкі саясаты нағыз жаңалық болуы мүмкін: бәріне рұқсат етіңіз.

Бұл нұсқаулық желі саясатының ішкі жұмысын түсінуге көмектеседі; олардың кәдімгі брандмауэрлердің ережелерінен айырмашылығын түсініңіз. Ол сондай-ақ кейбір қателіктер туралы айтып, Kubernetes қолданбаларын қорғауға көмектесетін ұсыныстар береді.

Kubernetes желілік саясаттары

Kubernetes желілік саясат механизмі желі деңгейінде платформада орналастырылған қолданбалардың өзара әрекеттесуін басқаруға мүмкіндік береді (OSI үлгісінде үшінші). Желілік саясаттарда OSI 7 деңгейін басқару және қауіптерді анықтау сияқты заманауи брандмауэрлердің кейбір кеңейтілген мүмкіндіктері жоқ, бірақ олар жақсы бастапқы нүкте болып табылатын желі қауіпсіздігінің негізгі деңгейін қамтамасыз етеді.

Желі саясаттары қосқыштар арасындағы байланысты басқарады

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 желі саясатының сипаттамасы төрт элементті қамтиды:

podSelector: осы саясат әсер ететін подкасттарды анықтайды (мақсаттар) - қажет;
policyTypes: осы саясаттың қандай түрлері қамтылғанын көрсетеді: кіру және/немесе шығу - міндетті емес, бірақ мен оны барлық жағдайларда нақты көрсетуді ұсынамын;
ingress: рұқсат етілгенін анықтайды кіріс мақсатты қосқыштарға трафик - міндетті емес;
egress: рұқсат етілгенін анықтайды шығыс мақсатты қосқыштардан келетін трафик міндетті емес.

Kubernetes сайтынан алынған мысал (мен ауыстырдым role туралы 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 нысандарына тіркеуге болады. Жапсырмалар (жапсырмалар тегтер) бұлттағы тегтердің баламасы болып табылады. 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:
...

Дереккөз және тағайындау

Брандмауэр саясаттары бастапқы және тағайындау ережелерінен тұрады. 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 бұл саясатта кіріс трафикті мақсатты қосқыштарға ашады. Басқаша айтқанда, кіріс көзі болып табылады және мақсат сәйкес тағайындалған орын болып табылады. Сол сияқты, шығу - баратын жер, ал мақсат - оның көзі.

Бұл брандмауэрдің екі ережесіне тең: Енгізу → Мақсат; Мақсат → Шығу.

Шығу және 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 аттар кеңістігіндегі барлық подкасттарды таңдайды.

Бірінші сәйкестік және ереже тәртібі

Кәдімгі желіаралық қалқандарда пакеттегі әрекет (Рұқсат ету немесе Бас тарту) ол қанағаттандыратын бірінші ережемен анықталады. Кубернетесте саясаттардың реті маңызды емес.

Әдепкі бойынша, ешбір саясат орнатылмаған кезде, қосқыштар арасындағы байланысқа рұқсат етіледі және олар ақпаратты еркін алмаса алады. Саясаттарды құрастыра бастағанда, олардың кем дегенде біреуі әсер еткен әрбір подвод оны таңдаған барлық саясаттардың ажыратылуына (логикалық НЕМЕСЕ) сәйкес оқшауланады. Ешқандай саясат әсер етпеген қосқыштар ашық қалады.

Бұл әрекетті тазалау ережесі арқылы өзгертуге болады.

Тазалау ережесі («Тыйым салу»)

Брандмауэр саясаттары әдетте рұқсат етілмеген кез келген трафикті жоққа шығарады.

Кубернетестің «бас тарту» әрекеті жоқ, бірақ бірдей әсерге бастапқы бөлімдердің бос тобын (кіру) таңдау арқылы қалыпты (рұқсат ететін) саясатпен қол жеткізуге болады:

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

Назар аударыңыз аттар кеңістігіндегі қосқыштарға трафикке рұқсат беретін кез келген қосымша саясаттар осы ережеден басым болады (брандмауэр конфигурациясындағы бас тарту ережесінің алдында рұқсат ету ережесін қосуға ұқсас).

Барлығына рұқсат беру (кез келген-кез келген-рұқсат ету)

«Барлығына рұқсат ету» саясатын жасау үшін жоғарыдағы бас тарту саясатын бос элементпен толықтыру қажет ingress:

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

Ол қол жеткізуді қамтамасыз етеді барлық аттар кеңістігіндегі барлық подкасттарды (және барлық 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

Бірнеше саясатты біріктіру

Саясат логикалық түрде үш деңгейде өңделеді; Әрбір подводтың рұқсаттары оған әсер ететін барлық саясаттардың бөлінуіне сәйкес орнатылады:

1. Өрістерде from и to элементтердің үш түрін анықтауға болады (барлығы НЕМЕСЕ-мен біріктірілген):

namespaceSelector - бүкіл аттар кеңістігін таңдайды;
podSelector - түйіршіктерді таңдайды;
ipBlock - ішкі желіні таңдайды.

Сонымен қатар, бөлімшелердегі элементтердің саны (тіпті бірдей). from/to шектелмеген. Олардың барлығы логикалық НЕМЕСЕ-мен біріктіріледі.

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 (логикалық НЕМЕСЕ арқылы біріктірілген). Сол сияқты, бөлім 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. Әртүрлі саясаттар да логикалық НЕМЕСЕ-мен біріктіріледі

Бірақ олар біріктірілген кезде, бір шектеу бар атап көрсетті Крис Куни: Кубернетес саясаттарды тек басқалармен біріктіре алады 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

Нәтижесінде аттар кеңістігіндегі барлық подкасттар default қосқыштарға қол жеткізу postgres аттар кеңістігінде database. Бірақ қол жеткізуді ашқыңыз келсе ше postgres аттар кеңістігіндегі арнайы подкасттар ғана default?

Атау кеңістігі ЖӘНЕ подкасттар бойынша сүзгілеу

Kubernetes 1.11 және одан жоғары нұсқасы операторларды біріктіруге мүмкіндік береді namespaceSelector и podSelector логикалық ЖӘНЕ пайдалану. Ол келесідей көрінеді:

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

Неліктен ол әдеттегі НЕМЕСЕ орнына ЖӘНЕ деп түсіндіріледі?

Осыған назар аударыңыз podSelector дефиспен басталмайды. YAML-де бұл дегеніміз podSelector және оның алдында тұр namespaceSelector сол тізім элементіне сілтеме жасаңыз. Сондықтан олар логикалық ЖӘНЕ -мен біріктіріледі.

Алдында сызықша қосу podSelector нәтижесінде алдыңғы элементпен біріктірілетін жаңа тізім элементі пайда болады namespaceSelector логикалық НЕМЕСЕ пайдалану.

Белгілі бір белгісі бар бөтелкелерді таңдау үшін барлық аттар кеңістігінде, бос енгізіңіз 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

Бірнеше белгілер ЖӘНЕмен біріктіріледі

Бірнеше нысандар (хосттар, желілер, топтар) бар брандмауэр ережелері логикалық НЕМЕСЕ арқылы біріктіріледі. Пакет көзі сәйкес келсе, келесі ереже іске қосылады Host_1 НЕМЕСЕ Host_2:

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

Керісінше, Kubernetes-те әртүрлі белгілер бар podSelector немесе namespaceSelector логикалық ЖӘНЕ тіркесімімен біріктіріледі. Мысалы, келесі ереже екі белгі де бар қосқыштарды таңдайды, role=db И version=v2:

podSelector:
  matchLabels:
    role: db
    version: v2

Дәл осындай логика мәлімдемелердің барлық түрлеріне қолданылады: саясаттың мақсатты таңдаушылары, подкаст таңдаушылары және аттар кеңістігі таңдағыштары.

Ішкі желілер және IP мекенжайлары (IPBlocks)

Желіаралық қалқандар желіні сегменттеу үшін 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

Бұл мысалдағы бос подвод селекторы "аттар кеңістігіндегі барлық подкасттарды таңдау" дегенді білдіреді.

Бұл саясат тек 8.8.8.8 кіруге рұқсат береді; кез келген басқа IP-ге кіруге тыйым салынады. Осылайша, сіз ішкі Kubernetes DNS қызметіне кіруді бұғаттадыңыз. Егер сіз оны әлі де ашқыңыз келсе, оны нақты көрсетіңіз.

әдетте ipBlocks и podSelectors қосқыштардың ішкі IP мекенжайлары пайдаланылмағандықтан, бір-бірін жоққа шығарады ipBlocks. Нұсқау ішкі IP қосқыштары, сіз шын мәнінде сол мекенжайлары бар қосылымдарға/қосылымдарға рұқсат бересіз. Іс жүзінде сіз қай 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 мекенжайларына кіруді аша аласыз. Мысалы, подкасттың ішкі желісі 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 көмегімен жаңа архитектуралық тәсіл (мысалы, Istio туралы төменде қараңыз - шамамен аударыңыз.) бұл мәселені шешуге мүмкіндік береді.

Ingress және Egress екеуін де жазу керек пе?

Қысқа жауап: иә, А орамы B иінімен байланысуы үшін оған шығыс қосылымды жасауға рұқсат беру керек (ол үшін шығу саясатын конфигурациялау керек), ал В подводы кіріс қосылымын қабылдай алуы керек. (бұл үшін сізге тиісінше кіру саясаты қажет).

Дегенмен, іс жүзінде қосылымдарға бір немесе екі бағытта рұқсат беру үшін әдепкі саясатқа сенуге болады.

Егер кейбір под –көзі біреуі немесе бірнешеуі арқылы таңдалады шығу-саясаткерлер, оған қойылатын шектеулер олардың дизъюнкциясымен анықталады. Бұл жағдайда подкольге қосылуға нақты рұқсат беру керекадресат. Егер подключ ешқандай саясатпен таңдалмаса, оның шығыс (шығу) трафигі әдепкі бойынша рұқсат етіледі.

Сол сияқты, подъа-адресатбіреуі немесе бірнешеуі арқылы таңдалады кіру-саясат олардың бөлінуімен анықталады. Бұл жағдайда, сіз оған бастапқы подкестеден трафикті қабылдауға нақты рұқсат беруіңіз керек. Егер подкаст ешбір саясатпен таңдалмаса, оған барлық кіру трафигі әдепкі бойынша рұқсат етіледі.

Төмендегі "Мемлекеттік немесе азаматтығы жоқ" бөлімін қараңыз.

Журналдар

Kubernetes желілік саясаттары трафикті тіркеу жолын білмейді. Бұл саясаттың күтілгендей жұмыс істеп тұрғанын анықтауды қиындатады және қауіпсіздік талдауын өте қиындатады.

Сыртқы қызметтерге трафикті бақылау

Kubernetes желі саясаттары шығу бөлімдерінде толық жарамды домен атауын (DNS) көрсетуге мүмкіндік бермейді. Бұл факт тіркелген IP мекенжайы жоқ (мысалы, aws.com) сыртқы бағыттарға трафикті шектеу әрекеті кезінде айтарлықтай қолайсыздыққа әкеледі.

Саясатты тексеру

Брандмауэр сізді ескертеді немесе тіпті қате саясатты қабылдаудан бас тартады. Кубернетес те кейбір тексерулер жасайды. kubectl арқылы желі саясатын орнатқан кезде, Кубернетес саясаттың дұрыс емес екенін жариялап, оны қабылдаудан бас тартуы мүмкін. Басқа жағдайларда Кубернетес саясатты қабылдап, оны жетіспейтін мәліметтермен толтырады. Сіз оларды пәрмен арқылы көре аласыз:

kubernetes get networkpolicy <policy-name> -o yaml

Kubernetes валидация жүйесі қате емес екенін және қателердің кейбір түрлерін өткізіп жіберуі мүмкін екенін есте сақтаңыз.

Орындау

Kubernetes желілік саясаттарды өз бетімен орындамайды, ол тек Контейнерлік желі интерфейсі (CNI) деп аталатын негізгі жүйеге басқару ауыртпалығын жүктейтін API шлюзі ғана. Сәйкес CNI тағайындамай Kubernetes кластеріндегі саясаттарды орнату желіаралық қалқанды басқару серверіндегі саясаттарды кейін брандмауэрлерге орнатпай орнатуға ұқсас. Сізде лайықты CNI немесе Kubernetes платформаларында бұлтта орналастырылғанына көз жеткізу сізге байланысты. (Провайдерлердің тізімін қараңыз осында - шамамен. транс.), сіз үшін CNI орнататын желі саясаттарын қосыңыз.

CNI сәйкес көмекшісіз желі саясатын орнатсаңыз, Kubernetes сізге ескертпейтінін ескеріңіз.

Мемлекеттік немесе азаматтығы жоқ па?

Мен кездестірген барлық Kubernetes CNI деректері (мысалы, Calico Linux conntrack пайдаланады). Бұл подводқа оны қайта орнатудың қажетінсіз іске қосқан TCP қосылымы бойынша жауаптарды алуға мүмкіндік береді. Дегенмен, мен күйге кепілдік беретін Kubernetes стандартын білмеймін.

Жетілдірілген қауіпсіздік саясатын басқару

Kubernetes-те қауіпсіздік саясатын қолдану тиімділігін арттырудың кейбір жолдары:

Service Mesh архитектуралық үлгісі қызмет деңгейінде егжей-тегжейлі телеметрия мен қозғалысты басқаруды қамтамасыз ету үшін жанамаларды пайдаланады. Мысал ретінде алуға болады Istio.
Кейбір CNI жеткізушілері Kubernetes желілік саясаттарынан шығу үшін құралдарын кеңейтті.
Туфин Орка Kubernetes желі саясатының ашықтығы мен автоматтандырылуын қамтамасыз етеді.

Tufin Orca бумасы Kubernetes желілік саясаттарын басқарады (және жоғарыдағы скриншоттардың көзі).

қосымша ақпарат

қорытынды

Kubernetes желілік саясаттары кластерлерді сегменттеуге арналған құралдардың жақсы жиынтығын ұсынады, бірақ олар интуитивті емес және көптеген нәзіктіктерге ие. Менің ойымша, осы күрделілікке байланысты көптеген қолданыстағы кластерлердің саясаты қате. Бұл мәселенің мүмкін шешімдері саясат анықтамаларын автоматтандыру немесе басқа сегменттеу құралдарын пайдалану болып табылады.

Бұл нұсқаулық кейбір сұрақтарды шешуге және туындауы мүмкін мәселелерді шешуге көмектеседі деп үміттенемін.

Аудармашыдан PS

Біздің блогта да оқыңыз:

«Istio көмегімен микросервистерге оралу»: 1 бөлім (негізгі мүмкіндіктерге кіріспе), 2 бөлім (маршруттау, қозғалысты басқару), 3-бөлім (қауіпсіздік);
«Кубернетестегі желіге арналған иллюстрациялық нұсқаулық»: 1 және 2 бөліктер (желі үлгісі, қабаттасатын желілер), 3-бөлім (қызметтер және трафикті өңдеу);
«Қауіпсіздікті қажет ететін орталарда Docker және Kubernetes«;
«9 Kubernetes қауіпсіздіктің ең жақсы тәжірибесі«;
«Kubernetes-те хакерлік шабуылға ұшырамаудың 11 жолы«.

Ақпарат көзі: www.habr.com

Қауіпсіздік мамандарына арналған Kubernetes желілік саясаттарына кіріспе