Опции applyOnForward, preDNAT и doNotTrack

Чтобы понять в каких случаях вам следует применять данные параметры, мы кратко рассмотрим как изменяется обработка трафика, если их включить.

applyOnForward

Параметр applyOnForward отвечает за то, применяется ли данная политика к трафику, который проходит по цепочке iptabels FORWARD. Например, трафик, направленный к pod’у. Так как pod является внешним ресурсом с точки зрения сети хоста (не считается локальным процессом), следовательно, трафик до него проходит по маршруту цепочек PREROUTING – FORWARD – POSTROUTING.

Если applyOnForward имеет значение false, GlobalNetworkPolicy к трафику для локальных workload (контейнер/pod/ВМ, которые имеют свои виртуальные интерфейсы) не применится. Она будет применяться только к трафику для локальных процессов и к трафику, исходящему от них. Пример приведу далее.

Если applyOnForward имеет значение true, GlobalNetworkPolicy также применяется к перенаправленному (forwarded) трафику, такому как:

* Трафик, который поступает через HostEndpoint и перенаправляется в локальные workload.
* Трафик из локальных workload, который перенаправляется черезHostEndpoint.
* Трафик, который поступает черезHostEndpointи пересылается на другой HostEndpoint.

По умолчанию applyOnForward имеет значение false. Для политик, использующих опции doNotTrack и preDNAT, для свойства applyOnForward должно быть установлено значение true, поскольку эти политики применяются ко всему трафику, проходящему через FORWARD.

По умолчанию пересылаемый трафик (FORWARD)разрешен, если к пункту его назначения или направлению не применены какие-либо политики. Иначе говоря: если у вас настроен HostEndpoint, но нет политик с параметром applyOnForward: true для этого HostEndpoint или направления трафика, то пересылаемый трафик будет разрешен. Если существуют политики applyOnForward:true, в которых упоминаются селекторы HostEndpoint или это направление, но никакие правила в политиках не разрешают трафик, трафик отклоняется.

Пример: вы создаете GlobalNetworkPolicy, разрешающую исходящий трафик по протоколу ICMP для данного HostEndpoint с applyOnForward:false. В этом случае, если вы попытаетесь сделать ping 8.8.8.8 из pod’а на данном хосте, вам это удастся, так как forwarded трафик по умолчанию разрешен, хотя GNP применилась только к локальному трафику. Но. Если вы создадите ещё одну политику для этого HostEndpoint, но уже с applyOnForward:true, например, вы разрешаете весь TCP-трафик, то ping 8.8.8.8 изнутри пода не пройдет. Потому что уже существует политика с applyOnForward:true для этого типа трафика (этого HostEndpoint) и этот тип трафика явно не разрешен.

preDNAT

Данная опция отвечает за то, применяется ли политика до прохождения через DNAT (Destination Network Address Translation) или нет.

Это может пригодится, например, если вы используйте NodePorts и хотите контролировать трафик, который приходит извне на эти порты. После того, как трафик извне приходит на NodePort его распределение по факту происходит при помощи DNAT (kube-proxy). Следовательно, для того, чтобы применить политику к трафику, приходящему на NodePort, preDNAT должен быть установлен в true.

Ключевые особенности для таких политик следующие:

* Политики с опцией preDNAT могут иметь правила только для входящего трафика, но не исходящего.
* Политика применяется для всего трафика, проходящего через host endpoint, не только к процессам на хосте, но и к локальным workload (pod/VM/container).
* По умолчанию весь preDNAT трафик разрешен. То есть если существует HostEndpoint, но для него нет preDNAT политик, для него не действует правило “отбрасывать все по умолчанию”.

*️⃣4/6: продолжение следует :)

#лонгрид

doNotTrack

Опция doNotTrack позволяет отключить отслеживание (conntrack) трафика, который попадает под данную политику, причем именно для локальных процессов хоста (не pod / VM / container).

conntrack — это опция ядра из сетевого стека Linux, которая помогает ему отслеживать сетевые потоки, чтобы была возможность обрабатывать пакеты из одного потока одинаково, на основании правила обработки выбранного для первого пакета из потока.

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

* Если вам необходимо одновременно обрабатывать активных соединений больше, чем установленное значение в таблице conntrack (больше 128k по умолчанию).
* Если вам необходимо обрабатывать большое количество коротких соединений в секунду. Так как даже после завершения соединения conntrack продолжает отслеживать соединение в течении некоторого времени (по умолчанию 120с). Например, если в таблице conntrack установлено значение на 128к доступных подключений, и вы пытаетесь обрабатывать 1100 соединений в секунду, лимит будет исчерпан, даже если эти подключения очень кратковременные (128k / 120s = 1092 connections/s ).

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

Так как для активации doNotTrack политика должна примениться в самом начале цепочек OUTPUT и PREROUTING, она действует раньше других (тех, для которых doNotTrack:false), вне зависимости от её order. То есть одна политика без doNotTrack может иметьorder:1, а другая с doNotTrack может иметь order:1000, но раньше подействует политика с doNotTrack. Порядок оrder соблюдается только между политиками данного типа.

*️⃣5/6: продолжение следует :)

#лонгрид

У вас есть Agile и нет DevOps? У вас нет Agile 🤷‍♂️

Многие компании, разрабатывающие свои digital-продукты, уверены, что работают по Agile. Станислав Тибекин, CVO компании Nixys, рассказал, почему сегодня невозможно существование Agile без DevOps.

➡️ Приятного чтения!

#статья_Nixys

Сегодня последняя пятница июля, а значит — С ДНЕМ СИСТЕМНОГО АДМИНИСТРАТОРА ВСЕХ ПРИЧАСТНЫХ! 🥳

В честь праздника мы сделали подборку интересных статей с Хабра про системное администрирование!

Для начинающих:

▪️«Как стать системным администратором — пособие для начинающих» (часть 1, часть 2) — статьи для начинающих системных администраторов, помощников системных администраторов и т.д. Опытным администраторам будет если и интересно, то бесполезно.

▪️Статья «Системное администрирование. Начало» — мануал по организационным вопросам, связанным с системным администрированием. С чего начать, если вы только устроились на работу системным администратором.

Развлекательное:

▪️Статья «Ping из Антарктиды. Пост настоящего админа: с котиками и пингвинами» — автор работает обычным сисадмином в необычном месте: на антарктической станции. Рассказывает, чем такая работа отличается от обычной работы сисадмина, что обычно делают, как держат связь со всем остальным миром.

▪️Статья «Я ненавижу компьютеры: исповедь сисадмина» — Нет, серьезно, я их ненавижу. Они — это ломающиеся, непонятные штуки — мешанина глюков, железа и ограничивающего свободу ПО.

▪️Статья «Маленький ноутбук для системного администратора» — автор задумался о том, каким бы получился ноутбук, если бы его разрабатывали, думая не о маркетинге, а о потребностях реальных пользователей. Например, системных администраторов.

▪️Статья «Как самому за один вечер собрать минимальную ОС Linux из исходного кода» — как собрать минимальную Linux из исходного кода и запустить её у себя на компьютере. Эта ОС не позволит использовать все возможности вашего компьютера, но будет иметь главное — интерфейс командной строки.

Полезное:

▪️Туториал «Как отправлять и обрабатывать графические уведомления на bash» — как рисовать красивые графические уведомления и взаимодействовать с ними из скриптов bash. Демонстрация будет осуществляться на вполне реальной задаче — необходимо уведомить пользователя о скором истечении пароля.

Всем отличной пятницы и крутых выходных 🔥

#статьи #Хабр

Docker подробно рассказали про атрибут include — он уже сейчас доступен в Docker Compose v2.20.0 и появится в грядущем релизе Docker Desktop 4.22

🅰️ Командная строка docker поддерживает множество флагов для точной настройки контейнера и трудно запомнить их все при репликации среды. Сделать это еще сложнее, когда приложение представляет собой не отдельный контейнер, а комбинацию многих контейнеров с различными отношениями зависимостей. Именно поэтому Docker Compose быстро стал популярным инструментом.

Тем не менее, проблема сохраняется для больших приложений, использующих десятки, а может быть, и сотни контейнеров, с распределением прав собственности между несколькими командами. При использовании монорепозиториев команды часто имеют свой собственный “локальный” Docker Compose file для запуска подмножества приложения, но тогда им нужно полагаться на то, что другие команды предоставят справочный файл Compose, который определяет ожидаемый способ запуска их собственного подмножества.

Эта проблема не нова и обсуждалась в 2014 году, когда Docker Compose был совсем новым проектом. Теперь мы внедрили возможность “compose compose files” — не прошло и 10 лет! 🅱️

📌 Спецификация Compose, раздел про include

#новости

Всем DevOps! 🖖

Хочется порекомендовать отличный блог про инфраструктуру, платформы, Linux, Open Source, DevOps, Kubernetes, контейнеризацию и облака. А еще автор пишет про Python, Go и shell.

Начать знакомство можно, например, со статьи «Kubernetes Taints, Tolerations, and Understanding the PreferNoSchedule Effect» — в ней говорится про эффект PreferNoSchedule в Kubernetes и его отличия от NoExecute и NoSchedule. Есть классная схема про принцип работы PreferNoSchedule.

Еще автор иногда пишет на смежные темы, например, заметка «12 Tips for Effective Technical Blogging». Вдруг вы ведете блог или просто пишете на Хабр? Будет полезно 😎

P.S. Кстати про технические блоги и Хабр! Может, здесь есть авторы? Расскажите о своих блогах в комментариях (ТГ, Хабр, что угодно) 🙃 Почему решили вести блог? А если вы не автор, можете рассказать — что вообще думаете о технических блогах? Почему не хотите писать сами?

Ну и, конечно, делитесь — кого читаете?

#блог

Открытое исследование «Защита персональных данных 2023» 🔒

За 2022-2023 год ужесточились условия и регулирование по 152-ФЗ.

На форумах мы слышим как всё меняется, но лозунги со сцен конференций и обновление ФЗ — это одна сторона медали, а реальная практика и опыт сообщества — совсем другая.

Компания Cortel проводит открытое исследование «Защита персональных данных 2023» чтобы выяснить:

• Как эксперты на местах смотрят на ситуацию;
• Как в действительности обстоят дела с ПДн и их защитой на практике.

Пожалуйста поделитесь своим мнением и пройдите короткий опрос на 3 минуты по этой ссылке, вы очень поможете.

🛡 Результатами исследования поделятся осенью в этом канале.