Всем привет!

Решили у вас спросить, какие посты вы хотели бы видеть в нашем канале DevSecOps Talks, поэтому составили короткий опрос. Собираем ваши мнения 😊

Привет!

Спасибо всем, кто принял участие в нашем опросе. Мы точно будем писать больше про безопасность и про наш практический опыт внедрений, продолжим писать про инструменты DevSecOps. А ещё мы придумали две новых рубрики:

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

📍Во второй поделимся "грабельками", которые мы встречали, и тем, какие выводы мы сделали по итогам.

⁉️Кстати, если у вас есть вопросы, то вы всегда можете их задавать в нашем чатике!

Всем привет!

Отличная новость для пятницы. Совсем скоро, а именно, 12 ноября состоится бесплатная онлайн-конференция ADDO - All Day DevOps. Мероприятие продлится 24 часа и на нем выступят 180 спикеров из разных стран. Перечень тематических блоков и конкретных докладов можно просмотреть на сайте.

Вот примеры того, о чем будут рассказывать:
🍡DevSecOps. Our Secret Management Journey from Code to Vault
🍡DevSecOps. Automated Governance - Building a Compliant by Default Environment
🍡DevSecOps. Embedding Security in your Terraform and Cloudformation Code
🍡Cultural Transformation. Oups already Agile! DevOps Remains
🍡Modern Infrastructure. DevCovidOps - Two Sprints to Production
🍡CI/CD Continuous Everything. Get up to Speed with DevOps using Modern Development Practices
🍡DevSecOps. Kubernetes from an Attacker's Perspective

И это еще не все! Присоединяйтесь, будет интересно!

Всем привет!

По ссылке можно найти результат internship молодого специалиста в компании Appsecco (только у нас ассоциации про смесь Application Security и Prosecco? 🤔), в котором шаг за шагом решаются такие задачи как:

🍭 Создание pipeline для генерации security report для DVNA (дада, еще один damn vulnerable 😂) – использование SAST/DAST, CI/CD – Jenkins
🍭 Создание bill of materials для анализируемого приложения
🍭 «Перенос» наработок с локальной рабочей станции на AWS, отдельное внимание уделяется корректному хранению необходимых секретов
🍭 Использование полученного опыта для анализа следующего приложения – SuiteCRM

Отчет отлично структурирован, в нем есть большое количество строк кода, ссылок на статьи, наработками которых пользовался автор и даже немного верхнеуровневого сравнения open source инструментов!!!

ИТОГО: на наш взгляд это must have для любого специалиста, который хочет углубиться в практики выстраивания secured pipeline – все лаконично, просто и по делу! А вы что думаете?

P.S. Отдельно задумались над вопросом – «А почему у нас по результатам испытательного срока/internship не делают чего то подобного? Это же просто потрясающе!»

P.P.S. У ссылки на отчет не отображается preview, поэтому дублируем еще раз: https://devsecops-pipelines.ayushpriya.tech/

Друзья, коллеги и соратники по открытому коду, а также еще не примкнувшие!

3 ноября пройдет Red Hat Forum 2020 - в этот раз глобально, в едином порыве, в онлайн-формате. Если вам интересны вопросы:

❓эксплуатации контейнеров,
❓построение cloud native приложений,
❓практики DevOps
... и другие животрепещущие темы,

присоединяйтесь и узнавайте об эталонных примерах и “живых” кейсах заказчиков! В программе истории таких компаний как Росбанк, РСА, Металлоиннвест и др.

Вас ждет живое демо, а также море увлекательных тем:

📍Как оптимизировать IT-Инфраструктуру с помощью Ansible

📍Синергия средств разработки и контейнерных облачных сред

📍Как выглядит история целиком: cloud native разработка и контейнеры, CI/CD и DevOps

📍Quarkus - Java-фреймворк следующего поколения, ориентированный на Kubernetes


Встречаемся здесь: https://red.ht/Russiaforum

Привет!

Раз уж мы заговорили про еще один Damn Vulnerable, DVNA, то по ссылке можно найти «разбор» приложения с точки зрения безопасности:

🍭 Как проэксплуатировать найденные уязвимости?
🍭 Как устранить найденные уязвимости?

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

Вместе с отчетом, разбираемом в предыдущем посте, получится mini-лаборатория, которая позволяет идентифицировать, проверить и устранить выявленные дефекты ИБ.

В жизни все обстоит несколько иначе, но все начинается с «маленьких шагов» и рассматриваемые ресурсы как нельзя лучше подходят на эту роль ☺️

P.S. И опять не отображается preview, поэтому дублируем ссылку: https://appsecco.com/books/dvna-developers-security-guide/

Welcome to hell! Dependency hell!

В статье автор разбирает трудности, с которыми могут столкнуться python–разработчики, использующие зависимости (которых более 1,4 млн. в PyPI) и способы их решения.

Как правило, проблемы составляют не direct-зависимости (те, что вы явно указываете), а зависимости зависимостей (transitive, чтобы понять рекурсию надо сперва понять рекурсию).

На примере это может выглядеть так:

🍭 Ваше приложение использует прямую (direct) зависимость A
🍭 А, в свою очередь, использует B и C (transitive)
🍭 Для корректной работы B и C необходима зависимость D

Вроде все хорошо, в чем же проблема? Проблема может быть в том, что версии D, одновременно удовлетворяющей потребностям B и C может попросту не существовать! В итоге приложение не собирается и не работает.

Для решения этих проблем автор статьи предлагает использовать Watchman – утилиту, которая позволяет строить полный граф зависимостей и поддерживать его в актуальном состоянии для идентификации потенциальных dependency conflict.

На наш взгляд это так же крайне важно и для специалистов по ИБ, которые иногда просят разработчиков обновить зависимость на более «новую», чтобы устранить уязвимость и даже не представляют о последствиях, которые могут произойти (казалось бы, что сложного использовать n+1 версию?).

Это подводит нас к тому, о чем не говорил только ленивый – важности взаимодействия между Dev и Sec командами для поиска оптимального решения задачи ☺️

P.S. Астрологи объявили неделю неработающих preview, поэтому дублируем ссылку: https://blog.acolyer.org/2020/09/21/watchman/

И снова всем привет!

По ссылке доступно видео, где рассказывают про методы статического анализа приложений, без привязки к vendor или open source продуктам.

Автор «на пальцах» объясняет, как работают SAST-инструменты, какие типы анализа они осуществляют, например:

🍭 Pattern matching analysis
🍭 Control flow analysis
🍭 Data flow analysis/Taint analysis/String Analysis/Lost Sink

Про каждый из подходов приводится небольшой пример, а в завершении формируется ответ на вопрос: «Почему так много false positive в out-of-the box SAST и почему это нормально?»

Ролик может оказаться полезным для специалистов, которые хотят узнать, как это «работает внутри» на простых примерах и что SAST это не только pattern matching на слово «password» 😜

P.S. Не пугайтесь 2015 году, на наш взгляд для концептуально-образовательных целей видео все еще подходит как нельзя лучше

Всем привет!

Начинаем неделю с поста для тех, кто любит делать траблешутинг, собирать грабельки и учиться на ошибках 😌

Есть решение под названием Prisma Cloud Compute Edition (защита хостов и контейнеров), о котором мы неоднократно писали в наших постах. Недавно мы столкнулись со следующей проблемой: система не сканирует образы в RedHat OpenShift Internal Registry (версия OS 4.4/4.5).

Выглядело это примерно так: подключение к реестру выполняется, в логах модулей защиты фигурирует ошибка об использовании недоверенных сертификатов (хотя untrusted registries были разрешены), а в консоли все образы зеленые (хотя бы глазу было приятно).

Пример сообщения об ошибке:
Failed to pull image openshift/apicurito-ui:1.5, error Error initializing source
docker://image-registry.openshift-registry.svc:5000/openshift/apicurito-ui:1.5: error pinging
docker registry image-registry.openshift-registry.svc:5000: Get
https://image-registry.openshift-registry.svc:5000/v2/: x509: certificate signed by unknown
authority

Выявленную проблему удалось решить следующим образом (отдельное спасибо вендору):
1. Сгенерировать в консоли управления (Console) новый YAML-файл для модуля защиты (Defender)
2. Внести следующие правки в конфигурацию вручную:

🍡 Раздел volumeMounts:

- name: registry-scan
  mountPath: /etc/docker/certs.d
- name: registry-scan2
  mountPath: /etc/containers/certs.d

🍡 Раздел volumes:

- name: registry-scan
  hostPath:
    path: /etc/docker/certs.d
    type: ''
- name: registry-scan2
  hostPath:
    path: /etc/containers/certs.d
    type: ''

После этого сканирование выполняется успешно и уязвимости в образах отображаются в консоли управления.

Всем привет!

На предыдущей неделе HashiCorp анонсировала сразу 2(!) новых продукта, которые расширят их и без того впечатляющий портфель!

Первый – это HashiCorp Boundary [Security]
Обеспечение безопасности удаленного доступа, основанное на trusted identity.

Решение предлагает альтернативный «классическим» VPN/хост-бастион SSH подход, что может быть удобно для распределенных команд, особенно в условиях «эфемерности и динамичности» окружений. Также решение позволяет гранулярно управлять доступом, получаемым извне компании.

Использование:

🍭 Gateway
🍭 Локального агента на машине пользователя
🍭 IdP (identity provider, любой из существующих)
🍭 Настроенных политик управления доступом, реализованных с учетом RBAC

позволяет контролировать доступ пользователей к определенной группе ресурсов. При этом, контроль осуществляется для логических групп («базы данных»), а не для "фиксированного перечня ресурсов" (перечень IP-адресов).

Это позволяет «убрать» целый перечень чувствительных данных (VPN/SSH credentials, перечень целевых IP-адресов, учетные данные целевых систем и т.д.), которые могут быть скомпрометированы.

Таким образом упрощается процедура предоставления доступа и повышается безопасность. Подробнее о том, как это работает можно посмотреть в видео, доступном по ссылке на решение ☺️

Привет!

Что общего у Docker и Xerox? На первый взгляд может показаться, что ничего. А если немного задуматься, то можно обнаружить интересное сходство: Docker, как и Xerox стал нарицательным именем для определенной технологии и может сложиться мнение, что управление контейнерами и образами – это Docker. И ничего больше.

В статье автор делает краткий обзор на существующие механизмы Container Engine, Image Build, Container Runtime и Image Distribution. Цель статьи проста и понятна – показать, что Docker не единственный инструмент и, возможно, вы сможете подобрать себе то, что устроит вас в большей степени (хотя бы для того, чтобы убрать daemon, запускаемый из-под root, что не всегда безопасно). Какие же есть альтернативы?

Container Engine

🍭 Podman – потенциально самый «сильный» конкурент Docker, разработанный Red Hat
🍭 LXD — средство управления LXC (Linux Containers). Используется для решения достаточно узкого круга задач
🍭CRI-O – не совсем engine, больше runtime, специализированный для Kubernetes
🍭 rkt — rocker, container engine, разрабоатнный CoreOS. Увы, проект не поддерживается в настоящее время

Image Build

🍭Buildah – инструмент, созданный Red Hat для разработки образов. Есть интересная история, связанная с его названием – советуем погуглить
🍭Kaniko (не путать с Calico ☺️ ) – решение от Google, которое представляет из себя контейнер и в большей степени пригодно для использования на кластерах
🍭Buildkit – если все же не хочется «отворачиваться» от Docker, то это решение для вас: может быть «включен» в Docker, в качестве experimental feature

Container Runtime

🍭 runc – вероятно, самый популярный container runtime, созданный в соответствии со спецификациями OCI (используется Docker, Podman, CRI-O)
🍭 crun – решение, разработанное Red Hat

Image Distribution

🍭 Skopeo – инструмент разработанные Red Hat, завершает «триаду» - Podman/Buildah/Skopeo

"А будут ли проблемы совместимости, если я все же захочу использовать что-либо отличное от Docker? ” – можете подумать вы. Нет, не будет. Все указанные инструменты разработаны с использованием спецификаций OCI (как и сам Docker). Например, alias docker=podman и проблем нет, даже команды те же самые, а местами даже больше! Чего стоит один только:

buildah rmi –a (какая мелочь, а сколько счастья ☺️)

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

P.S. Если вам понравилась статья и вы бы хотели, чтобы мы перевели ее на русский язык полностью – пишите в комментариях под постом или в чате – сделаем! ☺️

Привет!

Недавно мы написали про одно из двух решений, представленных HashiCorp (HashiCorp Boundary). Самое время рассказать про второе!

Встречаем HashiCorp Waypoint [Development]! Решение, которое позволяет разработчикам build, deploy и release приложений между различными платформами.

Причина, по которой Hashi решили сделать свое решение достаточно проста: сокращение сложности для разработчиков, которые просто хотят deploy, а не containers, schedulers, YAML, serverless и прочие нюансы cloud native мира.

Использование требует одной простой команды: waypoint up. Жизненный цикл, который происходит «за кадром» включает в себя следующие шаги:

🍭 Build: Сборка артефакта и помещение его в используемый реестр
🍭 Deploy: артефакт, собранный на предыдущем этапе, разворачивается на целевой инфраструктуре
🍭 Release: настройка потоков траффика на приложение

Просто пример deploy приложения на Kubernetes будет выглядеть так:

project = "HashiCorp Waypoint"

app "waypoint-up" {
    build {
        use "docker" {}
        registry {
            use "docker" {
                image = "hashicorp/wpmini"
                tag = gitrefpretty()
            }
         }        
      }

    deploy {
        use "kubernetes" {
            probe_path="/"
            service_port=80
        }
     }

    release {
        use "kubernetes" {
            load_balancer=true
            port=80
         }
     }

}

В результате будет собран образ, создан deployment в namespace и открыт порт для работы с приложением. И да, все будет реализовано с использованием одной команды: waypoint up!

Кроме Kubernetes Waypoint поддерживает HashiCorp Nomad, Amazon ECS, Google Cloud Run, Azure Container Instances, Docker, Buildpacks (перечень не полный 😉)

Это лишь часть функционала решения, подробности можно почитать по ссылкам:

🍭 https://www.waypointproject.io/docs/intro (документация)
🍭 https://www.waypointproject.io/docs/getting-started (простой пример использования)

Всем привет!

Сегодня пятница - день хороших новостей 🎂🍩🍪 Павел Новожилов и Анастасия Дитенкова из "Инфосистемы Джет" готовят вебинар на тему - Контейнеры vs Compliance. Не секрет, что требования регуляторов не всегда получается приземлить на эфемерные контейнерные среды, а выполнение некоторых из них кажется невозможным. Но нет ничего невозможного 😉

Мы поделимся опытом, как выполнить неприменимые к контейнерным средам требования ГОСТ для финансовых организаций, а так же расскажем как можно организовать:

🍩 Регистрацию событий рабочих нагрузок
🍩 Контроль целостности в контейнерной среде
🍩 Сегментирование контейнерных сетей
🍩 Управление уязвимостями

Регистрируйтесь, приходите и задавайте вопросы! Вебинар состоится 10 ноября в 16:00 МСК.

Привет!

Недавно натолкнулись на еще один интересный open source проект, хотя бы потому, что вся его документация на бразильском португальском ☺️

Проект называется Horusec и используется для того, чтобы агрегировать проверки (статический анализ) :

🍭 Python(3.x) => (Bandit and Safety)
🍭 Ruby => (Brakeman)
🍭 Javanoscript => (Npm Audit and Yarn Audit)
🍭 GoLang => (Gosec)
🍭 .NetCore(3.x) => (.NetCore)
🍭 Java => (HorusecJava)
🍭 Kotlin => (HorusecKotlin)
🍭 Terraform => (Tfsec)
🍭 Leaks => (HorusecLeaks)
🍭 Leaks(optional search in git history) => (GitLeaks)

Проект поддерживается и развивается, по ссылке на Git можно найти roadmap, согласно которому будут добавляться новые функции, поддержки языков!

Ссылка на документацию (на английском): https://zup-products.gitbook.io/horusec/v/v1-eng/

Сегодня мы хотим поговорить не о инструментах и технологиях, а о подходах. Думаю, многие из вас слышали такой подход, как GitOps. Он в свое время появился и получил распространение благодаря компании WeaveWorks (https://www.weave.works/).

GitOps - это метод / подход / практика / модель (называйте как удобно) к управлению кластером Kubernetes, и доставке приложений, которые в этом кластере работают. Чем-то это напоминает подход Infrastructure-as-a-Code, но чем-то и отличается. Если коротко, то, согласно блогу той же WeaveWorks (https://www.weave.works/technologies/gitops/), у вас GitOps, если:

🍬 Ваша система описана декларативно
🍬 Целевое требуемое состояние описано в едином источнике - Git
🍬 Автоматическое применение изменений
🍬 Софт, отслеживающий корректность фактического состояния

На текущий момент этот подход набирает обороты, уже появилось достаточное количество специализированных инструментов (GitOps - агентов), практических реализаций все больше. Преимущества подхода просты и понятны. И одно из них как раз и заключается в том, что GitOps - это не про инструменты, а про подход. Который как раз оставляет вам свободу выбора тех инструментов, к которым вы привыкли, и не привязывает вас к какому-то одному.

Но сегодня мы не об этом ) Сегодня как раз хотим поговорить не о том, почему это хорошо. А о том, почему это не (очень/всегда) хорошо.

Как и у любого подхода, у GitOps есть свои ограничения. Недавно наткнулись на интересную и познавательную статью - GitOps: The Bad and the Ugly (https://blog.container-solutions.com/gitops-limitations). В ней описаны следующие ситуации и проблемы, которые порождаются при GitOps - подходе:

🍬 Конфликты при апдейтах репозитория. Единый источник правды - Git - это и благо, и нет. Когда у вас большое окружение, сложное ПО с большим количеством микросервисов, конфликты при апдейтах неизбежны
🍬 Отсюда же следует вторая проблема: в попытке уйти от единого репозитория, их количество начинает расти большими темпами, и в итоге вы оказываетесь в ситуации, когда приходится тратить значительную часть времени на управление самими репозиториями, pull-request management, правильная настройка прав доступа, и т.д.
🍬 Недостаток наглядности, как следствие первых двух проблем. Понять и отследить фактическое состояние кластера, когда у вас много репозиториев - сложно
🍬 Сложность управления секретами (secrets management). GitOps не заточен для решения этой задачи сам по себе, и не особенно помогает ее решать. Потребуется единая точка управления секретами в виде отдельного хранилища
🍬 Аналогично и в части аудита изменения конфигураций. Бывают ситуации, когда отследить историю изменений сложно
🍬 Недостаток валидации артефактов на входе. В отличие от обращения к кластеру по API, при котором валидность проверяется, при простом коммите в git за корректность отвечает сам пользователь

Понятно, что не все из этих пунктов применимы ко всем кластерам, окружениям и компаниями. И нужно смотреть case-by-case.
Даже среди нас эти пункты вызвали дискуссии и разные мнения. Поэтому хотим обсудить это с вами - что вы думаете? Актуален ли для вас GitOps подход в целом? Применяете его? Сталкивались ли с проблемами и ограничениями? Поделитесь вашим опытом и соображениями на этот счет в комментариях!

П.с. А чтобы вам интереснее было читать статью - для затравки, в ней дано видение на подход, альтернативный GitOps'у.
П.с.2. И в этой же статье - ссылка на статью "11 причин зачем вам нужен GitOps" :) Enjoy!

Всем привет!

А вы знали, что Red Hat (IBM) не только включает в свою документацию разделы по безопасности, но и выпускает отдельные Security Guides для платформы оркестрации Red Hat OpenShift?

14 октября как раз появилась обновленная версия этого документа для платформы v4.5.

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

Вот перечень вопросов, ответы на которые можно найти в гайде:
🍡Почему безопасность контейнеров важна и как она ложится на стандарты безопасности?
🍡Какие меры по безопасности контейнеров реализуются на уровне ОС и на уровне платформы?
🍡Как проверять контейнеры на наличие уязвимостей?
🍡Как контролировать доступ к контейнерам, используя аутентификацию и авторизацию?
🍡Как обеспечивается контроль сетевых взаимодействий и безопасности подключенных к платформе хранилищ?
И пр.

Документ доступен по ссылке.

Всем привет!

Не так давно мы писали про решение по управлению секретами в контейнерной среде CyberArk DAP.
Сегодня затронем другой компонент продуктовой линейки Application Access Manager (AAM), предназначенный для выведения hardcoded секретов (паролей, токенов и тд) в монолитных приложениях - это CyberArk Credential Provider.

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

🍩 Java
🍩 C/C++
🍩 .NET

Эти библиотеки обеспечивают выполнение вызовов от приложений к хранилищу CyberArk Vault с применением:

🍩 политик выдачи секретов приложениям
🍩 периодической ротации секретов
🍩 аутентификацией хостов и приложений.

У решения есть 2 полезные фичи, которые пригодятся в случае отсутствия библиотек для конкретных языков программирования или невозможности установки Credential Provider на сервер с приложением:
🍩 возможность делать вызовы через утилиту CLI (её можно также использовать в bash/powershell скриптах)
🍩 централизация путем добавления к Credential Provider веб-сервера IIS. В этом случае в приложение добавляются SOAP/REST API запросы

И разумеется, решение может быть интегрировано в уже имеющуюся инфраструктуру CyberArk, используя общее хранилище секретов.

Более подробно с решением можно ознакомится на сайте вендора

Всем пятница!

В статье собрана отличная подборка курсов (бесплатных (!)), которые помогут совершить первые шаги в изучении Docker и Kubernetes.

В подборке проводится обзор следующих курсов:

🍭 Docker Mastery Tutorial : The Complete Toolset From a Docker Captain (Udemy)
🍭 Free Docker Training Courses Online (LinkedIn Learning)
🍭 Docker and Kubernetes: The Complete Guide (Udemy)
🍭 Docker Technologies Course for DevOps and Developers (Udemy)
🍭 Docker Tutorial from A to Z™: Swarm + Jenkins (Udemy)
🍭 Docker, Apache Mesos & DCOS: Run and manage cloud datacenter
🍭 Docker for Beginners Course
🍭 Docker Swarm Mastery: DevOps Style Cluster Orchestration
🍭 Hands on With Docker & Docker Compose Tutorial From a Docker Captain
🍭 Grow your Docker Skills (Pluralsight)

Для каждого курса приведено краткое описание, а также сильные стороны и его «рейтинг». Все подробности и ссылки можно найти в самой статье!

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

Microsoft следует заветам Simon Wardley и продолжает системно развивать инструменты для разработчиков: вот-вот выйдет релиз 1.0 Dapr. Это рантайм для распределенных систем, где из коробки умеет:
📍дискаверинг сервисов и вызовы по gRPC и HTTP
📍очереди сообщений
📍управление секретами
📍bindings для обработки событий
📍трейсинг и не только.

Стоит сказать, что это не новый велосипед, а тщательно обработанные напильником компоненты старых.

https://thenewstack.io/the-dapr-distributed-runtime-nears-production-readiness/

Привет!

11 ноября будет вебинар, посвящённый KubeLibrary – библиотеки из RobotFramework (open source проект, использующийся для тестирования средств автоматизации и роботизации).

KubeLibrary может быть использована для тестирования состояния объектов кластера Kubernetes, например:

🍭 Nodes
🍭 Jobs
🍭 Configmaps
🍭 PV Claims
🍭 Services и иных объектов

Зачем это надо? Например, вы хотите провести аудит настроек вашего кластера Kubernetes. Все, что потребуется - это написать необходимые проверки, запустить их на кластере, собрать и проанализировать результат. Получится быстрее, чем проведение аналогичных действий "в ручную".

Вкратце про библиотеку можно почитать в этой статье или вот в этой, а примеры использования – посмотреть на вебинаре, ссылка на который была в самом начале статьи!