Настройка механизма фильтрации трафика¶

Этот раздел описывает управление правилами фильтрации для узлов и сервисов, развёрнутых с помощью Kolla Ansible. Поддерживается фильтрация трафика на основании правил nftables, включая фильтрацию трафика в контейнерах, использующих интерфейсы типа bridge на базе Podman. При использовании сетей типа host правила фильтрации для контейнеров не применяются.

Параметры фаервола задаются в globals.yml или globals.d/firewall.yml репозитория региона.

При каждом запуске правила фаервола полностью пересоздаются.

Включение фаервола¶

По умолчанию управление фаерволом отключено (enable_firewall: "no"). Для включения:

Откройте веб-интерфейс GitLab.

Перейдите в репозиторий региона project_k / deployments / <имя региона>.
Перейдите в файл globals.yml или создайте файл globals.d/firewall.yml. Добавьте в файл следующую конфигурацию:
## Firewall options
enable_firewall: "yes"

## Разрешение исходящего трафика
firewall_allow_mgmt_outgoing: "yes"

## Добавление drop-правила в конце цепочек
firewall_enable_trailing_drop: "no"
где:

enable_firewall: "yes" — включение управления фаерволом через nftables;

firewall_allow_mgmt_outgoing: "yes" — разрешение всего исходящего трафика через api_interface (сетевой интерфейс, через который OpenStack-сервисы принимают API-запросы и взаимодействуют внутри кластера; как правило, это интерфейс управляющей сети). Необходимо для подключений сервисов к базам данных, очередям сообщений и другим компонентам кластера. Значение по умолчанию — "yes". Переопределяйте только в том случае, если нужно ограничить исходящий трафик;

firewall_enable_trailing_drop: "no" — добавление правила drop в конец цепочек для блокировки неразрешённого трафика. По умолчанию имеет значение "no".

При включении фаервола автоматически применяются правила по умолчанию для трёх типов трафика:

management — доступ к management IP-адресу каждого узла;
external — доступ к внешнему VIP-адресу (kolla_external_vip_address);
internal — доступ к внутреннему VIP-адресу (kolla_internal_vip_address).

Также автоматически создаётся тип keystack, который разрешает межузловую коммуникацию внутри кластера. Подробнее — в разделе Тип правил по умолчанию.

Секция firewall_rules¶

Секция firewall_rules предназначена для задания правил доступа к VIP-адресам или другим точкам подключения. Она дополняет правила, связанные с контейнерами, и применяется отдельно.

Ниже приведены правила по умолчанию, которые применяются автоматически при включении фаервола:

firewall_rules:
  management:
    allow:
      - "10.0.0.0/8"
      - "172.16.0.0/12"
      - "192.168.0.0/16"
    destination: "{{ hostvars[inventory_hostname].ansible_host | default(inventory_hostname) }}"
  external:
    allow:
      - "0.0.0.0/0"
    destination: "{{ kolla_external_vip_address }}"
    destination_ports:
      - "80"
      - "443"
      - "1024:65535"
  internal:
    allow:
      - "0.0.0.0/0"
    destination: "{{ kolla_internal_vip_address }}"
    destination_ports:
      - "80"
      - "443"
      - "1024:65535"

По умолчанию задано три блока:

management — разрешает доступ к management IP-адресу узла только из приватных подсетей (RFC 1918: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16). Ограничений по портам нет.
external — разрешает доступ к внешнему VIP из любого источника на портах 80 и 443 (HTTP/HTTPS для доступа к OpenStack API через HAProxy) и в диапазоне 1024:65535 (эндпоинты OpenStack-сервисов, которые HAProxy маршрутизирует на внутренние порты). Если переопределить этот блок и не указать нужные порты, внешний API станет недоступен.
internal — разрешает доступ на те же порты, что и external, но для внутреннего VIP, используемого для межсервисного взаимодействия компонентов OpenStack. В случае переопределения также важно сохранить доступ к нужным портам — иначе межсервисное взаимодействие с OpenStack нарушится.

Пользовательские правила объединяются с правилами по умолчанию. Если задать ключ management, external или internal в firewall_rules, его значения переопределят соответствующие поля из правил по умолчанию.

Для типа management ограничение по портам не задано — доступны все порты.

Для каждого блока правил доступны следующие параметры:

allow — список разрешённых источников (CIDR);
deny — список запрещённых источников (CIDR);
destination — целевой IP-адрес (например, внешний или внутренний VIP);
destination_ports — список портов или диапазонов.

Секция firewall_containers¶

Правила задаются для каждого контейнерного сервиса через переменную firewall_containers. Раздел применяется только для контейнеров с сетями типа bridge — при использовании network_mode: host правила firewall_containers не действуют.

В примере ниже запрещается трафик от контейнеров cinder_scheduler и cinder_api на порт 22 (SSH). Это предотвращает инициирование SSH-соединений из этих контейнеров.

firewall_containers:
  podman_override:
    deny:
      - "0.0.0.0/0"
    destination_ports:
      - "22"
    containers:
      - "cinder_scheduler"
      - "cinder_api"

Здесь podman_override — произвольное имя группы правил. Одна группа может охватывать несколько контейнеров через параметр containers. Имена контейнеров должны соответствовать именам сервисов Kolla Ansible.

Поддерживаемые параметры:

allow — список разрешённых источников (CIDR);
deny — список запрещённых источников (CIDR);
destination_ports — список целевых портов;
protocol — сетевой протокол (по умолчанию tcp, если заданы порты);
containers — применение правила на конкретные контейнеры.

Порядок правил¶

Порядок правил настраивается через две переменные:

firewall_ruleorder — задаёт порядок применения правил внутри одного типа:
firewall_ruleorder: - allow - deny
firewall_traffic_types — задаёт порядок применения типов правил относительно друг друга:
firewall_traffic_types: - podman_override - management - external - internal

Тип правил по умолчанию — KeyStack¶

Роль автоматически добавляет тип правил keystack первым в firewall_traffic_types. Этот тип обеспечивает межузловую коммуникацию внутри кластера и работает следующим образом:

При каждом применении фаервола роль собирает IP-адреса всех узлов из inventory-группы firewall — по интерфейсу api_interface.
Для текущего узла создаётся правило, разрешающее входящий трафик с этих адресов на его management IP-адрес.

Благодаря этому все узлы кластера могут взаимодействовать друг с другом, что обеспечивает корректную работу OpenStack-сервисов.

Тип keystack нельзя удалить из конфигурации. Однако его можно явно указать в firewall_traffic_types, чтобы изменить порядок применения относительно других правил:

firewall_traffic_types:
  - management
  - keystack
  - external
  - internal

Сохранение настроек¶

Конфигурация сохраняется в файл, путь к которому зависит от базового дистрибутива:

Для дистрибутивов на базе RHEL (например, Rocky, SberLinux) используется путь /etc/sysconfig/nftables.conf;
Для других систем (например, Debian или Ubuntu) — /etc/nftables.conf.

Также будет установлен и запущен системный сервис nftables-persist, который обеспечивает восстановление конфигурации после перезагрузки.