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 типа трафик: входящ (Ingress) в pod и изходящ (Egress) от него.

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

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

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

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

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

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

По подобен начин за изходящия:

  podSelector: {} 
  policyTypes: 
  - Egress

— за неговото деактивиране. А ето как за активиране:

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

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

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

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

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

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

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

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

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

Първите комити в GitHub в репозитория Сalico са датирани от юли 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 и при свързването получават маршрути към кластерни подсистеми на подовете и услугите. Подсистемите се пренасочват изцяло, за да не се загубят услугите при рестартиране и смяна на адресите.

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

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

1. Подовете с VPN се планират на възел в режим hostNetwork, тоест на фактическия IP.
2. Услугата се публикува навън чрез ClusterIP. На възела физически се отваря порт, който е достъпен отвън с малки уговорки (условно наличие на реален IP адрес).
3. Определянето на възела, на който е стартиран подът, е извън обхвата на нашето разказване. Ще кажа само, че може да се „закрепи“ услугата за възела или да се напише малък sidecar-service, който ще следи текущия 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 (мрежови модели, оверлейни мрежи), част 3 (услуги и управление на трафика);
• «Container Networking Interface (CNI) — мрежов интерфейс и стандарт за Linux контейнери».

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