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/

https://snips.sh/
https://github.com/robherley/snips.sh
#github #pastebin #ssh

https://github.com/bach-sh/bach
#bash #testing #github

ssh на стеройдах
https://github.com/moul/assh

https://gist.github.com/mcastelino/b8ce9a70b00ee56036dadd70ded53e9f#cpu-resource-management
#k8s #cgroups #cpu #gist #github