Forwarded from linkmeup
Forwarded from Технологический Болт Генона
Извините, но мы продолжаем 🌝
Ссылка на запрос для получения списка действий пользователя на GitHub
https://play.clickhouse.com/play?user=play#U0VMRUNUICogRlJPTSBnaXRodWJfZXZlbnRzIFdIRVJFIGFjdG9yX2xvZ2luPSdKaWFUNzUnIE9SREVSIEJZIGZpbGVfdGltZSBERVND
Там возвращается не всё, потому что были собраны данные об активности и выяснилось, что первые странные действия этого пользователя появились ещё в 2021 году
Everything I Know About the Xz Backdoor
https://boehs.org/node/everything-i-know-about-the-xz-backdoor
Ссылка на запрос для получения списка действий пользователя на GitHub
https://play.clickhouse.com/play?user=play#U0VMRUNUICogRlJPTSBnaXRodWJfZXZlbnRzIFdIRVJFIGFjdG9yX2xvZ2luPSdKaWFUNzUnIE9SREVSIEJZIGZpbGVfdGltZSBERVND
Там возвращается не всё, потому что были собраны данные об активности и выяснилось, что первые странные действия этого пользователя появились ещё в 2021 году
The first commits they make are not to xz, but they are deeply suspicious. Specifically, they open a PR in libarchive: Added error text to warning when untaring with bsdtar. This commit does a little more than it says. It replaces safe_fprint with an unsafe variant, potentially introducing another vulnerability. The code was merged without any discussion, and lives on to this day (patched).
Everything I Know About the Xz Backdoor
https://boehs.org/node/everything-i-know-about-the-xz-backdoor
https://youtube.com/playlist?list=PLJcGJBfGQVIjy5CJ8tjnPJImDMymWBEo0&si=nN_8MdSDrIXgg8QH
Курс лекций по Операционным Системам
#OS
Курс лекций по Операционным Системам
#OS
Forwarded from Кубертатный период (Pavel Klyuev)
Челик проходил интервью в Google на позицию Senior Site Reliability Engineer, SE (System Engineering) и любезно записал все вопросы и ответы на них с рассуждениями
https://prepare.sh/engineering/devops/google/
Там есть и другие интервью на другие позиции
https://prepare.sh/engineering/devops/google/
Там есть и другие интервью на другие позиции
prepare.sh
Latest Real Interview Questions & Interactive Labs | Prepare.sh
Discover real interview questions from top companies and prepare with our interactive labs at Prepare.sh. Stay ahead with expert insights and comprehensive preparation tools.
Forwarded from linkmeup
На случай если вам скучно и вдруг захочется почитать про организацию в линуксе замудрённого page cache.
https://biriukov.dev/docs/page-cache/0-linux-page-cache-for-sre/
https://biriukov.dev/docs/page-cache/0-linux-page-cache-for-sre/
Viacheslav Biriukov
Linux Page Cache for SRE
SRE deep dive into Linux Page Cache # In this series of articles, I would like to talk about Linux Page Cache. I believe that the following knowledge of the theory and tools is essential and crucial for every SRE. This understanding can help both in usual…
Forwarded from linkmeup
Безбожники запихали Doom в htop.
Кому мерзость, но покажите ещё, можно посмотреть самому https://github.com/0x0mer/doom-htop
Кому мерзость, но покажите ещё, можно посмотреть самому https://github.com/0x0mer/doom-htop
rsync
article 1: Scenarios https://michael.stapelberg.ch/posts/2022-06-18-rsync-article-1-scenarios/
article 2: Surroundings https://michael.stapelberg.ch/posts/2022-07-02-rsync-surroundings/
article 3: How does rsync work?
https://michael.stapelberg.ch/posts/2022-07-02-rsync-how-does-it-work/
#rsync
article 1: Scenarios https://michael.stapelberg.ch/posts/2022-06-18-rsync-article-1-scenarios/
article 2: Surroundings https://michael.stapelberg.ch/posts/2022-07-02-rsync-surroundings/
article 3: How does rsync work?
https://michael.stapelberg.ch/posts/2022-07-02-rsync-how-does-it-work/
#rsync
Michael Stapelberg
rsync, article 1: Scenarios
This post is the first article in a series of blog posts about rsync, see the Series Overview.
To motivate why it makes sense to look at rsync, I present three scenarios for which I have come to appreciate rsync: DokuWiki transfers, Software deployment and…
To motivate why it makes sense to look at rsync, I present three scenarios for which I have come to appreciate rsync: DokuWiki transfers, Software deployment and…
Forwarded from DOFH - DevOps from hell
Пример ненадёжности хеш функций:
Разница строк - в одном бите.
#ЗпН
%
echo -n TEXTCOLLBYfGiJUETHQ4hAcKSMd5zYpgqf1YRDhkmxHkhPWptrkoyz28wnI9V0aHeAuaKnak | md5sum
faad49866e9498fc1719f5289e7a0269 -
% echo -n TEXTCOLLBYfGiJUETHQ4hEcKSMd5zYpgqf1YRDhkmxHkhPWptrkoyz28wnI9V0aHeAuaKnak | md5sum
faad49866e9498fc1719f5289e7a0269
-
Разница строк - в одном бите.
#ЗпН
Forwarded from linkmeup
Ребятки решили сделать разным CNI больно и запустили тест на 40 Гбит/с ибо интересно же, кто что может выдать в 2024.
Самое интересное на мой взгляд:
- Без eBPF забудь про многопоточку
- Универсального комбайна, который хорошо молотит любой вид нагрузки, так и не изобрели
- Свои варианты применения есть и у куброутера, и у силиума, и калико, и так далее. Просто не надо брать бездумно по названию
https://itnext.io/benchmark-results-of-kubernetes-network-plugins-cni-over-40gbit-s-network-2024-156f085a5e4e
Самое интересное на мой взгляд:
- Без eBPF забудь про многопоточку
- Универсального комбайна, который хорошо молотит любой вид нагрузки, так и не изобрели
- Свои варианты применения есть и у куброутера, и у силиума, и калико, и так далее. Просто не надо брать бездумно по названию
https://itnext.io/benchmark-results-of-kubernetes-network-plugins-cni-over-40gbit-s-network-2024-156f085a5e4e
Medium
Benchmark results of Kubernetes network plugins (CNI) over 40Gbit/s network [2024]
This article is a new run of my previous benchmark (2020, 2019 and 2018), now running Kubernetes 1.26 and Ubuntu 22.04 with CNI version…
Forwarded from k8s (in)security (r0binak)
Если вам захотелось посмотреть как выглядит ваш
По сути это небольшой
ETCD
внутри, то инструмент ETCD Keeper может с этим помочь.По сути это небольшой
web ETCD client
с возможностью просматривать, добавлять, обновлять или удалять ноды, а также сами ключи и их значения. Есть поддержка как v2
так и v3
версии.https://ymmt2005.hatenablog.com/entry/2019/08/10/Writing_and_testing_Kubernetes_webhooks_using_Kubebuilder_v2
#k8s #kubernetes #webhook #tresting
#k8s #kubernetes #webhook #tresting
Blog of @ymmt2005
Writing and testing Kubernetes webhooks using Kubebuilder v2 - Blog of @ymmt2005
Recently, I am leading a project to re-design our on-premise data centers using Kubernetes. Inevitably there are opportunities to develop Kubernetes native appl…
Forwarded from Bash Days | Linux | DevOps (Роман Шубин)
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Нарыл (Pavel Sorokin)
Есть такая общеизвестная проблема когда делаешь non-root в k8s: контейнерам нужно биндить порты до 1024, что по умолчанию в Linux запрещено.
Лично по-моему само по себе такое ограничение - архитектурная ошибка в Linux, которая привела к куче проблем и сложностей: сервису, например nginx, нужно стартовать от рута, забиндить порт, а потом дропнуть лишние привилегии. Что уже само по себе звучит не безопасно и разумеется приводило к множеству LPE. А профит с точки зрения ИБ крайне сомнительный. Может быть он был когда на одном сервере одновременно крутился важный сайт на 80 порту и еще сидели руками какие-то непривилегированные пользователи, но сейчас это кажется бесполезным чуть более чем полностью (попробуйте меня переубедить :D)
Параметр ядра net.ipv4.ip_unprivileged_port_start позволяет управлять этим поведением в Linux. Если его установить в значение 0, то любому пользователю будет доступен биндинг любых портов. Параметр net.ipv4.ip_unprivileged_port_start относится к сетевому неймспейсу и у каждого контейнера свой.
При внедрении non-root можно добавлять securityContext.sysctls (net.ipv4.ip_unprivileged_port_start=0) в манифесты, но это требует модификации всех манифестов.
И вот я тут обнаружил что есть другой путь - в конфиге containerd есть опция enable_unprivileged_ports, которая устанавливает net.ipv4.ip_unprivileged_port_start в 0 для всех создаваемых контейнеров.
Другими словами можно поменять один параметр на всех нодах и не возиться с манифестами.
Лично по-моему само по себе такое ограничение - архитектурная ошибка в Linux, которая привела к куче проблем и сложностей: сервису, например nginx, нужно стартовать от рута, забиндить порт, а потом дропнуть лишние привилегии. Что уже само по себе звучит не безопасно и разумеется приводило к множеству LPE. А профит с точки зрения ИБ крайне сомнительный. Может быть он был когда на одном сервере одновременно крутился важный сайт на 80 порту и еще сидели руками какие-то непривилегированные пользователи, но сейчас это кажется бесполезным чуть более чем полностью (попробуйте меня переубедить :D)
Параметр ядра net.ipv4.ip_unprivileged_port_start позволяет управлять этим поведением в Linux. Если его установить в значение 0, то любому пользователю будет доступен биндинг любых портов. Параметр net.ipv4.ip_unprivileged_port_start относится к сетевому неймспейсу и у каждого контейнера свой.
При внедрении non-root можно добавлять securityContext.sysctls (net.ipv4.ip_unprivileged_port_start=0) в манифесты, но это требует модификации всех манифестов.
И вот я тут обнаружил что есть другой путь - в конфиге containerd есть опция enable_unprivileged_ports, которая устанавливает net.ipv4.ip_unprivileged_port_start в 0 для всех создаваемых контейнеров.
Другими словами можно поменять один параметр на всех нодах и не возиться с манифестами.
Forwarded from GitHub'ненько
Robusta KRR
Robusta KRR (Kubernetes Resource Recommender) is a CLI tool for optimizing resource allocation in Kubernetes clusters. It gathers pod usage data from Prometheus and recommends requests and limits for CPU and memory. This reduces costs and improves performance.
#k8s #devops #cloud #resources
https://github.com/robusta-dev/krr
Robusta KRR (Kubernetes Resource Recommender) is a CLI tool for optimizing resource allocation in Kubernetes clusters. It gathers pod usage data from Prometheus and recommends requests and limits for CPU and memory. This reduces costs and improves performance.
#k8s #devops #cloud #resources
https://github.com/robusta-dev/krr