Всем привет!

Сегодня за инструменты. kube-psp-advisor - утилита от Sysdig, которая помогает упростить разработку Pod Security Policies (политики для реализации контекстов ИБ в Kubernetes). Она может работать как с реальной конфигураций Kubernetes, так и с конкретными YAML файлами, содержащими спецификацию подов (например, с Deployment, DaemonSet и пр)

Утилита имеет 2 команды:
🍡kube-psp-advisor inspect - выполняет подключение к API серверу кластера и сканирует workload-ы в конкретном namespace или во всем кластере, затем генерирует PSP
🍡kube-psp-advisor convert - анализирует YAML, затем генерирует PSP

Установка утилиты осуществляется одним из вариантов:
🍡Через Krew плагин
🍡Сборка (make build)
🍡Контейнер

Дополнительную информацию, такую как описание сценариев использования, пример политик и пр, можно найти по ссылке: https://github.com/sysdiglabs/kube-psp-advisor?utm_sq=gn81msojq4

Привет!

Компания Sonatype расширила свое предложение, добавив туда Nexus Container и расширив возможности Lifecycle добавлением Infrastructure as Code Pack.

Nexus Container позволяет сканировать образы на наличие уязвимостей и compliance-несоответствий, но, что наиболее интересно на наш взгляд: «Not only do we continuously monitor your containers to identify vulnerabilities and share available fixes once in-production, we’re the only solution that can enforce Data Loss Protection and prevent zero-day malware and network attacks, tunneling, and breaches». Container DLP engine – звучит интересно, что из себя представляет на практике пока не очень понятно (как только протестируем – расскажем!)

Infrastructure as Code помогает выбирать наиболее безопасные open-source компоненты для использования в вашей инфраструктуре

Немного подробней можно почитать тут:
🍭 Nexus Container: https://www.sonatype.com/nexus/container?topnav=true
🍭 Infrastructure as Code: https://www.sonatype.com/nexus/infrastructure-as-code?topnav=true

Всем привет!

Бывают случаи, когда необходимо создать контейнер из другого контейнера (runner в CI, сбор дополнительных метрик). Как это можно сделать?

Есть несколько основных «стратегий»:
🍭 Docker in Docker, DinD – официальный образ, который позволяет запускать контейнер внутри контейнера we need to go deeper. Нюанс – ему требуется –privileged
🍭 Docker out of Docker, DooD – реализуется через mount /var/run/docker.sock, что позволяет использовать docker engine хоста для запуска контейнера «по соседству». Нюанс – можно получить информацию о контейнерах на хосте
🍭 Альтернативные runtime – реализуется при помощи «подмены» runtime, например, на sysbox-runc

Более подробно про это можно почитать в статье. В целом практика, хоть и существует, не является безопасной и рекомендуемой.

А вы используете такие подходы? Если да, то зачем и почему без этого нельзя обойтись?

Всем привет!

Kyverno – это инструмент для работы с политиками в Kubernetes, который может использоваться как для сканирования ресурсов кластера на соответствие лучшим практикам, так и для реализации этих практик путем блокировки или изменения API запросов. Важной особенностью является то, что управление политиками осуществляется аналогично управлению ресурсами Kubernetes. Это значит, что а) изучение нового языка (как в случае с OPA используется Rego, например) не требуется и б) управление политиками можно реализовать через стандартные утилиты, такие как kubectl.

Что можно делать с Kyverno?
🍡Проверять, изменять или генерировать любые ресурсы (например, генерировать квоты для namespaces при необходимости)
🍡Блокировать ресурсы или генерировать отчеты о нарушении политик
🍡Проверять политики и ресурсы в CI/CD сборке до применения в кластере, используя Kyverno CLI и пр.

Как работает Kyverno?
🍡Kyverno запускается в кластере как динамический admission controller,
🍡Посредством webhook получает проверяющие или изменяющие HTTP запросы с kube-apiserver
🍡Применяет соответствующие политики контроля
Установить Kyverno можно или напрямую из манифеста, или используя Helm.

Более подробная информация находится здесь: https://kyverno.io/docs/

А есть ли примеры?
Примеры есть. Один из них представлен ниже.

Запрет на использование пользователя с правами root

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: disallow-root-user
spec:
  validationFailureAction: audit
  rules:
  - name: validate-runAsNonRoot
    match:
      resources:
        kinds:
        - Pod
    validate:
      message: "Running as root user is not allowed. Set runAsNonRoot to true"
      anyPattern:
      - spec:
          securityContext:
            runAsNonRoot: true
      - spec:
          securityContext:
            runAsUser: ">0"
      - spec:
          containers:
          - securityContext:
              runAsNonRoot: true
      - spec:
          containers:
          - securityContext:
              runAsUser: ">0"

Больше примеров можно найти по ссылке: https://github.com/kyverno/kyverno/blob/main/samples/README.md

Всем привет!

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

Сегодня спешим поделиться чудесной, прелестно-прекрасной, абсолютно бесполезной, и от того не менее изящной утилитой Kubecraft!

«Название кажется подозрительно знакомым» - скажете вы
«Все верно!» - ответим мы!

Визуализация объектов в кластере Kubernetes через стандартный Minecraft клиент!
Просто загружаете образ сервера в кластер, выполняете expose приложения наружу, подключаетесь по этому адресу и вуаля! В мир Minecraft с неба падают свиньи, коровы и куры ваших приложений в кластере! Почувствуй себя Kubernetes фермером!

Разобраться легко:
🍩 Хрюшки - pods
🍩 Коровки - replicasets
🍩 Курочки - services
🍩 Лошадки - deployments

Щас бы подам хвосты накрутить, ух! Но если это нужно, то можно и управлять workload’ами. Например, удалить deployment, забив лошадь... 😱
2021 год, будущее уже здесь!

Ссылочка на GitHub проекта ниже!
Приятных исследований 😊👇

https://github.com/stevesloka/kubecraft

Привет!

В приложении отчет, подготовленный компанией GitGuardian. Суть отчета проста – показать сколько секретов (API keys, database connection strings, private keys, certificates, usernames and passwords) может быть в репозиториях, используемых командами разработки. Для формирования выборки использовались 2,5 миллиона public commits/per day.

Итого:
🍭 Более 5000 секретов/день
🍭 Более 2 000 000 секретов было идентифицировано в 2020 году
🍭 Наиболее часто удавалось идентифицировать Google Keys (27,6%)
🍭 Вторым «по популярности» идут секреты Development Tools (Django, RapidAPI, Okta, 15,9%)

Кроме того, в отчете приведены ссылки на известные случаи утечки секретов у известных компаний (Uber, Starbucks, Equifax, UN)

Всем привет!

В Windows 10 есть одна интересная возможность, которая отключена by default – WSL2 (Windows Subsystem for Linux). Все достаточно просто – практически полноценный bash для Windows без необходимости установки полноценной *nix виртуальной машины!

Устанавливается (активируется, скачивается необходимый "дистрибутив") очень просто, об этом можно почитать тут.

Зачем это нужно? Да много зачем 😊 Один из возможных сценариев
🍭 Скачиваем Visual Studio Code (можно добавить YAML-edition функциональность)
🍭 Настраиваем интеграцию с WSL2 (об этом можно почитать тут)
🍭 Устанавливаем Docker for Windows, попутно интегируя с WSL2 (об этом можно почитать тут)
🍭 Устанавливаем Minikube и kubectl

Готово! Мы получили небольшой стенд, который можно использовать для тестирования и обучения по контейнерам без необходимости создания отдельной VM (если вы привыкли к Windows и не хотите «городить огород»). Подробнее можно почитать в этой статье.

P.S. Единственный нюанс, необходимо прописать alias в ~/.bashrc, чтобы можно было пользовать "kubectl", а не "kubectl.exe", т.к. сам по себе WSL2 этого не делает, аналогично с docker и т.д.

Привет!

В феврале 2021 года была анонсирована новость о покупке StackRox Red Hat’ом. Теперь продукт называется Red Hat Advanced Cluster Security for Kubernetes.

Многим было интересно, как именно OpenShift будет работать вместе с StackRox. Время пришло! Ребята объявили вебинар, на котором будут рассмотрены вопросы (теория + демонстрация):

🍭 Обеспечение безопасности supply chain – сканирование образов и реестров, интеграция с CI/CD
🍭 Защита инфраструктуры – конфигурация Kubernetes, compliance, security posture management
🍭 Защита run time – управление привилегия, контроль сети, анализ и реагирование на угрозы

Вебинар пройдет 24 марта (среда) в 17:00 по Москве. Регистрация доступна по ссылке.

Preview не работает, поэтому дублируем ссылку: https://security.stackrox.com/Kube-native-Security-with-OpenShift_Registration.html?Source=Community&LSource=Community

Всем привет!

Управление уязвимостями – одновременно простая (много инструментов, чтобы их найти) и сложная (за что браться в первую очередь, реально ли эта уязвимость exploitable и т.д.) задача. Еще одной «проблемой» становится отсутствие «единой точки управления», которая позволит если не управлять сканированиями, то хотя бы агрегировать информацию в себе.

Одними из примеров решений, решающих такую задачу являются Defect DOJO (open source), Archery (open source) и ThreadFix (entrerprise).

Есть еще один интересный представитель подобного класса решений – Vulcan Cyber!

🍭 Прочитать про него можно на сайте (в самом низу есть набор whitepaper)
🍭 Интеграций много, ознакомиться с ними можно по ссылке
🍭 Есть возможность получения free account (с некоторыми ограничениями, указанными по ссылке)

Единственный «нюанс» - решение облачное и подойдет в РФ далеко не всем, но проект достаточно интересный благодаря предлагаемому функционалу

Всем привет!

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

Итак, сегодня расскажем про Denial of Service Container - Dostainer!

🍩 Маленькая утилита оформленная в контейнере, организующая стресс-тест вашего k8s кластера.

🍩 Контейнер содержит несколько скриптов, аллоцирующих всю доступную оперативную память и дисковое пространство

🍩 Контейнер так же содержит fork-бомбу, генерирующую множество процессов

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

Стоит отметить, что утилита призвана искать бреши в ресурсных квотах. Таким образом, если ваш деплой приложений подвергается наложению resource quotas по умолчанию, вам выполнение этого теста не страшно.

⚠️Внимание!⚠️
Однако, если запустить контейнер без limits для ресурсов, он может отправить ноду или весь кластер в отказ!

Будьте осторожны и не планируйте стресс-тесты на PROD’е в пятницу 😉

Подробнее на GitHub разработчика 👇
https://github.com/uchi-mata/dostainer

Google kCTF.

kCTF – это инфраструктура Kubernetes для проведения соревнований по CTF.
kCTF состоит из:
🏷 nsjail для изоляции игроков
🏷 Docker для запуска контейнеров
🏷 Kubernetes для управления.

В работе это выглядит следующим образом:
🍏 В кластере есть группа заданий.
🍏 Каждое задание представляет собой Deployment в Kubernetes.
🍏 Внутри каждого Deployment есть группа контейнеров.
🍏 Один контейнер выполняет healthchecks – т.е. проверяет, удалось ли вам запустить эксплойт.
🍏 Другой контейнер запускает задание. Задание использует nsjail и создает новое окружение для каждого TCP соединения.

Подробности работы и инструкции для проведения CTF смотрите на https://github.com/google/kctf

Всем привет!

По ссылке доступна статья из целого цикла статей, которые направлены на подготовку к сдаче экзамена CKS (Certified Kubernetes Specialist).

Статья посвящена Network Policy и тому, как их «готовить». Задача проста – «Create a default deny NetworkPolicy and then allowlist more traffic», приводится ее решение, состоящее из следующих шагов:

🍭 Создаем namespace
🍭 Добавляем Egress Default Deny
🍭 Разрешаем DNS
🍭 Разрешаем Egress к некоторым Pods
🍭 Игнорируем Ingress трафик

Статья простая, понятная и с примерами. В ней можно найти ссылки на другие статьи, которые могу пригодиться при подготовке к CKS (Immutable Pods, ImagePolicyWebhook, Container Hardening и т.д.). Структура везде одинакова – описание задачи и ее возможное решение.

P.S. В статье можно найти упоминание удобного инструмента для редактирования Network Policy, о котором мы писали ранее.

Всем привет!

Согласитесь, достаточно удобно когда названия ваших веток в git несут смысл, а с коммитом приходит нормальное описание (ещё лучше когда со ссылкой на задачи в Jira). А знаете, что у Gitlab до есть целая группа функций "Push Rules", которые позволяля делать такие полезные вещи:
🍬 запретить удалять тэги при использование git push
🍬 использовать регулярные выражения для проверки email авторов
🍬 запретить пушить секреты в явном виде
🍬 использовать регулярные выражения для проверки сообщения коммита
🍬 запретить пушить определенных расширения файлов
🍬 использовать регулярные выражения для проверки названия новых веток

Почитать подробнее можно по ссылке.

К сожалению с обновления 13.9 и смены ценовой политики компании "Push Rules" распространяются начиная от плана Premium.

Всем привет!

По ссылке можно скачать Lens – open source IDE для Kubernetes! Удобный инструмент для тех, кто все же предпочитает использование GUI вместе с консолью.

Чем может помочь Lens?
🍭 Устанавливается на Windows, Linux, Mac
🍭 Наглядное структурирование nodes, namespaces, services, deployments, statefulsets, pods и т.д.
🍭 Работа с multiple clusters
🍭 Поддержка RBAC Kubernetes
🍭 Возможность получения доступа к pod terminal
🍭 Предоставление метрик использования ресурсов кластера
🍭 Локальное сохранение логов workloads для дальнейшего debug/troubleshooting и многое другое!

Для того, чтобы быстро понять, что к чему, рекомендуем посмотреть ролик, доступный на сайте по ссылке.

Всех с пятницей!

Всем привет!

У Snyk много удобных cheatsheets с советами о том, как сделать элементы разработки безопаснее. Появился еще один – «10 Kubernetes Security Context settings you should understand».

В нем собраны рекомендации о том, как повысить безопасность кластера, на что обращать внимание:
🍭 runAsNonRoot
🍭 runAsUser / runAsGroup
🍭 seLinuxOptions
🍭 seccompProfile
🍭 privileged / allowPrivilegeEscalation
🍭capabilities
🍭 readonlyRootFilesystem
🍭 procMount
🍭 fsGroup / fsGroupChangePolicy
🍭 sysctls

В статье по ссылке приведены не только сами рекомендации, но еще и объяснения – «Зачем это делать/не делать? Какие последствия могут быть?». Рекомендуем к прочтению!

Всем привет!

Одна из самых больших сложностей процесса управления дефектами – приоритизация: за что браться в первую очередь, что наиболее важно?

В приложении небольшое исследование WhiteSource, посвященное этой теме применительно к open source. Ребята взяли такие «классические» подходы к приоритизации, как:

🍭 Уровень CVSS
🍭 Уровень критичности приложений
🍭 «Популярность» open source
🍭 Disclosure date
🍭 Простота устранения

На этом они не остановились и сделали корреляцию с данными CYR3CON – компании, специализирующейся на предсказании кибератак, в том числе с использованием данных из Deep/Dark Web. Получился интересный результат! Какой? Советуем прочитать отчет ☺️

Всем привет!

Еще одна отличная статья от Snyk, в которой описаны минимальные практики повышения безопасности контейнеров:

🍭 Использование linters
🍭 Запуск linters в качестве commit hooks
🍭 Тестирование образов локально (Docker, Kubernetes)
🍭 Контроль user и linux capabilities (как проверить, как настроить)
🍭 Использование сканеров уязвимостей
🍭 Image slimming практики

Статья интересна тем, что в ней приводится много примеров и отсылок на free инструменты, полезные практики! Сами примеры разбираются, как в контексте Docker, так и в контексте Kubernetes ☺️

🍩 Контейнеры призваны ускорить time-to-market и это очень полезно!
🍩 Системы контейнерной оркестрации помогают в этом, способствуя автоматизации развертывания и масштабирования контейнерных приложений - это еще лучше!

Но как и у любого инструмента, у k8s тоже есть инструкция. Будем же ее читать, чтобы наши контейнеры помогали решать проблемы, а не добавляли их!

Всё, что вы хотели знать о экзамене Certified DevSecOps Professional, но боялись спросить?

Подготовка к экзамену представляет собой:
🥕Просмотр материала курса, куда входят вебинары и ссылки на полезные материалы
🥕Выполнение лабораторных работ, доступ к которым предоставляется на 30 дней

Курс затрагивает такие темы и работу с инструментами как:
🥕Введение в основы
🥕Введение в инструменты работы
🥕Безопасность SDLC и CI/CD пайплайн
🥕Анализ компонентов программного обеспечения в CI/CD
🥕Статический анализ кода в CI/CD
🥕Динамический анализ кода в CI/CD
🥕Инфраструктура как код и её безопасность
🥕Комплаенс как код
🥕Управление уязвимостями с помощью специальных инструментов

Для того, чтобы лучше раскрыть тему, рекомендуем ознакомиться с описанием курса

Сам экзамен проходит в виде 12-ти часовой лабораторной работы и детальному заполнению отчёта по проделанным заданиям, на который даётся 24 часа после завершения практической части

Критерий успешной сдачи - набрать 80 баллов из 100.
🔥Не забудьте получить дополнительные 10 баллов за выполнение бонусной задачи🔥

P.S. Отличный экзамен для тех, кто хочет не только разобраться в теме DevSecOps, но и получить практические навыки.
Не менее важным фактором является то, что команда курса обеспечивает крутую поддержку, оперативно отвечая на вопросы в Slack и реагируя на проблемы

Всем привет!

Для тестирования настроек безопасности или используемых СЗИ зачастую нужен «подопытный», при помощи которого можно проводить испытания.

По ссылке доступен образ BOtB: Break out of the box! Согласно описанию, BOtB – инструмент для анализа и эксплуатации уязвимостей в контейнерах, подготовленный для использования pentester’ами и инженерами.

Что он умеет? Например (список не полный):
🍭 Container breakout через exposed Docker daemons (docker.sock)
🍭 Container breakout через CVE-2019-5736
🍭 Privileged container breakout через имеющиеся CAPS и SYSCALLS
🍭 Идентификация и попытка использования Kubernetes Service Accounts secrets
🍭 Идентификация и анализ чувствительных данных в ENV и процессов в the ProcFS, например /Proc/{pid}/Environ

Все вышеописанное и не только можно реализовать через аргументы CLI или с использованием YAML config file.

P.S. Если захотите протестировать – делайте это аккуратно, в тестовом окружении, сперва детально изучив возможности контейнера