Alauda Container Platform
  • Русский

    • Понимание API сетевых политик

    Содержание

    ВведениеОценка сетевой политики в KUBE-OVNВ чем разница между AdminNetworkPolicy с областью действия и NetworkPolicy с областью namespace?

    Введение

    Сетевая безопасность в кластерах в стиле Kubernetes включает контроль того, какие рабочие нагрузки (Pods, namespaces) могут взаимодействовать и каким образом. В основе лежат API сетевых политик, которые обеспечивают сегментацию (уровни 3/4) и управление трафиком. Со временем появились более продвинутые уровни API для поддержки глобальных ограничений в кластере, обеспечения мультиарендности, моделей с нулевым доверием и фильтрации на уровне приложений (уровень 7).

    В этой статье рассматривается модель API v1alpha1: AdminNetworkPolicy (ANP) и BaselineAdminNetworkPolicy (BANP), их место среди API сетевых политик, их связь со стандартной NetworkPolicy и способы использования сегодня с учетом планирования будущих версий.

    Оценка сетевой политики в KUBE-OVN

    Когда применяется несколько сетевых политик, они следуют строгому порядку приоритета: Admin Network Policy имеет приоритет над Network Policy, которая, в свою очередь, имеет приоритет над Baseline Admin Network Policy.

    Процедура следующая:

    В чем разница между AdminNetworkPolicy с областью действия и NetworkPolicy с областью namespace?

    ПараметрNetworkPolicy с областью namespaceAdminNetworkPolicy с областью кластера
    Область действияПрименяется только к одному namespaceПрименяется ко всему кластеру
    Аудитория / ВладельцыРазработчик приложения или владельцы namespaceАдминистраторы платформы или администратор кластера
    Основное назначениеМикросегментация на уровне рабочих нагрузок (L3/L4)Применение глобальных или межпространственных правил доступа
    Объект управленияPods внутри namespace, выбранные через podSelectorNamespaces или Pods, выбранные через верхнеуровневый subject
    Приоритет политикиСредний приоритет — оценивается после правил уровня администратораБолее высокий приоритет — переопределяет политики namespace
    Типичные сценарииРазрешение frontend → backend, ограничение доступа к БД и т.п.Ограничение межарендного трафика, применение ограничений исходящего трафика, установка глобальных защит
    ВидимостьВлияет только на namespace, где создана политикаМожет влиять на несколько namespace одновременно
    Правила между namespaceРазрешены только косвенно (через namespaceSelector)Полноценный контроль трафика между namespace
    Поверхность рискаОшибка конфигурации затрагивает один namespaceОшибка конфигурации может повлиять на трафик всего кластера