Забавный датасет в формате API на тему "Рика и Морти"

Есть доступ через REST и GraphQL.

ИМХО можно использовать в примерах и hello world приложениях в качестве "какого-нибудь API"

https://rickandmortyapi.com/

Kube-apiserver в роли port scanner

Всем привет!

Еще одна потрясающая статья от Rory McCune, посвященная «своеобразному» использованию возможностей Kubernetes. Нет, это не уязвимость, это не bug, это не ошибка.

Kubernetes устроен таким образом, что он может осуществлять сетевые запросы на внешние адреса в некоторых ситуациях. Например, в случае с Validating Webhooks. Таким образом можно реализовать некий аналог SSRF и превратить Kubernetes в «сканер портов».

Rory проделал следующее:
🍭 Создается namespace
🍭 Регистрируется webhook. Никакой сервер, обрабатывающий запрос не регистрируется. Вместо этого указывается потенциальная «жертва»
🍭 Создается pod в указанном namespace. Готово! В сообщении об ошибки получаем всю необходимую информацию

PoC того, что описано выше можно найти в repo. Если интересно посмотреть небольшую демонстрацию, ее можно найти в блоге Rory.

P.S. Лучше не проверять этот, пусть и крайне базовый PoC на каких-либо настоящих сервисах и/или в production-окружениях.

В рамках изучения Cilium Service Mesh и Istio Ambient Mesh (прошлые посты 1,2) я наткнулся на занимательную статью "Exploring Cilium Layer 7 Capabilities Compared to Istio". Там сравниваются не Service Mesh реализации, а L7 возможности стандартного CNI Cilium (v1.12) и sidecar реализации Istio. И из этой статьи можно узнать много всего интересного о деталях реализации CNI Cilium и Istio, а именно:
- L7 фильтрация в ресурсе CiliumNetworkPolicy реализована как расширение/фильтр (Cilium.L7Policy) для Envoy proxy
- Как выглядит/хранится L7 правило внутри CNI Cilium
- CNI Cilium использует для этого Envoy filter, а Istio использует RBAC filters из апстрима Envoy
- чем является identity в Cilium, как он вычисляется (база это IP, labels) и хранится (это никакой не криптографический приметив, а просто целое число). А в Istio для этого служит service account token - там вообще все сроиться вокруг сертификатов, что как вы понимаете надежнее

Также там поднимается вопрос/проблема, что при модели Envoy per Node ресурсов потребляется меньше, но в случае его отказа страдают сразу все микросервисы на Node. Есть и еще одна интересная проблема с Network cache-based identity, что как я написал выше используется в Cilium, но это заслуживает отдельной заметки ;)

Еще одно достойное применение ИИ - написание регулярок вместо меня.

https://regex.ai/

https://tech.aabouzaid.com/2022/11/set-openapi-patch-strategy-for-kubernetes-custom-resources-kustomize.html?m=1
#kustomize #patch

- Спокойно запускаете DEV и PROD окружения в одном кластере?
- Уверены что ваши namespaces хорошо изолированы друг от друга?
- Собственными руками организовали multitenancy уровня Namespaces as a Service?

Специально для проверки качества таких реализаций и был создан Multi-Tenancy Benchmarks. А к нему в придачу для автоматизации проверки плагин для kubectl под названием kubectl-mtb.

Так все проверки разбиты на 2 класса:
- Configuration Checks (CC)
- Behavioral Checks (BC)

К сожалению, 7 проверок из 23 так и не автоматизировали. НО их можно подсмотреть в документации проекта Capsule и дописать или сделать ручками ;)

Гайд как записывать консольные демо без боли и страданий

https://martinheinz.dev/blog/94

https://www.puzzle.ch/de/blog/articles/2021/12/16/cilium-host-policies
#cilium #host #policies

Auto-Updating VM OS Base Images with KubeVirt’s Containerised Data… – Miscellaneous Knowledge
https://blog.kingj.net/2022/06/02/how-to/auto-updating-vm-os-base-images-with-kubevirts-containerised-data-importer/

#kubevirt

Хорошо проиллюстрированная статья "Kubernetes: Security Contexts", объясняющая назначение, специфику и отличия Pod Security Context и Security Context.

В официальной документации этому вопросу посвящен раздел "Configure a Security Context for a Pod or Container".

🛠 SSHLog - инструмент для логирования (и мониторинга в реальном времени) всей активности пользователя после установки им SSH подключения...

https://github.com/sshlog/agent

Реализовано всё с помощью eBPF. Авторы позаботились, и собрали пакеты для популярных дистрибутивов. Достаточно просто добавить репозиторий и установить из него необходимое.

#ssh #security #logs

Отличная статья про балансировку и разные алгоритмы балансировки. Еще и с анимацией!

https://samwho.dev/load-balancing/

https://github.com/Textualize/frogmouth
#github #md #markdown #viewer

На днях ко мне пришёл коллега с интересным вопросом, для понимания которого придётся начать издалека.

Вот есть у нас в кубере securityContext и можно в нём выставлять списочек всяких линуксовых capabilies, ну знаете, setuid, setowner, setpcap... Все наши, короче.

И есть задача давать контейнерам одного публичного приложения только те capabilities, которые ему нужны, а те, что не нужны - отобрать. Делается это всё, традиционно, helm чартом от мейнтейнеров приложения. Чарт нормальный и в нём есть нужная шаблонизация и вот такой объект в values.yaml:

securityContext:
allowPrivilegeEscalation: false
readOnlyRootFilesystem: false
runAsNonRoot: true
privileged: false
capabilities:
drop:
- ALL

Но нам-то надо не только отобрать, но ещё и добавить, поэтому коллега дописывает сюда нужных нам вещей, в результате чего готовый объект в values.yaml становится вот таким:

securityContext:
capabilities:
drop:
- ALL
add:
- CHOWN
- DAC_OVERRIDE
- FOWNER
- SETFCAP
- SETGID
- SETUID

Потом он запускает helm с dry-run, после чего и приходит ко мне, чтобы задать свой вопрос: "А вот смотри, я всегда считал, что drop и add тут должны идти в правильном порядке и ставить сперва add, потом drop нельзя. Ведь затрёт же. А хелм наш на этот блок делает toYaml и у него ключи сортируются по алфавиту, потому в манифест прилетает сперва add, потом drop. Что делать?"
И правда, в итоговом манифесте это выглядит вот так:

securityContext:
capabilities:
add:
- CHOWN
- DAC_OVERRIDE
- FOWNER
- SETFCAP
- SETGID
- SETUID
drop:
- ALL

Документация кубернетиса на этот счёт не говорит ничего внятного, зато в интернете хватает статей, сообщающих в разных вариация, что:

Here the order is very important, if you first provide the add field and then later provide the drop ALL field then all the capabilities would be dropped from the container. So, make sure you use drop first followed by add.

Из-за этого мы несколько приуныли, ведь вечер только что резко перестал быть томным, и пошли выяснять, как дела обстоят на самом деле.
Так вот, если вдруг вы когда-нибудь зададитесь таким вопросом и пойдёте читать интернет, то знайте: НЕКОТОРЫЕ ЧЕРЕПАШКИ ПИЗДЯТ.
На самом деле API кубера глубоко поебать на порядок ключей в capabilities, он сперва делает drop, а потом уже add.

Такая вот хуйня, ребятки, верить нынче нельзя никому (но мне можно).

https://music.yandex.ru/album/5792882/track/43516266

Оказывается, уже во всю используется новый типа DNS записи SVCB (HTTPS). Смысл в том, что браузер сразу подключается по протоколу HTTP/3 выполняя всего один DNS запрос.

Да, этой штуке уже 3 года, но я только узнал 😊

Раньше для апрегйда на HTTP/3 сначала происходило подключение по старому протоколу и только внутри существующего коннета поднималась версия протокола, на это уходило лишнее время.

Блог Флиппера, кстати поддерживает эту DNS запись. Проверить можно так:

Для нового dig в линуксе:
dig https blog.flipperzero.one

Для старого dig в макосе:
dig -t type65 blog.flipperzero.one

https://fe.ax/diskless-drbd/
https://fe.ax/reliability-drbd/
#drbd #diskless

Не самые популярные но полезные HTTP коды

https://blog.frankel.ch/leverage-richness-http-status-codes/