Deny all: Модуль ngx_http_access_module

Существует четыре типа селекторов, которые могут быть указаны во входном из раздела или выходном в разделе:

podSelector : выбирает определенные поды в том же пространстве имен, что и NetworkPolicy, которые должны быть разрешены в качестве источников входящего или выходного адреса.

namespaceSelector : выбирает определенные пространства имен, для которых все поды должны быть разрешены в качестве источников входящего или выходного назначения.

namespaceSelector и podSelector : одна запись с по / из , которая указывает, что namespaceSelector и podSelector выбирают определенные поды в определенных пространствах имен. Будьте осторожны, чтобы использовать правильный синтаксис YAML; эта политика:

 ...
  вход:
  - из:
    - namespaceSelector:
        matchLabels:
          пользователь: Алиса
      podSelector:
        matchLabels:
          роль: клиент
  ...
  

содержит один элемент из , разрешающий подключения из модулей с меткой role = client в пространствах имен с меткой user = alice . Но это политика :

  ...
  вход:
  - из:
    - namespaceSelector:
        matchLabels:
          пользователь: Алиса
    - podSelector:
        matchLabels:
          роль: клиент
  ...
  

содержит два элемента в массиве из и разрешает соединения из модулей в локальном пространстве имен с меткой role = client , или из любого модуля в любом пространстве имен с меткой user = alice .

В случае сомнений используйте kubectl describe , чтобы узнать, как Kubernetes интерпретирует политику.

ipBlock : Выбирает определенные диапазоны IP CIDR для разрешения в качестве источников входящего или выходного назначения.Это должны быть внешние IP-адреса кластера, поскольку IP-адреса Pod эфемерны и непредсказуемы.

Механизмы входа и выхода кластера часто требуют перезаписи IP-адреса источника или назначения. пакетов. В тех случаях, когда это происходит, не определено, произойдет ли это раньше или после обработки NetworkPolicy, и поведение может отличаться для разных комбинации сетевого плагина, облачного провайдера, внедрения службы , и т. д.

В случае входящего трафика это означает, что в некоторых случаях вы можете фильтровать входящие пакеты основаны на фактическом исходном IP-адресе, а в других случаях - на «исходном IP-адресе», NetworkPolicy может использовать IP-адрес LoadBalancer или узла Pod'а и т. д.

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

Политики по умолчанию

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

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

Вы можете создать политику изоляции «по умолчанию» для пространства имен, создав NetworkPolicy, которая выбирает все модули, но не разрешает входящий трафик к этим модулям.

  ---
apiVersion: network.k8s.io/v1
вид: NetworkPolicy
метаданные:
  имя: default-deny-ingress
спецификация:
  podSelector: {}
  policyTypes:
  - Ingress
  

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

По умолчанию разрешить весь входящий трафик

Если вы хотите разрешить весь трафик для всех модулей в пространстве имен (даже если добавлены политики, которые заставляют некоторые модули обрабатываться как «изолированные»), вы можете создать политику, которая явно разрешает весь трафик в этом пространстве имен.

  ---
apiVersion: network.k8s.io/v1
вид: NetworkPolicy
метаданные:
  имя: разрешить все-вход
спецификация:
  podSelector: {}
  вход:
  - {}
  policyTypes:
  - Ingress
  

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

Вы можете создать политику изоляции исходящего трафика «по умолчанию» для пространства имен, создав NetworkPolicy, которая выбирает все модули, но не разрешает исходящий трафик из этих модулей.

  ---
apiVersion: сеть.k8s.io/v1
вид: NetworkPolicy
метаданные:
  имя: default-deny-egress
спецификация:
  podSelector: {}
  policyTypes:
  - Выход
  

Это гарантирует, что даже модули, не выбранные какой-либо другой NetworkPolicy, не получат исходящего трафика. Эта политика не изменить поведение изоляции входящего трафика по умолчанию.

По умолчанию разрешить весь исходящий трафик

Если вы хотите разрешить весь трафик от всех модулей в пространстве имен (даже если добавлены политики, которые заставляют некоторые модули обрабатываться как «изолированные»), вы можете создать политику, которая явно разрешает весь исходящий трафик в этом пространстве имен.

  ---
apiVersion: network.k8s.io/v1
вид: NetworkPolicy
метаданные:
  имя: allow-all-egress
спецификация:
  podSelector: {}
  выход:
  - {}
  policyTypes:
  - Выход
  

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

Вы можете создать политику «по умолчанию» для пространства имен, которая предотвращает весь входящий И исходящий трафик, создав следующую NetworkPolicy в этом пространстве имен.

  ---
apiVersion: сеть.k8s.io/v1
вид: NetworkPolicy
метаданные:
  имя: по умолчанию-запретить-все
спецификация:
  podSelector: {}
  policyTypes:
  - Ingress
  - Выход
  

Это гарантирует, что даже модули, не выбранные какой-либо другой NetworkPolicy, не получат входящий или исходящий трафик.

Поддержка SCTP

СОСТОЯНИЕ ФУНКЦИИ: Kubernetes v1.20 [стабильный]

В качестве стабильной функции эта функция включена по умолчанию. Чтобы отключить SCTP на уровне кластера, вам (или администратору кластера) необходимо отключить шлюз функции SCTPSupport для сервера API с помощью --feature-gates = SCTPSupport = false,… .Когда шлюз функций включен, вы можете установить в поле протокола NetworkPolicy значение SCTP .

Примечание. Вы должны использовать подключаемый модуль CNI, поддерживающий протокол SCTP NetworkPolicies.

Ориентация на диапазон портов

СОСТОЯНИЕ ФУНКЦИИ: Kubernetes v1.21 [альфа]

При написании NetworkPolicy вы можете указать диапазон портов вместо одного порта.

Это достижимо с использованием поля endPort , как в следующем примере:

  apiВерсия: сеть.k8s.io/v1
вид: NetworkPolicy
метаданные:
  имя: multi-port-egress
  пространство имен: по умолчанию
спецификация:
  podSelector:
    matchLabels:
      роль: db
  policyTypes:
  - Выход
  выход:
  - к:
    - ipBlock:
        cidr: 10.0.0.0/24
    порты:
    - протокол: TCP
      порт: 32000
      endPort: 32768
  

Приведенное выше правило позволяет любому Pod с меткой db в пространстве имен по умолчанию взаимодействовать с любым IP в диапазоне 10.0.0.0/24 по TCP, при условии, что целевой порт находится в диапазоне от 32000 до 32768 .

При использовании этого поля действуют следующие ограничения:

• Как альфа-функция, по умолчанию отключена. Чтобы включить поле endPort на уровне кластера, вам (или администратору кластера) необходимо включить шлюз функций NetworkPolicyEndPort для сервера API с --feature-gates = NetworkPolicyEndPort = true,… .
• Поле endPort должно быть равно или больше поля порта .
• endPort может быть определен, только если также определен порт .
• Оба порта должны быть числовыми.

Примечание: Ваш кластер должен использовать подключаемый модуль CNI, который поддерживает поле endPort в спецификациях NetworkPolicy.

Таргетинг на пространство имен по его имени

СОСТОЯНИЕ ФУНКЦИИ: Kubernetes 1.21 [бета]

Плоскость управления Kubernetes устанавливает неизменяемую метку kubernetes.io/metadata.name на всех пространства имен при условии, что NamespaceDefaultLabelName функция ворота включена.Значение метки - это имя пространства имен.

Хотя NetworkPolicy не может настроить таргетинг на пространство имен по его имени с каким-либо полем объекта, вы можете использовать стандартизированная метка для определенного пространства имен.

Чего нельзя делать с сетевыми политиками (по крайней мере, пока)

Начиная с Kubernetes 1.21, в API NetworkPolicy нет следующих функций, но вы можете реализовать обходные пути с помощью компонентов операционной системы (таких как SELinux, OpenVSwitch, IPTables и т. Д.) Или технологий уровня 7 (контроллеры Ingress, Реализации Service Mesh) или контроллеры допуска.Если вы новичок в сетевой безопасности в Kubernetes, стоит отметить, что следующие истории пользователей (пока) не могут быть реализованы с использованием NetworkPolicy API.

• Принудительное прохождение внутреннего трафика кластера через общий шлюз (лучше всего это обслужить с помощью служебной сети или другого прокси).
• Все, что связано с TLS (используйте для этого служебную сетку или входной контроллер).
Политики для конкретных узлов
• (для них можно использовать нотацию CIDR, но нельзя нацеливать узлы специально на их идентификаторы Kubernetes).
• Таргетинг служб по имени (однако вы можете настроить таргетинг на поды или пространства имен по их меткам, что часто является жизнеспособным решением).
• Создание или управление «запросами политики», выполняемыми третьей стороной.
• Политики по умолчанию, которые применяются ко всем пространствам имен или подам (есть некоторые сторонние дистрибутивы и проекты Kubernetes, которые могут это делать).
• Расширенный инструментарий запросов и доступности политик.
• Возможность регистрировать события сетевой безопасности (например, заблокированные или принятые соединения).
• Возможность явно отклонять политики (в настоящее время модель для NetworkPolicies по умолчанию запрещает, с возможностью только добавлять разрешающие правила).
• Возможность предотвращения обратной петли или входящего трафика хоста (в настоящее время модули не могут блокировать доступ к локальному хосту, а также не имеют возможности блокировать доступ со своего резидентного узла).

Что дальше

CCNA: Явное запрещение всего

Одним из ключевых фактов, касающихся списков контроля доступа (ACL), которые мы вдалбливаем в вашу голову во время CCNA, является тот факт, что списки, которые вы создаете, заканчиваются так называемым «неявным» запретом всего.Вы этого не видите, но эффект неоспоримый. Любые пакеты, которые не соответствуют ни одному из разрешений в вашем списке, обрабатываются с отклонением. В случае наших списков доступа для фильтрации это означает, что пакеты отбрасываются. Как вы помните из курса, именно поэтому нам отчаянно требуется хотя бы одна запись о разрешении во всех наших списках управления доступом для фильтрации.

Но что, если мы хотим отследить, что мы на самом деле теряем в результате этого мощного неявного эффекта запрета всего? Что ж, хитрый трюк - закончить список явным заявлением deny и записать результат.В этом посте мы рассмотрим эту технику.

Давайте создадим именованный стандартный список управления доступом, который разрешит получение пакетов из адресного пространства 10.x.x.x.

 стандартный список доступа IP AL_PERMIT_10 
 разрешение 10.0.0.0 0.255.255.255 

Теперь я применю этот ACL для входящего трафика к интерфейсу маршрутизатора и сгенерирую некоторый трафик, соответствующий этому утверждению. Когда мы запускаем команду show access-lists, мы можем видеть по «счетчику посещений», что разрешение обнаружило некоторые совпадения. Но как насчет неудачных пакетов?

 R1 (config-std-nacl) #int fa0 / 0 
 R1 (config-if) #ip access-group AL_PERMIT_10 in 
 R1 (config-if) #end 
 R1 # 
 R1 # show access-lists 
 Standard IP список доступа AL_PERMIT_10 
 10 разрешение 10.0.0.0, подстановочные биты 0.255.255.255  (57 совпадений)  

Чтобы получать предупреждения о пакетах, которые попадают в неявный запрет всех, нам нужно создать явный. Если нас действительно беспокоят пакеты, которые не соответствуют никаким разрешениям, мы можем добавить параметр журнала, чтобы мы могли получать уведомления в командной строке, в дополнение к уведомлению, когда мы выполняем команду show access-list.

 R1 (config) #ip access-list standard AL_PERMIT_10 
 R1 (config-std-nacl) # Deny any log 

После этого изменения конфигурации посмотрите, что произойдет, когда кто-то из 1.1.1.1 пытается подключиться к R1 через наш интерфейс:

 R1 # 
  * 1 марта 00: 12: 23.251:% SEC-6-IPACCESSLOGNP: список AL_PERMIT_10 запрещен 0 1.1.1.1 -> 10.0.0.1, 1 пакет  
 R1 # показать списки доступа 
 Стандартный список доступа IP AL_PERMIT_10 
 10 разрешить 10.0.0.0, подстановочные биты 0.255.255.255 (117 совпадений) 
 20 запретить любой журнал  (5 совпадений)  

Один вопрос, который я часто получаю от студентов в этот момент: почему мы получили только одно уведомление (об одном пакете) через системное сообщение командной строки, но на самом деле было заблокировано 5 пакетов (как показано в выходных данных команды show )?

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

Надеюсь, вам нравится изучение CCNA здесь, в INE!

kubernetes-network-policy-recipes / 12-deny-all-non-whitelisted-traffic-from-the-namespace.md at master · ahmetb / kubernetes-network-policy-recipes · GitHub

💡 Пример использования: Это основная политика, блокирующая все исходящие (исходящие) трафик из пространства имен по умолчанию (включая разрешение DNS).После развертывания это позволяет развернуть сетевые политики, разрешающие определенный исходящий трафик.

Рассмотрите возможность применения этого манифеста к любому пространству имен, в котором развертываются рабочие нагрузки. (кроме кубе-система ).

💡 Лучшая практика: Эта политика предоставит вам по умолчанию «запретить все» функциональность. Таким образом, вы можете четко определить, какие компоненты имеют зависимости от того, какие компоненты и развертывают сетевые политики, которые могут быть переведены в графы зависимостей между компонентами.

Манифест

 вид: NetworkPolicy
apiVersion: network.k8s.io/v1
метаданные:
  имя: default-deny-all-egress
  пространство имен: по умолчанию
спецификация:
  policyTypes:
  - Выход
  podSelector: {}
  выход: [] 

Обратите внимание на этот манифест:

• пространство имен: по умолчанию развернуть эту политику в пространство имен по умолчанию .
• podSelector: пуст, это означает, что он будет соответствовать всем модулям. Следовательно, политика будет применяться ко ВСЕМ модулям в пространстве имен по умолчанию .
• Список исходящих правил представляет собой пустой массив: это вызывает весь трафик (включая DNS-разрешение), которое будет удалено, если оно исходит от модулей в по умолчанию .

Сохраните этот манифест в default-deny-all-egress.yaml и примените:

 $ kubectl apply -f default-deny-all-egress.yaml
networkpolicy "default-deny-all-egress" создан 

Очистка

  kubectl удалить networkpolicy default-deny-all-egress
  

Запретить все, разрешить некоторые | InfoWorld

Корпоративные сети сталкиваются с большим количеством угроз безопасности, чем когда-либо прежде. Будь то безудержное распространение вредоносных программ, злонамеренных сотрудников или простая и простая ошибка пользователей, ИТ-администраторы должны отступить, чтобы гарантировать, что злоумышленники останутся снаружи, а корпоративные данные останутся внутри.Существует множество инструментов, которые помогут вам защитить ваши данные, но одна простая политика - независимо от того, на какую часть вашей инфраструктуры вы изучаете - всегда будет защищать вас больше, чем любое отдельное оборудование или программное обеспечение безопасности: запретить все, разрешить некоторые.

Недавнее напоминание о ценности этой политики пришло ко мне, когда организация, с которой я работаю, была поражена новым червем нулевого дня. В течение нескольких часов в течение выходных значительная часть компьютеров с Windows в сети была заражена. Почти весь следующий понедельник прошел до того, как стали доступны сигнатуры обнаружения вирусов, которые распознают червя и его полезную нагрузку, и был достигнут реальный прогресс в борьбе с ним.

[Эффективная безопасность на уровне данных имеет решающее значение для борьбы с экспоненциальным ростом информации. Посетите iGuide Enterprise Data Explosion от InfoWorld для получения дополнительной информации. ]

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

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

В конце концов, множество мер безопасности, включая хорошо настроенную IPS, фильтр содержимого, политику безопасности рабочего стола и антивирусное программное обеспечение, было обнаружено простым правилом «запретить любое» в нижней части списка доступа на внутренний интерфейс межсетевого экрана. Это серьезная пища для размышлений. Иногда самые простые действия, которые вы можете сделать для защиты вашей сети, имеют наибольшее влияние.

Включить запрет по умолчанию для модулей Kubernetes

Переключить навигацию

  apiVersion: projectcalico.org/v3
вид: GlobalNetworkPolicy
метаданные:
  имя: default-deny
спецификация:
  селектор: все ()
  типы:
  - Ingress
  - Выход
  

  apiВерсия: projectcalico.org / v3
вид: GlobalNetworkPolicy
метаданные:
  имя: deny-app-policy
спецификация:
  namespaceSelector: имеет (projectcalico.org/name) && projectcalico.org/name не в {"kube-system", "calico-system"}
  типы:
  - Ingress
  - Выход
  выход:
  # разрешить всем пространствам имен взаимодействовать с модулями DNS
  - действие: Разрешить
    протокол: UDP
    назначения:
      селектор: 'k8s-app == "kube-dns"'
      порты:
      - 53
  

  apiVersion: projectcalico.org/v3
вид: NetworkPolicy
метаданные:
  имя: default-deny
  пространство имен: инженерия
спецификация:
  селектор: все ()
  типы:
  - Ingress
  - Выход