Forwarded from k8s (in)security (Дмитрий Евдокимов)
01_Kubernetes,_ответь_мне,_кто_я_для_тебя,_Константин_Аксенов,_Флант.pdf
2.4 MB
"Kubernetes, ответь мне, кто я для тебя", Константин Аксенов, Флант
02_Не_такой_очевидный_RBAC_Kubernetes,_Дмитрий_Евдокимов,_Luntry.pdf
1.9 MB
"Не такой очевидный RBAC Kubernetes", Дмитрий Евдокимов, Luntry
03_Как_приручить_Linux_capabilities_в_Kubernetes,_Николай_Панченко.pdf
5.8 MB
"Как приручить Linux capabilities в Kubernetes", Николай Панченко, Тинькофф
04_Контейнерная_ОС_Flatcar_как_обмазаться_докерами_и_забыть_про.pdf
2.2 MB
"Контейнерная ОС Flatcar: как обмазаться докерами и забыть про пакеты", Александр Кондратьев, BI.ZONE
05_NetworkPolicy_для_системных_и_инфраструктурных_компонент,_Александр.pdf
1.6 MB
"NetworkPolicy для системных и инфраструктурных компонент", Александр Кожемякин, VK
06_OPA_с_shared_Docker_executor,_Павел_Сорокин,_OZON.pdf
12.4 MB
"OPA с shared Docker executor", Павел Сорокин, OZON
Forwarded from YAH (Egor Bogomolov)
Открытая образовательная программа для Хакеров
Про программу «Профессия – белый хакер» я уже писал, но очень хочется правильно донести посыл.
Я захотел сделать открытый образовательный проект по наступательной кибербезопасности для всех, кто имеет отношение к ИБ. Даже если просто задумывается об учебе или работе в этой сфере. Программу для всех, кто, как я когда-то, не понимал, с чего начать. Дать возможность вкатиться в нашу теперешнюю профессию.
Сегодня с друзьями из сообщества - коллегами, преподавателями, учащимися - мы запустили образовательный трек "Профессия - белый хакер", который является абсолютно открытым, без какой-либо навязывающей рекламы типа «КУПИ чтобы идти дальше». Он дает продвинутое представление о том, как будет выглядеть ваша работа белым хакером, какие знания вам нужны и какие этапы вас ждут дальше. Со ссылками на международные платформы, с указанием материалов и мест, популярных в мире, где можно еще учиться хакерским навыкам. С большим упором на методичность объяснения, без "наговаривания фундаментальщины" и только с полезными замечаниями и мыслями.
Этот трек создан сообществом и для сообщества. Чтобы таких, как мы, становилось все больше. Чтобы мы объединялись вокруг подобных инициатив и делали наше российское комьюнити круче: пополняли новыми людьми CTF команды, стартапы, крупных игроков, университеты и лицеи.
Ссылка на регистрацию: https://u.to/TseyHw, после регистрации вам сразу придет приглашение на Stepik!
P.S. В том, что это сделали именно CyberEd, можно увидеть рекламу. Но кто-то должен был это сделать. Просто наслаждайтесь, и я надеюсь, это принесет вам пользу!
Про программу «Профессия – белый хакер» я уже писал, но очень хочется правильно донести посыл.
Я захотел сделать открытый образовательный проект по наступательной кибербезопасности для всех, кто имеет отношение к ИБ. Даже если просто задумывается об учебе или работе в этой сфере. Программу для всех, кто, как я когда-то, не понимал, с чего начать. Дать возможность вкатиться в нашу теперешнюю профессию.
Сегодня с друзьями из сообщества - коллегами, преподавателями, учащимися - мы запустили образовательный трек "Профессия - белый хакер", который является абсолютно открытым, без какой-либо навязывающей рекламы типа «КУПИ чтобы идти дальше». Он дает продвинутое представление о том, как будет выглядеть ваша работа белым хакером, какие знания вам нужны и какие этапы вас ждут дальше. Со ссылками на международные платформы, с указанием материалов и мест, популярных в мире, где можно еще учиться хакерским навыкам. С большим упором на методичность объяснения, без "наговаривания фундаментальщины" и только с полезными замечаниями и мыслями.
Этот трек создан сообществом и для сообщества. Чтобы таких, как мы, становилось все больше. Чтобы мы объединялись вокруг подобных инициатив и делали наше российское комьюнити круче: пополняли новыми людьми CTF команды, стартапы, крупных игроков, университеты и лицеи.
Ссылка на регистрацию: https://u.to/TseyHw
P.S. В том, что это сделали именно CyberEd, можно увидеть рекламу. Но кто-то должен был это сделать. Просто наслаждайтесь, и я надеюсь, это принесет вам пользу!
CyberED
Профессия БЕЛЫЙ ХАКЕР b2c
Курс «БЕЛЫЙ ХАКЕР» разработан участниками профессионального сообщества - этичными хакерами, сотрудничающими с российскими компаниями.
У меня честно говоря даже слов нет чтобы выразить все чувства и эмоции, которые переполняют меня при прочтении этой статьи: https://habr.com/ru/articles/742492/
Одно лишь могу сказать - когда вас спросят, почему вы зарабатываете 300-400-500к/месяц, покажите им эту статью
Одно лишь могу сказать - когда вас спросят, почему вы зарабатываете 300-400-500к/месяц, покажите им эту статью
Хабр
МегаполОС или как мы были вынуждены переизобрести DevOps
Вступление Это история о том как небольшая группа IT-шников хотела автоматизировать свою работу, а в результате решила переизобрести DevOps-заново, и (с точки зрения этой группы) добилась прогресса....
Victoriametrics релизнули продукт для сбора и визуализации логов. Интересно будет посмотреть-сравнить
https://docs.victoriametrics.com/VictoriaLogs/
https://github.com/VictoriaMetrics/VictoriaMetrics/releases/tag/v0.1.0-victorialogs
https://docs.victoriametrics.com/VictoriaLogs/
https://github.com/VictoriaMetrics/VictoriaMetrics/releases/tag/v0.1.0-victorialogs
Victoriametrics
VictoriaLogs
Documentation for VictoriaMetrics, VictoriaLogs, Operator, Managed VictoriaMetrics and vmanomaly
Forwarded from Грефневая Кафка (pro.kafka)
Свежая статья от Neil Buesing в которой он раскрывает все тонкости настройки Apache Kafka в режиме KRaft! Для тех кто не в курсе (что очень странно для меня т.к. мой видос про Kraft давно в сети), KRaft — это KRaft mode in Apache Kafka, режим, который позволяет Kafka работать без использования Apache ZooKeeper.
В статье вы найдете подробные инструкции и лучшие практики по настройке этого режима.
🔗 Статью вы можете прочитать по этой ссылке: тут
А если вы предпочитаете действовать на практике, у нас есть хорошая новость: код и docker compose файлы из статьи доступны на Github!
🔗 GitHub репозиторий: тут
В статье вы найдете подробные инструкции и лучшие практики по настройке этого режима.
🔗 Статью вы можете прочитать по этой ссылке: тут
А если вы предпочитаете действовать на практике, у нас есть хорошая новость: код и docker compose файлы из статьи доступны на Github!
🔗 GitHub репозиторий: тут
Прикольная визуализация работы AWS
https://media.licdn.com/dms/image/D4E22AQE2jRapTPMMsg/feedshare-shrink_2048_1536/0/1687177177295?e=1690416000&v=beta&t=Wmenb5G5ELMptFLBernazh5RDNUz8hwOfnufvlNVdRw
🌍 Amazon CloudFront
🌐 Amazon Route 53
💻 Amazon EC2
⚖️ Amazon Autoscaling
🪪 Amazon Certificate Manager
🪣 Amazon Backup service
🗄️ Amazon RDS
☁️ Amazon VPC
🔐 Amazon WAF
👁️ Amazon CloudWatch
https://media.licdn.com/dms/image/D4E22AQE2jRapTPMMsg/feedshare-shrink_2048_1536/0/1687177177295?e=1690416000&v=beta&t=Wmenb5G5ELMptFLBernazh5RDNUz8hwOfnufvlNVdRw
🌍 Amazon CloudFront
🌐 Amazon Route 53
💻 Amazon EC2
⚖️ Amazon Autoscaling
🪪 Amazon Certificate Manager
🪣 Amazon Backup service
🗄️ Amazon RDS
☁️ Amazon VPC
🔐 Amazon WAF
👁️ Amazon CloudWatch
Forwarded from Future Crew
Мы приглашаем опытных девопсов для работы с тремя направлениями во Future Crew: это Data Platforms, приватная связь и защита от уязвимостей периметра.
Если темы вам интересны – откликайтесь по ссылкам.
DevOps в Data Platforms
Задачи: K8s, VMWare, Linux, изоляция ресурсов (GPU, CPU, RAM), LDAP, мониторинг, участие в создании архитектуры, развитие CI/CD для ML и не только.
О команде Big Data можно мы немного рассказывали здесь.
DevOps в Membrana
К8 – одна из ключевых составляющих нашей инфраструктуры. Девопс будет работать с контейнерами, сетями, маршрутами и Kafka.
Здесь можно прочитать о технологиях и о команде.
DevOps в Cicada8
Задачи: Построение и доработка кластера K8s, настройка системы мониторинга с нуля, автоматизация развертывания и скейлинга Cicada8. Опыт работы с облачными провайдерами и понимание процессов ИБ будет плюсом.
А здесь есть ещё три вакансии в команде Cicada8.
Если темы вам интересны – откликайтесь по ссылкам.
DevOps в Data Platforms
Задачи: K8s, VMWare, Linux, изоляция ресурсов (GPU, CPU, RAM), LDAP, мониторинг, участие в создании архитектуры, развитие CI/CD для ML и не только.
О команде Big Data можно мы немного рассказывали здесь.
DevOps в Membrana
К8 – одна из ключевых составляющих нашей инфраструктуры. Девопс будет работать с контейнерами, сетями, маршрутами и Kafka.
Здесь можно прочитать о технологиях и о команде.
DevOps в Cicada8
Задачи: Построение и доработка кластера K8s, настройка системы мониторинга с нуля, автоматизация развертывания и скейлинга Cicada8. Опыт работы с облачными провайдерами и понимание процессов ИБ будет плюсом.
А здесь есть ещё три вакансии в команде Cicada8.
Forwarded from k8s (in)security (Дмитрий Евдокимов)
Сегодня мы очень рады сообщить вам, что стали доступны все видеозаписи докладов с прошедшей конференции БЕКОН, посвящённой безопасности контейнеров и контейнерных сред (
Таким образом сейчас уже доступны все материалы с мероприятия:
- Видео
- Презентации
- Фотоотчет
P.S. Теперь уже можно смело готовиться к следующему БЕКОНу ;)
Kubernetes
в первую очередь).Таким образом сейчас уже доступны все материалы с мероприятия:
- Видео
- Презентации
- Фотоотчет
P.S. Теперь уже можно смело готовиться к следующему БЕКОНу ;)
Админим с Буквой
Сегодня мы очень рады сообщить вам, что стали доступны все видеозаписи докладов с прошедшей конференции БЕКОН, посвящённой безопасности контейнеров и контейнерных сред (Kubernetes в первую очередь). Таким образом сейчас уже доступны все материалы с мероприятия:…
не самое лучшее мое выступление, но были причины много нервничать)
Sber OPS Meetup: удобство, функциональность, надежность
🗓 10 июля 18:00 (МСК, GMT+3)
🌐Онлайн — трансляция на сайте
📍Офлайн — офис Сбера по адресу: Москва, Кутузовский проспект, 32, корпус Г
В большом комьюнити единомышленников будут обсуждать актуальные темы ИТ-сопровождения: Kubernetes Governance as a Code, dev/staging/testing-ветки, рабочее пространство администратора и техподдержку для сотрудников.
Что в программе:
✔ Максим Чудновский — «Kubernetes Governance as a Code, или Как содержать кластеры в чистоте и порядке».
✔ Семен Киреков — «Разделение на dev/master-ветки при деплое на стенды: паттерн или антипаттерн?».
✔ Александр Шрамко, Павел Степуро — «Единое рабочее пространство администратора, или Когда закончилось место на панели вкладок».
✔ Дмитрий Мошенко — «Как мы в Сбере предоставляем техническую поддержку сотрудникам».
Для участия в онлайне или офлайне нужно зарегистрироваться.
🗓 10 июля 18:00 (МСК, GMT+3)
🌐Онлайн — трансляция на сайте
📍Офлайн — офис Сбера по адресу: Москва, Кутузовский проспект, 32, корпус Г
В большом комьюнити единомышленников будут обсуждать актуальные темы ИТ-сопровождения: Kubernetes Governance as a Code, dev/staging/testing-ветки, рабочее пространство администратора и техподдержку для сотрудников.
Что в программе:
✔ Максим Чудновский — «Kubernetes Governance as a Code, или Как содержать кластеры в чистоте и порядке».
✔ Семен Киреков — «Разделение на dev/master-ветки при деплое на стенды: паттерн или антипаттерн?».
✔ Александр Шрамко, Павел Степуро — «Единое рабочее пространство администратора, или Когда закончилось место на панели вкладок».
✔ Дмитрий Мошенко — «Как мы в Сбере предоставляем техническую поддержку сотрудникам».
Для участия в онлайне или офлайне нужно зарегистрироваться.
Forwarded from Инженер Тяпкин (Clear Gray)
Ладно, покекали, давайте теперь и побухтим.
Есть один вопрос, который преследует меня постоянно. В работе, на собесах (причём с обеих сторон), в общении за пивом. Каждый раз он порождает жаркие дискуссии и взаимные обвинения вгомосексуализме профнепригодности. Каждый, сука, раз правильный ответ заставляет людей уходить со взглядом на тысячу парсек. И вопрос этот очень прост: "Как работают хелсчеки апстримов в nginx?"
И честно, я не знаю, почему люди настолько уверены, что у nginx эти самые хелсчеки есть, что готовы с пеной у рта отстаивать свою позицию.
Если вы уже готовы негодовать "ДА КАК НЕТ-ТО БЛЯДЬ ТЫ ЧО ТАМ СОВСЕМ ОХУ...", то тут самое время притормозить и сделать глубокий вдох. Я уже много раз участвовал в этом диалоге, фоллоу ми.
Что такое healthcheck вообще? Это проверка какой-то системы на предмет её состояния, чтобы понять, с этой системой всё хорошо или не очень.
То есть, когда у нас есть апстрим, то мы в него кричим "Тебе там нормально вообще?" и ждём, что оттуда послышится "Нормально!". Тогда мы понимаем, что апстрим живой и в него можно слать наш драгоценный трафик.
Но у нас же обычно больше одного апстрима (больше ведь, да?) и называем мы это всё группой. И нам бы хотелось, чтобы в группе все апстримы были рабочими, а нерабочих не было и наши ценннейшие запросы не улетали в один конец гнить до таймаута. И поэтому мы берём наш хелсчек и кричим в каждый апстрим в группе "Нормально тебе?". И если слышим в ответ "Намана!", то считаем апстрим хорошим, годным, а если не "Намана!" или вообще тишина - то считаем его плохим. Хорошие оставляем в группе, плохие исключаем, пока снова не начнут отвечать "Намана!".
Ну классика же, да? Ну все же так работают, и Haproxy, и Envoy, и любой балансировщик, да даже Apache. Ну очевидно же. Так вот, nginx не таков.
В nginx у нас тоже есть группы апстримов, мы туда тоже кидаем запросы, они летят в апстримы по roundrobin (по умолчанию, ага), но что будет, если один апстрим в группе вдруг перестанет отвечать? А нихуя не будет, лол. Он просто останется в этой группе, потому что механизма проверки нет. И тут вы такие "СТОПЭ, КАК ЭТО НЕТ, ОН ЖЕ КАК-ТО ПОНИМАЕТ, ЧТО НАДО ПОСЛАТЬ ЗАПРОС В ДРУГОЙ АПСТРИМ?". И вот тут мы подходим к самой мякотке:
ЖИВОСТЬ АПСТРИМА ОПРЕДЕЛЯТСЯ ПО РЕЗУЛЬТАТУ ЗАПРОСА.
То есть прилетает наш боевой запрос в nginx и проваливается в группу апстримов, где просто засылается в первый апстрим из списка. Запрос прошёл успешно и апстрим вернул 200? Отлично, посылаем ответ клиенту. Апстрим ответил 502? Просто берём этот же запрос и отправляем его в следующий апстрим из списка. И так пока запрос не обработается или апстримы не кончатся. Когда прилетит следующий запрос, он тоже пойдёт по этому кругу и не важно, что первый апстрим в списке у нас умер и всегда отвечает 502, ведь механизма хелсчека нет.
И тут у большинства возникает логичный вопрос: а если апстрим не совсем умер, а просто не отвечает и запросы к нему падают по таймауту? Всё верно, запрос будет ждать ответа весь таймаут, после чего будет отправлен в следующий апстрим. И если у вас в группе три апстрима и два первых не отвечают, то да, суммарное время обработки запроса будет "таймаут 1-го апстрима + таймаут 2-го апстрима + время ответа 3-го апстрима". Вот на этом простом факте и ломается большинство неокрепших умов, особенно тех, кто с nginx'ом встречается только в составе ingress'а в кубах. И именно поэтому у меня непроизвольно закатываются глаза всякий раз, как я слышу "а для балансировки трафика мы возьмём nginx".
"Как же так может быть в 2К23 году, что у одного из самых популярных веб-серверов нет хелсчеков?", спросите вы. И я вам отвечу: они на самом деле есть, но только за деньги в nginx plus. Но идея платить за nginx по популярности болтается где-то на уровне "купить лицензию winrar", да и ценник там моё почтение.
Вот теперь можете выдыхать с протяжным "БЛЯЯЯяяяя..."
P.S. если всё ещё считаете, что я пизжу, вам в первые три абзаца документации к ngx_http_upstream_module
P.P.S да, я знаю про max_fail и fail_timeout, даже про retry знаю, но это просто костыли от отсутствия хелсчеков
.
Есть один вопрос, который преследует меня постоянно. В работе, на собесах (причём с обеих сторон), в общении за пивом. Каждый раз он порождает жаркие дискуссии и взаимные обвинения в
И честно, я не знаю, почему люди настолько уверены, что у nginx эти самые хелсчеки есть, что готовы с пеной у рта отстаивать свою позицию.
Если вы уже готовы негодовать "ДА КАК НЕТ-ТО БЛЯДЬ ТЫ ЧО ТАМ СОВСЕМ ОХУ...", то тут самое время притормозить и сделать глубокий вдох. Я уже много раз участвовал в этом диалоге, фоллоу ми.
Что такое healthcheck вообще? Это проверка какой-то системы на предмет её состояния, чтобы понять, с этой системой всё хорошо или не очень.
То есть, когда у нас есть апстрим, то мы в него кричим "Тебе там нормально вообще?" и ждём, что оттуда послышится "Нормально!". Тогда мы понимаем, что апстрим живой и в него можно слать наш драгоценный трафик.
Но у нас же обычно больше одного апстрима (больше ведь, да?) и называем мы это всё группой. И нам бы хотелось, чтобы в группе все апстримы были рабочими, а нерабочих не было и наши ценннейшие запросы не улетали в один конец гнить до таймаута. И поэтому мы берём наш хелсчек и кричим в каждый апстрим в группе "Нормально тебе?". И если слышим в ответ "Намана!", то считаем апстрим хорошим, годным, а если не "Намана!" или вообще тишина - то считаем его плохим. Хорошие оставляем в группе, плохие исключаем, пока снова не начнут отвечать "Намана!".
Ну классика же, да? Ну все же так работают, и Haproxy, и Envoy, и любой балансировщик, да даже Apache. Ну очевидно же. Так вот, nginx не таков.
В nginx у нас тоже есть группы апстримов, мы туда тоже кидаем запросы, они летят в апстримы по roundrobin (по умолчанию, ага), но что будет, если один апстрим в группе вдруг перестанет отвечать? А нихуя не будет, лол. Он просто останется в этой группе, потому что механизма проверки нет. И тут вы такие "СТОПЭ, КАК ЭТО НЕТ, ОН ЖЕ КАК-ТО ПОНИМАЕТ, ЧТО НАДО ПОСЛАТЬ ЗАПРОС В ДРУГОЙ АПСТРИМ?". И вот тут мы подходим к самой мякотке:
ЖИВОСТЬ АПСТРИМА ОПРЕДЕЛЯТСЯ ПО РЕЗУЛЬТАТУ ЗАПРОСА.
То есть прилетает наш боевой запрос в nginx и проваливается в группу апстримов, где просто засылается в первый апстрим из списка. Запрос прошёл успешно и апстрим вернул 200? Отлично, посылаем ответ клиенту. Апстрим ответил 502? Просто берём этот же запрос и отправляем его в следующий апстрим из списка. И так пока запрос не обработается или апстримы не кончатся. Когда прилетит следующий запрос, он тоже пойдёт по этому кругу и не важно, что первый апстрим в списке у нас умер и всегда отвечает 502, ведь механизма хелсчека нет.
И тут у большинства возникает логичный вопрос: а если апстрим не совсем умер, а просто не отвечает и запросы к нему падают по таймауту? Всё верно, запрос будет ждать ответа весь таймаут, после чего будет отправлен в следующий апстрим. И если у вас в группе три апстрима и два первых не отвечают, то да, суммарное время обработки запроса будет "таймаут 1-го апстрима + таймаут 2-го апстрима + время ответа 3-го апстрима". Вот на этом простом факте и ломается большинство неокрепших умов, особенно тех, кто с nginx'ом встречается только в составе ingress'а в кубах. И именно поэтому у меня непроизвольно закатываются глаза всякий раз, как я слышу "а для балансировки трафика мы возьмём nginx".
"Как же так может быть в 2К23 году, что у одного из самых популярных веб-серверов нет хелсчеков?", спросите вы. И я вам отвечу: они на самом деле есть, но только за деньги в nginx plus. Но идея платить за nginx по популярности болтается где-то на уровне "купить лицензию winrar", да и ценник там моё почтение.
Вот теперь можете выдыхать с протяжным "БЛЯЯЯяяяя..."
P.S. если всё ещё считаете, что я пизжу, вам в первые три абзаца документации к ngx_http_upstream_module
P.P.S да, я знаю про max_fail и fail_timeout, даже про retry знаю, но это просто костыли от отсутствия хелсчеков
.
YouTube
Goldfinger - "Nothing To Me"
Artist: Goldfinger
Song: "Nothing To Me"
Album: Never Look Back
℗Big Noise Music Group, LLC.
©Noise Nest Publishing / Straight From The Crowd / BMG Rights Management (US) LLC o/b/o Beat Poet Music / BMG Gold Songs
Video: Josh Thornberry
Produced, Recorded…
Song: "Nothing To Me"
Album: Never Look Back
℗Big Noise Music Group, LLC.
©Noise Nest Publishing / Straight From The Crowd / BMG Rights Management (US) LLC o/b/o Beat Poet Music / BMG Gold Songs
Video: Josh Thornberry
Produced, Recorded…
Товарищи, подскажите пожалуйста кто чем пользуется для отслеживания новых релизов опенсорс продуктов? Интересует что-то типа телеграм бота, который будет ходить по гитхабу/гитлабу/конкретному урлу и сообщать в телегу о новом релизе (т.е. не ручная подписка!). Я знаю, что есть бот от Владимира (https://github.com/Civil/github2telegram/tree/master) но он очень давно не обновлялся, хоть и присутствует в большом количестве публичных каналов, и не понятен его статус. Вдруг кто-то придумал что-то повеселее? =)
Forwarded from /usr/bin
Что происходит, когда запускаешь «Hello World» в Linux
В статье рассказано об инструментах, при помощи которых вы можете исследовать происходящее. Будут рассмотрены утилиты readelf, strace, ldd, debugfs, /proc, ltrace, dd и stat. Читать статью.
В статье рассказано об инструментах, при помощи которых вы можете исследовать происходящее. Будут рассмотрены утилиты readelf, strace, ldd, debugfs, /proc, ltrace, dd и stat. Читать статью.
Forwarded from OFFZONE
This media is not supported in your browser
VIEW IN TELEGRAM
Наконец-то наш CFP-комитет отобрал лучших из лучших и мы готовы рассказать, какие доклады будут на OFFZONE 2023.
Программа будет пополняться, следите за обновлениями на сайте.
Please open Telegram to view this post
VIEW IN TELEGRAM