DevOps *

Управление секретами и почему это так важно для нас?

Привет! Меня зовут Евгений, я работаю на позиции Lead DevOps в EXANTE. В этой статье мы разберем жизненный опыт сетапа high availability Hashicorp Vault с gcp storage backend и autounseal в k8s.

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

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

Мы решили сделать наш продукт cloud native, и для этого нужно было изменить подход к разработке и инфраструктуре, провести рефакторинг наших легаси сервисов, начать двигаться в сторону микросервисной архитектуры, разворачивать сервисы в cloud k8s, использовать managed ресурсы (redis, postgres).

В наших реалиях под изменения попасть должно было все – от приложений и инфраструктуры до методов распространения конфигов и секретов. В качестве облачного провайдера был выбран Google, а хранилищем секретов был выбран Hashicorp Vault. На данный момент мы довольно успешно прошли большую часть пути.

Почему Hashicorp Vault?

У нас есть несколько причин:

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

Как  разработчики большой мультибрендовой торговой площадки (Faire) внедрили автоматизированные c LLM  Code Review (статья - мой перевод для нашего ТГ канала посвященного разработке софта при помощи LLM). 

В Faire мы верим в ценность код-ревью и всегда придерживаемся этой практики. Хотя многие аспекты код-ревью требуют глубокого понимания проекта, существуют также множество общих требований, которые можно учесть без дополнительного контекста. Например, наличие ясного заголовка и описания, достаточное покрытие тестами, соблюдение стиля кода, выявление изменений несовместимых между сервисами.

Похоже, что LLM хорошо подходят для выполнения таких общих задач код-ревью. Имея достаточно информации о pull request: метаданные, diff, логи сборки и  отчеты о покрытии тестами, можно эффективно настроить LLM для добавления полезной информации, выявления багов или потенциально опасных изменений и даже автоматического исправления простых ошибок.

В последнее время разгон мониторов до 75 Герц стал достаточно популярной темой. Дело в том, что многие современные модели официально поддерживают только 60 Гц, хотя вполне способны нормально работать и с частотой 75 Гц.

Повышение частоты обновления монитора с 60 до 75 Гц позволяет добиться большей плавности изображения в играх и снижает утомляемость глаз. Поэтому, если монитор поддерживает такую частоту, то подобный разгон приносит только преимущества. В этой инструкции мы расскажем о том, как разогнать монитор до 75 Гц с помощью драйверов NVIDIA/AMD или специальных программ.

Прошивки часто пишут в Eclipse.

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

Именно этот аргумент огромная fun база Eclipse плагинов и приводит в качестве главного за Eclipse плагины.

В этом же тексте я написал как активировать эту пресловутую опцию даже при сборке сторонними скриптами. Причем любыми.

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

Двухфакторная аутентификация (2FA) – это мощный инструмент, который значительно повышает уровень безопасности, требуя подтверждения вашей личности с помощью второго фактора. В этом контексте, двухфакторная аутентификация через Telegram представляет собой эффективное решение, которое можно легко интегрировать в процесс SSH-подключения.

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

В этой статье мы шаг за шагом рассмотрим, как настроить двухфакторную авторизацию для SSH с использованием Telegram-бота. Мы разберем все необходимые шаги – от создания бота до интеграции с вашим сервером, чтобы вы могли обеспечить дополнительный уровень безопасности для вашего окружения.

В этой небольшой статье расскажу, как мы организовали нашему клиенту закрытый контур в Yandex Cloud. Если конкретнее: покажу, как настроить StrongSwan site-to-site IKEv2 ipsec tunnel, а потом — инфраструктуру, состоящую в основном из кластера Kubernetes, GitLab, Vault и Keycloak. Приятного чтения!

В современном мире практически ни одна разработка программного обеспечения не обходится без использования средств контейнеризации, что связано с удобством хранения артефактов и зависимостей. Киберпираты следуют трендам DevSecOps, чтобы повышать энтропию атак на контейнерные среды. Кроме того, растет количество APT группировок, что является сегодня довольно значимой проблемой. В данной статье мы подробно рассматриваем техники злоумышленников, а также рассказываем о существующих тактиках защиты для того, чтобы разработчики или DevOps-инженеры смогли применять их в своей повседневной работе.

ChatGPT-4o написал Python-скрипт на 400 строк, который с помощью API Cloudflare переносит домены со всеми настройками между разными аккаунтами. В статье подробно рассмотрен процесс создания скрипта, включая сохранение и копирование настроек и DNS-записей. Также приводятся примеры кода и пояснения, позволяющие легко адаптировать решения под конкретные задачи.

Всем привет! Напишу как я устанавливал youtubeUnblock на старый роутер keenetic start, больше для себя ну и поделится опытом.

Kubernetes — самый популярный оркестратор в России. По данным исследования VK Cloud «State of Kubernetes», K8s используют 56% компаний, работающих с оркестраторами (причем из них 53% работают с Kubernetes в облаке). Более того, спрос на работу с технологией увеличивается. Вместе с тем многие компании сталкиваются с недостатком опыта, что приводит не только к техническим сложностям, но и к неоправданным расходам.

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

Привет Хабр! На дворе конец лета и слушатели ИТ-курсов в раздумьях о выборе обучения на осень 2024 и профессии как таковой. А мы продолжим цикл статей о плюсах и минусах разных профессий в ИТ. Давайте поговорим о DevOps-инженере. Как говорят рекрутеры, на фоне переизбытка выпускников курсов по разработке на Python, профессия DevOps-инженера смотрится одной из топов по востребованности и оплате.
P.S. Иллюстрация ИИ к статье — “я художник, так вижу DevOps и девушки их любят”.

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

Вот буквально несколько настоящих примеров из жизни. Парад нелепости.

Формализм при ревью уже перешёл все рамки здравого смысла.

Привет, друзья! Разговоры у вечернего костра, у палатки, у реки, в спокойный, тихий вечер и в располагающей к технической честности и объективности атмосфере, а не «у пепелища дата-центра», как некоторым может показаться! 😊 Приготовьтесь погрузиться в захватывающую историю, как, но, важнее, почему мы сознательно пришли к активному использованию контейнеров и «доросли» до внедрения Kubernetes в высоконагруженном проекте «BI-конструктор». Но про Kubernetes в посте не будет не слова, будет только про контейнеры, но мы подготовим мозг к следующему посту, уже исключительно про Kubernetes, но тоже максимально доступно. Однако, я буду все рассказывать очень простыми (иногда техническими) словами, без ныряния в многоуровневый мат, уж простите. Я убежден, что когда ты все прочувствовал и выстрадал умом и сердцем, то сможешь этот опыт передать доступно и понятно другим, а когда сам не понимаешь, о чем говоришь, то и остальных просто запутаешь. И еще один момент – технических картинок и графиков по теме тоже не будет, они вызывают головную боль от растекания абстракций и их легко найти самостоятельно и в конце я дам рецепт где. Но, даже без них, не сомневайтесь, вы все поймете с первого раза. Итак, наливайте кофе, насыпайте попкорн, кладите в карман таблетку от головной боли (иногда будет сложно, но ради вашего же блага) и ныряйте «под кат».

Привет! Я Максим Коровенков, DevSecOps Lead в Купере (ex СберМаркет). Хочу поделиться мыслями по поводу минимально необходимого набора процессов, сопутствующих внедрению сканеров безопасности в пайплайны разработки. 

В результате попытаюсь ответить на вопрос: «А что, собственно, стоит иметь в виду под фразой “Мы внедрили сканеры безопасности в пайплайны разработки”?» 

Да, в тысячный раз про пайплайны, но, как вы, думаю, догадываетесь, желание поделиться казалось бы очевидными мыслями появилось не случайно! Не так давно я завершил найм и укомплектовал свою DevSecOps-команду. В рамках поиска пришлось провести достаточное количество интервью, на которых я любопытствовал, как обстоят дела у соискателей с пайплайнами безопасности на текущем/предыдущем месте работы. Это удивительно, но для 90% респондентов фраза «внедрение сканеров безопасности в пайплайны» означает только факт внедрения. Лишь некоторые кандидаты упоминали отправку результатов в VMs/ASOC систему. 

Ведь действительно кажется, что все просто: запаслись вокабуляром из нескольких аббревиатур, внедрили инструменты, SAST, SCA, может что-то еще, настроили отправку результатов для AppSec-ов и, как-будто, можно идти бить баклуши. Но я на своем опыте убедился, что DevSecOps — это про глубокую проработку процессов. Поэтому в данной статье сконцентрируюсь больше на процессах, нежели на технике. 

Предлагаю наконец переходить к сути!

История о том, как мы развивали наш CI процесс для монолитного Python-репозитория с авто тестами, возникавшие проблемы и примеры их решений. Поговорим о Docker, линтерах, Allure TestOps и многом другом.

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

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

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

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

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

Привет! На связи Олег Казаков из Spectr. 

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

Сегодня я расскажу о заключительном этапе DevSecOps — Deploy-time Checks. 

Привет, Хабр! Меня зовут Николай Пискунов — я ведущий разработчик в подразделении Big Data. И сегодня в блоге beeline cloud мы продолжим серию статей про Git и Gitflow — рассмотрим релизный цикл: то есть то, как общий код команды должен попасть в прод. Для этого в GitFlow существует процесс и ветка под названием release.

В разработке ПО повторяющиеся задачи часто занимают много времени, особенно когда нужно массово генерировать кучу файлов с кодом. Чтобы повысить эффективность и уменьшить количество ошибок, TableConvert.com предлагает мощный инструмент — Magic Конвертер. В этой статье я расскажу о его крутых функциях и как его использовать, чтобы упростить рабочий процесс.