Calico за мрежа в Kubernetes: запознаване и малко опит

Целта на статията е да запознае читателя с основите на мрежовото взаимодействие и управлението на мрежовите политики в Kubernetes, както и с външния плъгин Calico, който разширява стандартните възможности. В същото време ще бъдат демонстрирани удобството на конфигурацията и някои функции с реални примери от нашия опит.

Бързо въведение в мрежовото устройство на Kubernetes

Кластърът Kubernetes не може да се представи без мрежа. Вече публикувахме материали по техните основи: «Илюстрирано ръководство по устройството на мрежата в Kubernetes» и „Въведение в мрежовите политики на Kubernetes за специалисти по сигурността».

В контекста на тази статия е важно да се отбележи, че за мрежовата свързаност между контейнерите и възлите не отговаря самият K8s: за това се използват всевъзможни плагини CNI (Container Networking Interface). Подробно за тази концепция вече разказвахме.

Например, най-разпространеният от тези плъгини — Flannel — осигурява пълна мрежова свързаност между всички възли в кластера, като изгражда мостове на всеки възел, закрепвайки подмрежа за него. Въпреки това пълната и нерегулирана наличност не винаги е полезна. За да се осигури някаква минимална изолация в клъстера, е необходимо да се намеси в конфигурацията на firewall-а. Обикновено тя се управлява от същия CNI, поради което всякакви външни намеси в iptables могат да бъдат интерпретирани неправилно или игнорирани напълно.

А «из коробки» за организиране на управлението на мрежовите политики в кластера Kubernetes се предоставя NetworkPolicy API. Този ресурс, разпространяващ се в избраните пространства от имена, може да съдържа правила за разграничаване на достъпа между различни приложения. Той също така позволява настройка на достъпността между конкретни pod-ове, среди (пространства от имена) или блокове IP адреси:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: test-network-policy
  namespace: default
spec:
  podSelector:
    matchLabels:
      role: 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

Този не съвсем примитивен пример от официалната документация Може би веднъж завинаги ще ни отнеме желанието да разберем логиката на работа на мрежовите политики. Въпреки това, ще се опитаме да разберем основните принципи и методи на обработка на трафика с помощта на мрежови политики...

Логично е, че има 2 типа трафик: входящ в pod (Ingress) и изходящ от него (Egress).

Всъщност, на тези 2 категории по посока на движение се разделя политиката.

Следващият задължителен атрибут е селектор; този, към когото се прилага правилото. Това може да бъде pod (или група pod-ове) или среда (т.е. пространство на имената). Важно е да се отбележи, че и двата вида на тези обекти са задължителни да съдържат етикет (label в терминологията на Kubernetes) — именно тях използват политиките.

Освен крайния брой селектори, обединени с някакъв етикет, съществува възможност за писане на правила като "Разреши/забрани всичко/всички" в различни вариации. За това се използват конструкции от вида:

  podSelector: {}
  ingress: []
  policyTypes:
  - Ingress

— в този пример на всички pod-ове на средата им се забранява входящ трафик. Обратното поведение може да бъде постигнато с такава конструкция:

  podSelector: {}
  ingress:
  - {}
  policyTypes:
  - Ingress

По аналогичен начин за изходящия:

  podSelector: {}
  policyTypes:
  - Egress

— за да го изключим. А ето как за да го включим:

  podSelector: {}
  egress:
  - {}
  policyTypes:
  - Egress

Връщайки се към избора на CNI плъгин за клъстера, трябва да отбележим, че не всеки мрежов плъгин поддържа работа с NetworkPolicy. Например, споменатият Flannel не може да конфигурира мрежови политики, за което е казано директно в официалното хранилище. Там също е спомената алтернатива — проект с отворен код Calico, който значително разширява стандартния набор от API на Kubernetes по отношение на мрежовите политики.

Запознаваме се с Calico: теория

Плъгинът Calico може да се използва в интеграция с Flannel (подпроект Canal) или самостоятелно, обхващайки както функции за осигуряване на мрежова свързаност, така и възможности за управление на достъпността.

Какви възможности дава използването на "кутия" решение K8s и набор от API от Calico?

Ето какво е вградено в NetworkPolicy:

• политиките са ограничени до средата;
• политиките се прилагат към pod-ове, маркирани с етикети;
• правила могат да се прилагат към pod-ове, среди или подсистеми;
• правила могат да съдържат протоколи, номинирани или символни указания за портове.

А ето как Calico разширява тези функции:

• Политиките могат да се прилагат към всеки обект: pod, контейнер, виртуална машина или интерфейс;
• Правилата могат да съдържат конкретно действие (забрана, разрешение, логване);
• Като цел или източник на правилата може да бъде порт, диапазон от портове, протоколи, HTTP или ICMP атрибути, IP или подсметка (4 или 6 поколение), всякакви селектори (възли, хостове, среди);
• Допълнително може да се регулира преминаването на трафика с помощта на настройки DNAT и политики за пренасочване на трафика.

Първите комити на GitHub в репозитория Calico датират от юли 2016 година, а вече след година проектът заема водещи позиции в организацията на мрежовата свързаност на Kubernetes — за което свидетелстват, например, резултатите от проучванията, проведени от The New Stack:

Много големи managed решения с K8s, като Amazon EKS, Azure AKS, Google GKE и други, преминаха към препоръчване на него за употреба.

Що се отнася до производителността, тук всичко е чудесно. При тестовете на продукта си екипът за разработка на Calico демонстрира астрономически показатели, стартирайки над 50000 контейнера на 500 физически възли със скорост на създаване от 20 контейнера в секунда. Проблеми при мащабиране не са открити. Такива резултати бяха обявени вече при анонса на първата версия. Независими изследвания, насочени към пропускната способност и обемите на потребление на ресурси, също потвърдиха производителността на Calico, която практически не отстъпва на Flannel. Например:

Проектът много бързо напредва, поддържа работата в популярни managed K8s решения, OpenShift, OpenStack, има възможност за използване на Calico при разгръщане на кластер с помощта на kops, срещат се споменавания за изграждане на Service Mesh мрежи (ето пример за употреба заедно с Istio).

Практика с Calico

В общия случай на използване на ванилов Kubernetes, инсталацията на CNI се свежда до прилагане на файла calico.yaml, изтеглен от официалния сайт, с помощта на kubectl apply -f.

Като правило, актуалната версия на плагина е съвместима с 2-3 последните версии на Kubernetes: работа с по-стари версии не се тества и не се гарантира. Според твърдения на разработчиците, Calico работи на ядро на Linux над 3.10 под управлението на CentOS 7, Ubuntu 16 или Debian 8, върху iptables или IPVS.

Изолация вътре в средата

За общото разбиране, нека разгледаме един прост случай, за да видим как се различават мрежовите политики в нотация Calico от стандартните и как подходът при съставяне на правила улеснява тяхната четимост и гъвкавост при конфигурирането:

В кластера са разположени 2 уеб приложения: на Node.js и PHP, като едното от тях използва Redis. За да затворим достъпа до Redis от PHP, оставяйки свързаността с Node.js, е достатъчно да приложим следната политика:

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: allow-redis-nodejs
spec:
  podSelector:
    matchLabels:
      service: redis
  ingress:
  - from:
    - podSelector:
        matchLabels:
          service: nodejs
    ports:
    - protocol: TCP
      port: 6379

Всъщност разрешихме входящия трафик на порта на Redis от Node.js. И явно не забранихме нищо друго. След като се появи NetworkPolicy, всички селектори, споменати в него, започват да се изолират, освен ако не е указано друго. Въпреки това, правилата за изолация не се разпространяват върху други обекти, които не са покрити от селектора.

В примера се използва apiVersion на Kubernetes „извън кутията“, но нищо не пречи да се използва същият ресурс от доставката на Calico. Синтаксисът там е по-разширен, така че ще трябва да препишем правилото за горепосочения случай по следния начин:

apiVersion: crd.projectcalico.org/v1
kind: NetworkPolicy
metadata:
  name: allow-redis-nodejs
spec:
  selector: service == 'redis'
  ingress:
  - action: Allow
    protocol: TCP
    source:
      selector: service == 'nodejs'
    destination:
      ports:
      - 6379

Гореизброените конструкции за разрешаване или забрана на целия трафик чрез обикновен NetworkPolicy API съдържат сложни за възприемане и запомняне конструкции със скоби. В случая с Calico, за да променим логиката на правилото на защитната стена на противоположната, е достатъчно да сменим action: Allow на action: Deny.

Изолация по среди

Сега да представим ситуация, в която приложението генерира бизнес метрики за събирането им в Prometheus и последващия анализ чрез Grafana. В експорта могат да се съдържат чувствителни данни, които по подразбиране отново са достъпни за общо разглеждане. Нека закрием от външни погледи тези данни:

Prometheus обикновено е извън основната работна среда — в примера това ще бъде namespace с следния вид:

apiVersion: v1
kind: Namespace
metadata:
  labels:
    module: prometheus
  name: kube-prometheus

Поле metadata.labels това не е случайно. Както беше споменато по-горе, namespaceSelector (както и podSelector) оперира с етикети. Затова, за да разрешите извличането на метрики от всички pod’ове на определен порт, ще трябва да добавите някаква етикета (или да вземете от съществуващите), след това да приложите конфигурация като:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-metrics-prom
spec:
  podSelector: {}
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          module: prometheus
    ports:
    - protocol: TCP
      port: 9100

А в случай на използване на политики Calico синтаксисът ще бъде следният:

apiVersion: crd.projectcalico.org/v1
kind: NetworkPolicy
metadata:
  name: allow-metrics-prom
spec:
  ingress:
  - action: Allow
    protocol: TCP
    source:
      namespaceSelector: module == 'prometheus'
    destination:
      ports:
      - 9100

При добавяне на подобни политики за конкретни нужди можете да защитите приложенията в кластера от злонамерено или случайно вмешателство.

Най-добрата практика, според създателите на Calico, е подходът „Забрани всичко и ясен достъп до необходимото“, отразен в официалната документация (аналогичен подход имат и други — в частност, в вече споменатата статия).

Приложение на допълнителни обекти Calico

Напомням, че чрез разширен набор от API Calico можете да регулирате достъпността на възлите, без да сте ограничени до pod’ове. В следващия пример с помощта на GlobalNetworkPolicy се затваря възможност за провеждане на ICMP заявки в кластера (например пингове от pod в възел, между pod’ове или от възел до IP на pod’а):

apiVersion: crd.projectcalico.org/v1
kind: GlobalNetworkPolicy
metadata:
  name: block-icmp
spec:
  order: 200
  selector: all()
  types:
  - Ingress
  - Egress
  ingress:
  - action: Deny
    protocol: ICMP
  egress:
  - action: Deny
    protocol: ICMP

В горния случай остава възможността на възлите в кластера да комуникират помежду си чрез ICMP. И този въпрос се решава с помощта на GlobalNetworkPolicy, приложена към сущността HostEndpoint:

apiVersion: crd.projectcalico.org/v1
kind: GlobalNetworkPolicy
metadata:
  name: deny-icmp-kube-02
spec:
  selector: "role == 'k8s-node'"
  order: 0
  ingress:
  - action: Allow
    protocol: ICMP
  egress:
  - action: Allow
    protocol: ICMP
---
apiVersion: crd.projectcalico.org/v1
kind: HostEndpoint
metadata:
  name: kube-02-eth0
  labels:
    role: k8s-node
spec:
  interfaceName: eth0
  node: kube-02
  expectedIPs: ["192.168.2.2"]

Случай с VPN

Накрая, ще представя съвсем реален пример за използването на функциите на Calico в случаи на взаимодействие около кластера, където стандартният набор от политики не е достатъчен. За достъп до уеб приложение клиентите използват VPN тунел, и този достъп е строго контролиран и ограничен до конкретен списък на разрешени услуги:

Клиентите се свързват с VPN през стандартния UDP порт 1194 и при свързване получават маршрути към кластерните подсистеми на pod’овете и услугите. Подсистемите се push-ват изцяло, за да се избегне загуба на услуги при рестартирания и промяна на адреси.

Портът в конфигурацията е стандартен, което налага някои нюанси в процеса на конфигуриране на приложението и пренасянето му в Kubernetes кластера. Например, в AWS LoadBalancer за UDP стана наличен буквално в края на миналата година в ограничен списък с региони, а NodePort не може да се използва поради пробиването му на всички възли в кластера и невъзможността за мащабиране на броя на инстанциите на сървъра с оглед отказоустойчивост. Освен това, ще се наложи да промените диапазона на портовете, избирани по подразбиране…

В резултат на разглеждането на възможни решения беше избрано следното:

1. Pod’те с VPN се планират на възел в режим hostNetwork, т.е. на фактическия IP.
2. Услугата се извежда навън чрез ClusterIP. На възела физически се активира порт, който е достъпен навън с малки уговорки (условно наличие на реален IP адрес).
3. Определението на възела, на който е активиран pod, е извън нашето повествование. Ще кажа само, че е възможно да се 'прибие' услугата твърдо към възела или да се напише малък sidecar-сервис, който ще следи текущия IP адрес на VPN услугата и да коригира DNS записите, зададени при клиентите — каквото и да е на въображението.

От гледна точка на маршрутизацията, можем недвусмислено да идентифицираме клиента зад VPN по неговия IP адрес, предоставен от VPN сървъра. По-долу — примитивен пример за ограничаване на достъпа на такъв клиент до услугите, илюстрация на споменатия по-горе Redis:

apiVersion: crd.projectcalico.org/v1
kind: HostEndpoint
metadata:
  name: vpnclient-eth0
  labels:
    role: vpnclient
    environment: production
spec:
  interfaceName: "*"
  node: kube-02
  expectedIPs: ["172.176.176.2"]
---
apiVersion: crd.projectcalico.org/v1
kind: GlobalNetworkPolicy
metadata:
  name: vpn-rules
spec:
  selector: "role == 'vpnclient'"
  order: 0
  applyOnForward: true
  preDNAT: true
  ingress:
  - action: Deny
    protocol: TCP
    destination:
      ports: [6379]
  - action: Allow
    protocol: UDP
    destination:
      ports: [53, 67]

Тук е строго забранено свързването на порт 6379, но в същото време е запазена работата на DNS услугата, функционирането на която често претърпява проблеми при съставянето на правила. Защото, както беше споменато по-рано, при появата на селектор към него се прилага рестриктивна политика по подразбиране, ако не е указано друго.

Итог

По този начин, с помощта на разширеното API на Calico можете гъвкаво да конфигурирате и динамично да променяте маршрутизацията в кластера и около него. В общия случай, самото му използване може да изглежда като стреляне с пушка по врани, а внедряването на L3 мрежа с BGP и IP-IP тунели изглежда монструозно в проста инсталация на Kubernetes в плоска мрежа... Въпреки това, инструментът изглежда напълно жизнеспособен и полезен.

Изолацията на кластера за осигуряване на изискванията за сигурност не винаги може да бъде реализирана, и точно в такива случаи на помощ идва Calico (или подобно решение). Примерите, посочени в статията (с малки корекции), се използват в няколко инсталации на нашите клиенти в AWS.

P.S.

Прочетете също в нашия блог:

• «Въведение в мрежовите политики на Kubernetes за специалисти по сигурността»;
• «Илюстрировано ръководство за структурата на мрежата в Kubernetes»: части 1 и 2 (мрежова модел, overlay мрежи), част 3 (услуги и обработка на трафика);
• «Container Networking Interface (CNI) — мрежов интерфейс и стандарт за Linux контейнери».

Източник: habr.com