Это главы 39 и 40 раздела «HTTP API & REST» моей книги «API». Второе издание книги будет содержать три новых раздела: «Паттерны API», «HTTP API и REST», «SDK и UI‑библиотеки». Если эта работа была для вас полезна, пожалуйста, оцените книгу на GitHub, Amazon или GoodReads. English version on Substack.

Привет! Меня зовут Максим Коровенков, я DevSecOps Lead в СберМаркете. 

Хочу рассказать о том, как мы строим developer-центричный DevSecOps. Мы набили по ходу этого «строительства» уже достаточное количество шишек, поэтому, дабы поберечь вас, делюсь обретенным опытом.

Статья будет полезна тем, кто только начинает строить DevSecOps-процессы в компании, а также тем, кто уже начал, но столкнулся с проблемами роста (рост числа микросервисов, команд разработки, экспоненциальный рост нагрузки, нехватка кадров и т.д.). Поехали!

В данной статье мы рассмотрим небезопасные варианты написания собственного Dockerfile, а также лучшие практики, включая работу с секретами и встраивание инструментов статического анализа. Тем не менее для написания безопасного Dockerfile наличия документа с лучшими практиками мало. В первую очередь требуется организовать культуру написания кода. К ней, например, относятся формализация и контроль процесса использования сторонних компонентов, организация собственных Software Bill-of-Materials (SBOM), выстраивание принципов при написании собственных базовых образов, согласованное использование безопасных функций, и так далее. В данном случае отправной точкой для организации процессов может служить модель оценки зрелости BSIMM. Однако в этой статьей пойдет речь именно о технических аспектах.

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

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

• SAST
• DAST
• IAST
• RASP

SAST и DAST

SAST (Static Application Security Testing) — тестирование «белого ящика», существует уже более десяти лет. Позволяет разработчикам находить уязвимости безопасности в исходном коде приложения на ранних этапах жизненного цикла разработки ПО. SAST также обеспечивает соответствие руководствам и стандартам кодирования без фактического выполнения базового кода.

DAST (Dynamic Application Security Testing) — тестирование «черного ящика», может обнаруживать уязвимости и слабые места в работающем приложении, обычно веб-приложениях. Это достигается за счет использования методов внедрения ошибок в приложении, таких как передача вредоносных данных в программное обеспечение, для выявления распространенных уязвимостей безопасности, например, SQL-инъекций и межсайтовых сценариев.

DAST также может пролить свет на проблемы времени выполнения, такие как:

• проблемы аутентификации и конфигурации сервера
• недостатки, видимые только при входе известного пользователя

Обнаружить это с помощью статистического анализа нельзя.

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

Технологии контейнеризации в последние годы получили широкое распространение и наиболее известным решением по управлению контейнерами по праву считается Kubernetes, или, сокращенно, K8s. Kubernetes это система автоматизации развертывания и масштабирования контейнеризированных приложений и управления ими. Данная система построена на базе программного обеспечения с открытым исходным кодом. Изначально решение разрабатывалось специалистами Google, начиная с 2014 года и предназначалось для решения внутренних задач корпорации. Однако, впоследствии Kubernetes стал решением Open-Source и получили широкое распространение по всему миру.

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

В целом, K8s можно назвать стандартом для современных DevOps-сред в организациях различного уровня. Например, Kubernetes используется в таких облачных сервисах, как: AWS, Microsoft Azure или Google Cloud.

Container Storage Interface (CSI) — это унифицированный интерфейс взаимодействия Kubernetes и систем хранения данных. Вкратце о нём мы уже рассказывали, а сегодня подробнее рассмотрим связку CSI и Ceph: покажем, как подключить хранилище Ceph к кластеру Kubernetes.
В статье приведены реальные, хотя и немного упрощённые для удобства восприятия примеры. Установку и настройку кластеров Ceph и Kubernetes не рассматриваем.

Вам интересно, как это работает?

Настроить хранение данных приложений, запущенных в кластере Kubernetes, можно несколькими способами. Одни из них уже устарели, другие появились совсем недавно. В этой статье рассмотрим концепцию трёх вариантов подключения СХД, в том числе самый последний — подключение через Container Storage Interface.

На собеседованиях на позицию, предполагающую понимание DevOps, я люблю задавать кандидатам такой вопрос (а иногда его еще задают и мне):

Каким, по вашему мнению, должен быть идеальный пайплайн от коммита до продашкена?/Опишите идеальный CI/CD / etc?

Сегодня я хочу рассказать про своё видение идеального пайплайна. Материал ориентирован на людей, имеющих опыт в построении CI/CD или стремящихся его получить.

Helm, как и Docker стал де-факто стандартом в индустрии. Тоже самое и с Kubernetes (52% доля в нише). И новость, что Docker is deprecated вызвало волну обсуждений в сообществе. Настолько все привыкли к Docker.

Что такое система управления конфигурацией?

Переменные в Gitlab можно задать в нескольких местах:

1. В настройках групп
2. В настройках проекта
3. Внутри .gitlab-ci.yml

При этом переменные в настройках групп и проекта можно задать как "файл"или "обычную переменную" и поставить галочки "защищено" и "маскировать".

Начнем с простого наследования и будем постепенно усложняться.

С конечным списком уровней приоритетов можно ознакомиться в конце документа.