Сетевые политики

Страница “Сетевые политики” содержит список политик (правил) для входящего и исходящего трафика к ресурсам кластера. В основе используется Cilium.

Для создания политик реализован графический интерфейс. Он представлен в виде блоков, обозначающий компоненты, между которыми конфигурируется доступ, и линии, которые отображают связи между компонентами.

Есть 3 уровня компонентов:

  • вне кластера;
  • внутри кластера;
  • внутри неймспейса.

Центральным компонентом схемы является неймспейс, в рамках которого происходит настройка (далее - конфигурируемый неймспейс). В блоке неймспейса введите название политики и выберите конфигурируемый неймспейс.

Правила сетевых политик

Для каждого компонента можно настроить правило взаимодействия с неймспейсом. Входящие потоки в конфигурируемый неймспейс регламентируются правилами Ingress, исходящие - правилами Egress. Для создания правила нажмите на + в блоке компонента и выберите параметры. Добавленные правила будут отображаться в нижней части блока компонента. Для удаления правила нажмите на правило, затем на значок корзины в открывшемся окне. От каждого созданного правила отображается связь до конфигурируемого неймспейса.

Правила могут быть:

  • Запрещающим (запрещает обращение одного объекта к другому по указанному порту)
  • Разрешающим (разрешает обращение одного объекта к другому по указанному порту)
  • Отключенным (правило неактивно, не выполняет разрешения или запрета).

Когда весь трафик по умолчанию разрешен и добавляется правило, накладывающее ограничение, то трафик вне этого правила запрещается.

Ingress правила (Входящий трафик)

Вне кластера

На этом уровне можно определить правила входящего в неймспейс кластера трафика:

  • Из любого эндпоинта. При установлении запрещающего правила трафик из любых эндпоинтов вне кластера к указанным портам объектов в конфигурируемом неймспейсе будет отбрасываться.
  • Из CIDR. При установлении правила исключения для CIDR, трафик из этого CIDR вне кластера будет отбрасываться.

Если необходимо, чтобы поды конфигурируемого неймспейса получали входящий трафик, рассмотрите один из следующих вариантов:

  • разрешить входящий трафик с любых эндпоинтов;
  • разрешить входящий трафик с любых эндпоинтов, но только к определенному порту(ам) (например, к порту 80);
  • разрешить входящий трафик с определенного CIDR;
  • разрешить входящий трафик с определенного CIDR, но только к определенному порту(ам) (например, к порту 80).

Внутри кластера

Трафик из любого пода или неймспейса в кластере будет отброшен, если не разрешен другими правилами.

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

  • разрешить входящий трафик только из выбранных неймспейсов;
  • разрешить входящий трафик только от подов, соответствующих выбранным лейблам;
  • разрешить весь входящий трафик от любого пода в кластере.

Типы правил:

  • Из всех ресурсов кластера;
  • Из некоторых неймспейсов;
  • Из некоторых подов;
  • Из хостов (выбирает локальный хост и все контейнеры, запущенные на этом хосте);
  • Из удаленных узлов (Любой узел в любом из подключенных кластеров, кроме локального хоста, все контейнеры, работающие в режиме сети хоста на удаленных узлах).

Внутри неймспейса

Весь входящий трафик к любому поду конфигурируемого неймспейса будет отброшен, если он не разрешен другими правилами.

Типы правил:

  • Из любого пода.
  • Из некоторых подов.

Если необходимо, чтобы поды конфигурируемого неймспейса получали входящий трафик, рассмотрите один из следующих вариантов:

  • разрешить входящий трафик любым подам;
  • разрешить входящий трафик любым подам, но только к определенному порту(ам) (например, к порту 80);
  • разрешить входящий трафик некоторым подам;
  • разрешите ходящий трафик некоторым подам, но только к определенному порту(ам) (например, к порту 80).

разрешить входящий трафик только к любому поду конфигурируемого неймспейса с любых эндпоинтов.

Egress правила (Исходящий трафик)

Вне кластера

Исходящий трафик к любому эндпоинту вне кластера будет запрещен, если его не разрешают другие правила.

Если поды в конфигурируемом неймспейсе должны иметь возможность передавать трафик в эндпоинты за пределами кластера, рассмотрите одну из следующих опций:

  • Разрешить трафик к конкретным CIDR;
  • Разрешить трафик к конкретным FQDN;
  • Разрешить трафик к любому эндпоинту вне кластера.

Типы правил:

  • К любому эндпоинту;
  • До CIDR;
  • До FQDN.

Чтобы разрешить трафик до FQDN должен быть разрешен трафик до Kubernetes DNS. Без соблюдения этого условия правило добавить можно, но оно не будет работать. Такая связь будет отображаться серым цветом. DNS proxy будет включен, когда вы разрешите трафик до Kubernetes DNS.

Внутри кластера

Исходящий трафик к любому поду в любом неймспейсе кластера будет запрещен, если он не разрешен другими правилами.

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

  • разрешить исходящий трафик только к выбранным неймспейсам;
  • разрешить исходящий трафик только к подам, соответствующим выбранным лейблам.

Типы правил:

  • Ко всем ресурсам кластера (по умолчанию);
  • Kubernetes DNS (Когда разрешена: разрешает потоки Egress в Kubernetes DNS. Когда запрещена: Текущая политика не допускает передачу трафика на DNS Kubernetes. В результате запросы DNS от подов конфигурируемого неймспейса будут игнорироваться внутри кластера, если не будет разрешено другими правилами). Когда Kubernetes DNS разрешен, DNS proxy включен по умолчанию. Когда отключен, вы не можете включить DNS proxy.
  • К некоторым неймспейсам;
  • К некоторым подам;
  • К сервисам;
  • К хостам (выбирает локальный хост и все контейнеры, запущенные на этом хосте);
  • К удаленным узлам (любой узел в любом из подключенных кластеров, кроме локального хоста. Также выбирает все контейнеры, работающие в режиме сети хоста на удаленных узлах).

Внутри неймспейса

Исходящий трафик к любому поду из конфигурируемого неймспейса будет запрещен, если не разрешен другими правилами.

Используйте селекторы подов, чтобы обеспечить минимальные привилегии безопасности, или разрешите весь входящий трафик в пределах неймспейса для начала работы с более простой политикой.

Типы правил:

  • К любому поду;
  • К сервисам;
  • К некоторым подам.

Просмотр и изменение Сетевых политик

Созданные Сетевые политики отображаются в виде списка на странице Сетевые политики в разделе Администрирование кластера.

Для просмотра нажмите на название Сетевой политики в списке.

При необходимости изменения Сетевой политики измените в редакторе сетевой политики конфигурацию и нажмите Сохранить.

Сетевую политику также можно изменить с помощью YAML манифеста. Перейдите на вкладку Манифест внесите изменения. После изменения манифеста нажмите Применить и в правой части экрана отобразится результат проверки. Раскройте блок результата проверки, чтобы увидеть полный манифест.

Сохраните изменения, внесенные в манифест. Несохраненные данные не будут применены.

Дефолтные сетевые политики

Доступ к KubeAPI-серверу 

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: allow-kube-apiserver
  namespace: yournamespacename
spec:
  description: "For endpoints in this namespace, allow egress to kube-apiserver"
  endpointSelector: {}
  egress:
    - toEntities:
      - kube-apiserver

Запрещающая политика

denyall

apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:
  name: deny-all
  namespace: yournamespacename
spec:
  description: "Deny all traffic in this namespace"
  endpointSelector: {}
  ingress:
  - {}
  egress:
  - {}

Исходящий трафик к KubeDNS и NodeLocalDNS 

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: allow-dns
  namespace: yournamespacename
spec:
  description: "For endpoints in this namespace, allow egress to kube-dns and shturval-caching-dns"
  endpointSelector: {}
  egress:
    - toEndpoints:
        - matchLabels:
            io.kubernetes.pod.namespace: kube-system
            k8s-app: kube-dns
      toPorts:
        - ports:
            - port: "53"
              protocol: UDP
            - port: "53"
              protocol: TCP
            - port: "9153"
              protocol: TCP
    - toEndpoints:
        - matchLabels:
            io.kubernetes.pod.namespace: kube-system
            app.kubernetes.io/name: shturval-caching-dns
      toPorts:
        - ports:
            - port: "53"
              protocol: UDP
            - port: "9253"
              protocol: TCP

Исходящий трафик к определенному приложению

allowout

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: allow-egress
  namespace: yournamespacename
spec:
  description: "For endpoints in this namespace, allow to target app"
  endpointSelector: {}
  egress:
    - toEndpoints:
        - matchLabels:
            io.kubernetes.pod.namespace: <TARGET NAMESPACE>
            app.kubernetes.io/name: <TARGET APP NAME>
      toPorts:
        - ports:
            - port: "<TARGET APP PORT>"
              protocol: <TARGET APP PORT PROTOCOL(TCP/UDP)>

Входящий трафик из Ingress-контроллера

allowin

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: allow-ingress
  namespace: yournamespacename
spec:
  description: "For endpoints in this namespace, allow ingress from ingress-controller"
  endpointSelector: {}
  ingress:
    - fromEndpoints:
        - matchLabels:
            app.kubernetes.io/name: shturval-ingress-controller
            io.kubernetes.pod.namespace: ingress

Трафик внутри неймспейса

allowinns

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: allow-in-namespace
  namespace: yournamespacename
spec:
  description: "For endpoints in this namespace, allow all in this namespace"
  endpointSelector: {}
  ingress:
    - fromEndpoints:
        - {}
  egress:
    - toEndpoints:
        - {}
← Cluster Issuer
Persistent Volumes →