Среда оркестрации контейнеризированных приложений Kubernetes получила в последние годы широкое распространение.

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

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

Таким образом, совершенно очевидно, что Kubernetes является по сути основой для всей инфраструктуры, на которой работает приложение и то, насколько безопасно оно будет работать во многом зависит от того, насколько правильно будет настроена сама среда оркестрации.

Конечно, можно внедрить различные механизмы защиты, например ролевую модель доступа, о которой мы уже говорили ранее, но судить о том, насколько хорошо защищена та или иная система можно только попытавшись пойти по пути хакера, то есть попытаться ее взломать. В реальной жизни эту задачу обычно выполняют так называемые «белые хакеры» – пентестеры. В этой статье мы попробуем посмотреть на безопасность Kubernetes как раз глазами пентестеров.

Привет, Хабр! С вами снова Матвей Мочалов из cdnnow!, и в этом посте мы не будем разбираться с FFmpeg - в этот раз наша рубрика «Эээээксперименты!» будет затрагивать объектные хранилища. Разберёмся, чем S3 отличается от S3, а также почему не всё то S3, что называется S3. А заодно эксперимента ради сделаем своё собственное простенькое объектное хранилище на любимом языке всех DevOps и SRE-инженеров – Go.

Доброго дня. Это мой первый пост на хабре, поэтому не будьте особо строги к нему.

В мире разработки, системного администрирования и DevOps не смотря на то, что давно существуют и заняли свою нишу инструменты, связанные с централизованным сбором, визуализацией и анализом логов (graylog, ELK/EFK, loki, loggly и другие), всё ещё существует необходимость периодически взять шашку в руки и поработать со старыми/добрыми (а может быть и не очень добрыми) текстовыми логами. За 21 год своей деятельности я успел побыть системным администратором, DevOps инженером, разработчиком, CTO и системным аналитиком, но необходимость периодической работы с логами неизменно присутствовала в том или ином виде всегда. Это может быть разбор вывода нового сервиса или контейнера на машине разработчика, что-то, что ещё не успели завести (или сознательно по каким-либо причинам не завели) на централизованную систему сбора логов или, например, сервис, временно включенный в режиме debug для поиска причин проблемы. Ситуаций бывает много и ситуации бывают разные, а текстовые логи были, есть и ещё долго будут с нами.

Все, кто как-либо связан с DevOps знают про такие утилиты как more, less, tail, head, grep, sed, awk (а кто-то и ещё десяток более специфичных) и при необходимости их используют, но из тех, с кем я общался, никто не подтвердил мне, что знает про lnav. Я и сам не знал и искал нечто подобное более десяти лет. lnav — это не просто швейцарский армейский нож в мире работы с логами, а целый космический корабль, на котором можно улететь в соседнюю галактику. Мой мир разделился на "до" и "после" знакомства с этой утилитой. Там, где раньше требовались часы, а то и десятки часов на анализ логов, теперь хватает считанных минут.

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

В 1940 году, когда в немецкой армии появился запрос на армейскую самозарядную винтовку, на старт вышли 2 фирмы: Маузер и Вальтер. Одинаковое техническое задание привело к разному результату, на который я и предлагаю посмотреть.

Примечание: основная часть изложенного в статье относится к реализации SMT компании Intel, также называемой гипертредингом (hyper-threading). Она основана на научной статье компании, опубликованной в 2002 году.

Наша новая статья — для довольно искушённых пользователей Linux. В ней DevOps-инженер Алексей Гаврилов разобрал, как установить Debian или аналогичный дистрибутив на полностью зашифрованный диск без загрузчика на UEFI с включённым Secure Boot. 

После завершения установки вы получите включённый Secure boot с использованием личных ключей для подписи EFI-файлов, подписанные ключом файл ядра и initramfs, а также зашифрованные разделы диска за вычетом EFI boot. Это позволит уменьшить возможность векторного взлома ноутбука и усложнит жизнь потенциальному взломщику, поскольку в его распоряжении будут только подписанные EFI-файлы.

Когда в последний раз вы сталкивались с трудной для понимания темой? Или проводили часы за просмотром обучающих видео на YouTube?

Существует множество эффективных методик обучения, позволяющих усвоить сложные концепции и обрести уверенность в своих знаниях. Если вы, как и я, постоянно стремитесь к саморазвитию, то понимаете важность правильного подхода к обучению. Одним из наиболее простых и действенных методов является техника Фейнмана.

В этой статье я расскажу, как эффективно применять метод Фейнмана и использовать искусственный интеллект для восполнения пробелов в знаниях.

По окончании чтения вы научитесь использовать ChatGPT для разбора сложных концепций и их интуитивного освоения всего за четыре простых шага.

Уже много лет, начиная с 1966 года, во всем мире 20 июля отмечают Международный день шахмат. В честь недавно прошедшего праздника мы решили написать статью, в которой поговорим о шахматных задачах из курсов "Поколение Python".

Так получилось, что шахматные задачи являются одной из главных визиток наших курсов. Мы любим эти задачи потому, что они учат строить алгоритмы, находить закономерности, а также позволяют отточить работу с условными (if-else) и логическими (and и or) операторами.

Всем привет! Это команда Amnezia. 

Мы читаем комментарии под нашими постами и знаем, что один из самых частых вопросов – когда будет XRay? Так вот, мы добавили XRay в приложение AmneziaVPN, а точнее протокол Reality от XRay для всех платформ -  IOS, Android, Windows, Linux и MacOS. Если у вас еще нет последнего релиза, скорее скачивайте и создавайте VPN на собственном сервере в пару кликов с одним из самых защищенных и быстрых протоколов в мире, ниже мы немного о нем расскажем, а в конце статьи будет пошаговая  инструкция как это сделать.

Почему XRay Reality так популярен ?

Все дело в том, что Reality подходит для стран с самым высоким уровнем интернет-цензуры, сейчас его используют в Китае и Иране, он защищен от детектирования методами active probing. 

Распознать цензоров REALITY может еще на этапе TLS-хендшейка. Если REALITY видит, что к нему приходит его клиент, то сервер запускает для него VPN туннель, а если приходит любой другой запрос на 443 порт, то TLS-подключение передается на какой-нибудь другой реальный сайт, например, google.com, где цензор получит настоящий TLS-сертификат от google.com и вообще все настоящие данные с этого сайта.

Со стороны систем анализа трафика это выглядит как подключение к настоящему сайту, сервер отдает настоящий TLS-сертификат этого сайта, и вообще все (включая TLS fingerprint сервера) выглядит очень по-настоящему и не вызывает подозрений. 

Особенно приятно, что при этом производительность REALITY и скорость подключения у протокола действительно хороши, в сравнении, например, со связкой OpenVPN over Cloak.

В моей базе знаний 4 000 заметок.

Да, у меня немного съехала крыша на этой теме. Но решение создать систему для ведения заметок три года назад — пока что лучшая из моих интеллектуальных инвестиций. В этом посте хочу поделиться, зачем я это делаю, в каком формате и какие полезные практические кейсы для себя нашел. Тема бездонная, на самом деле. Можете взять часть идей и развить у себя.

Серьезные инциденты случаются со всеми, даже с глобальными игроками. Чего стоил один только прошлогодний сбой у Toyota! Тогда переполнение дискового пространства и сбой в СУБД стали причиной остановки всех заводов компании в Японии. А недавно произошла хакерская атака на СДЭК. В таких ситуациях остается надеяться только на бэкапы.

Не удивительно, что мы часто получаем запросы от клиентов о том, как организовать корпоративное резервное копирование. Их интересует, что именно бэкапить, как часто это делать, где хранить резервные копии, какие регламенты нужны и как лучше организовать резервное копирование на предприятии. Особенно много таких запросов стало поступать в последнее время. Поэтому я решил написать серию статей о том, как устроено резервное копирование, как его организовать и защитить. Моя цель — рассказать о best practice и структурировать эти знания. Бэкапы — обширная тема, которая включает множество нюансов, так что я начну с архитектуры и буду постепенно углубляться в детали. 

Привет, Хабр!

Давайте знакомиться: меня зовут Никита Соболев, я core‑разработчик CPython, mypy и typeshed. Некоторое время назад я понял, что на русском языке довольно мало контента про устройство CPython внутри. В основном доклады с конференций и статьи. Где‑то про память, где‑то про GIL, где‑то про парсер. Но чтоб системно и по всем основным частям в одном месте — такого я не нашел.

И решил сделать своё! Под катом я расскажу, как я делаю «Лучший курс по Питону»* на ютюбе. Почему он бесплатный. И почему он такой, какой есть. А еще я расскажу, какая польза будет разработчикам от его просмотра.

Привет, меня зовут Руслан Савченко, я руководитель службы разработки динамических таблиц в Yandex Infrastructure и преподаватель в Школе анализа данных. Сегодня я поделюсь актуальными инсайтами о том, как ломаются большие системы и как их траблшутить. Думаю, это будет полезно разработчикам и студентам, которые интересуются Site Reliability Engineering. Вообще, мало где сейчас обучают SRE, хотя в индустрии такие задачи очень востребованы.

В основе статьи — материалы SRE Week, открытого интенсива ШАДа по работе с большими нагруженными системами.

Как правило, заказы на Red Team поступают к уже опытным хакерским командам, которые набили руку на многочисленных пентестах. У них есть проверенные тактики и методы взлома, а также уверенность в своих силах. А ещё иногда они совершают «детские» ошибки во время первых редтимингов в карьере. Знаю это по собственному опыту.

В этой статье тряхну стариной и расскажу об одном из первых Red Team-проектов:

1. Разберу различия между Red Team и пентестом с точки зрения исполнителя.
2. Поделюсь приемами оффлайн-разведки и рассмотрю процесс поиска уязвимостей на примере реального кейса.
3. Покажу типичные ошибки, которые совершают пентестеры, переходящие в Red Team.

Рано или поздно системный программист сталкивается с понятием firmware. В данной статье мы коротко рассматриваем, что это, зачем, и как с этим работать.

Disclaimer:
Материал не является сборником best practices и не претендует на фундаментальный труд. Это шпаргалка. Если угодно - application note в свободной форме. Основная задача материала - "сделать короткую статью, которая помогла бы лично мне быстро разобраться, если бы я впервые столкнулся с темой". Если вы знаете что-то лучше - дополнения и замечания по существу приветствуются. Мотивацией для написания послужила недавно встреченная статья, которая как раз объясняла эти аспекты не очень хорошо.