Привет!

17 августа CNCF провела несколько онлайн сессий в рамках KubeCon: ServiceMeshCon, Serverless Practitioners Summit и Cloud Native Security Day.

Буквально вчера на youtube стали доступны записи докладов!!! Посмотреть их можно по ссылке. А чтобы получить первое представление о том, что можно посмотреть приводим несколько примеров:

ServiceMeshCon:

🍭 Service Mesh Is Still Hard. The Things we all Did Wrong & Tales of Woe
🍭 Service Mesh Architectures Explained - Sidecar and Beyond

Serverless Practitioners Summit

🍭 Chaos Engineering in a Serverless World 🙈🙈🙈
🍭 3factor app: An Accessible Design Pattern for Serverless

Cloud Native Security Day

🍭 Kubernetes Attack and Defense
🍭 Pod Security as an Afterthought

Что может быть лучше, чем залезть под одеяло в такую погоду и смотреть множество интересных видео?
А какой доклад понравился вам больше всего? Ждем в чате! Кстати, там даже есть доклад от Сбербанка 😃

Привет!

Читая большое количество статей про Kubernetes и контейнеры может сложиться впечатление, что это просто silver bullet, который позволяет без особых усилий переносить приложения всеми возможными способами (из Dev в Prod, из on-prem в Cloud, из Cloud в on-pem и вообще везде-везде-везде).

Но, все знают, что silver bullet не существует, но продолжают его искать. Такой вот парадокс. Чтобы показать, что реальность может несколько отличаться от ожиданий мы перевели отличную статью Kevin Casey, в которой рассматриваются потенциальные трудности (или задачи! зависит от вашей точки зрения), с которыми можно столкнуться при миграции Dev -> Prod!

А вы сталкивались с чем-нибудь подобным или все прошло «как по маслу»? Ждем вас в чате!

https://habr.com/ru/company/jetinfosystems/blog/518694/

Всем привет!

К вопросу о сетевых плагинах к Kubernetes. Нашли отличную статью про актуальные плагины для кубера, в которой приведено сравнение по производительности для разных вариантов. На наш взгляд, весьма ценная информация, которая позволяет сориентироваться в существующем многообразии CNI. Помимо тестов на performance, авторы так же дают рекомендации по настройке MTU, и рассматривают вопрос функционирования при включении шифрования трафика. Рекомендуем к прочтению!

https://itnext.io/benchmark-results-of-kubernetes-network-plugins-cni-over-10gbit-s-network-updated-august-2020-6e1b757b9e49

Привет!

По ссылке пост из блога компании Palo Alto Networks, который описывает, казалось бы, достаточно очевидные вещи, такие как значимость комплексного подхода для защиты контейнеров.

Суть заключается не только в анализе образов, но и в защите runtime. Такой подход позволит стать ближе к реализации концепции Zero Trust в Cloud Native мире. А сами примеры того, на что стоит обращать внимание приведены в статье! ) Приятного чтения!

Ссылка: https://blog.paloaltonetworks.com/2020/09/cloud-native-zero-trust/

И это снова мы!

В предыдущем посте мы написали про значимость комплексного подхода по защите контейнеров: на «уровне» образов и runtime. А так ли это важно на самом деле?

Ответ – да. Из показательных примеров можно привести недавно обнаруженную уязвимость CVE-2020-14386, которая позволяет повысить привилегии до root и совершить escape на node.

Специалисты из Sysdig написали потрясающую статью, которая описывает способы обнаружения и устранения указанной уязвимости с использованием их продуктов:

🍭 Falco (runtime защита) – создание правила, которое позволит идентифицировать создание новых socket в контейнер
🍭 Sysdig Secure – использование функционала по анализу workloads с целью идентификации тех, что подвержены рассматриваемой CVE

Для устранения уязвимостей рекомендуется следующее:

🍭 Обновить операционную систему
🍭 Отключить CAP_NET_RAW
🍭 Использовать PodSecurityPolicy

Для последнего отлично подойдет Sysdig Secure PSP Advisor, который позволяет «эмулировать» применение политики для идентификации workloads, которые будут подвержены изменениям, что позволяет минимизировать нежелательный эффект (например, нарушение доступности) при применении политик!

Подробности и примеры можно найти по ссылке: https://sysdig.com/blog/cve-2020-14386-falco/

Всем привет! 22 сентября вышла новая версия Prisma Cloud Compute Edition компании Palo Alto Networks. Версия 20.09.345.

Перечень основных изменений:
🍡 Появилась поддержка VMware Tanzu TAS
🍡 Сканирование git-репозиториев на наличие уязвимых компонентов
🍡 Возможность настройки правил для конкретных кластеров (а не только образов, хостов и пр)
🍡 Добавление новых методов аутентификации (OAuth 2.0 and OpenID Connect)
🍡 Расширение функциональности Web Application Firewall (теперь модуль CNAF называется WAAS)

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

Всем привет!

Решили у вас спросить, какие посты вы хотели бы видеть в нашем канале 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 МСК.