es
Feedback
DevSecOps Talks

DevSecOps Talks

Ir al canal en Telegram

Рассказываем об актуальном в мире DevSecOps. Канал DevSecOps-команды "Инфосистемы Джет"

Mostrar más
7 859
Suscriptores
+824 horas
+397 días
+11330 días
Archivo de publicaciones
Всем привет! Еще одна отличная статья от Snyk, в которой описаны минимальные практики повышения безопасности контейнеров: 🍭 Использование linters 🍭 Запуск linters в качестве commit hooks 🍭 Тестирование образов локально (Docker, Kubernetes) 🍭 Контроль user и linux capabilities (как проверить, как настроить) 🍭 Использование сканеров уязвимостей 🍭 Image slimming практики Статья интересна тем, что в ней приводится много примеров и отсылок на free инструменты, полезные практики! Сами примеры разбираются, как в контексте Docker, так и в контексте Kubernetes ☺️

Всем привет! Одна из самых больших сложностей процесса управления дефектами – приоритизация: за что браться в первую очередь, что наиболее важно? В приложении небольшое исследование WhiteSource, посвященное этой теме применительно к open source. Ребята взяли такие «классические» подходы к приоритизации, как: 🍭 Уровень CVSS 🍭 Уровень критичности приложений 🍭 «Популярность» open source 🍭 Disclosure date 🍭 Простота устранения На этом они не остановились и сделали корреляцию с данными CYR3CON – компании, специализирующейся на предсказании кибератак, в том числе с использованием данных из Deep/Dark Web. Получился интересный результат! Какой? Советуем прочитать отчет ☺️

Всем привет! У Snyk много удобных cheatsheets с советами о том, как сделать элементы разработки безопаснее. Появился еще один – «10 Kubernetes Security Context settings you should understand». В нем собраны рекомендации о том, как повысить безопасность кластера, на что обращать внимание: 🍭 runAsNonRoot 🍭 runAsUser / runAsGroup 🍭 seLinuxOptions 🍭 seccompProfile 🍭 privileged / allowPrivilegeEscalation 🍭capabilities 🍭 readonlyRootFilesystem 🍭 procMount 🍭 fsGroup / fsGroupChangePolicy 🍭 sysctls В статье по ссылке приведены не только сами рекомендации, но еще и объяснения«Зачем это делать/не делать? Какие последствия могут быть?». Рекомендуем к прочтению!

Всем привет! По ссылке можно скачать 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 и многое другое! Для того, чтобы быстро понять, что к чему, рекомендуем посмотреть ролик, доступный на сайте по ссылке. Всех с пятницей!

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

Всем привет! По ссылке доступна статья из целого цикла статей, которые направлены на подготовку к сдаче экзамена 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, о котором мы писали ранее.

Google kCTF. kCTF – это инфраструктура Kubernetes для проведения соревнований по CTF. kCTF состоит из: 🏷 nsjail для изоляции игроков 🏷 Docker для запуска контейнеров 🏷 Kubernetes для управления. В работе это выглядит следующим образом: 🍏 В кластере есть группа заданий. 🍏 Каждое задание представляет собой Deployment в Kubernetes. 🍏 Внутри каждого Deployment есть группа контейнеров. 🍏 Один контейнер выполняет healthchecks – т.е. проверяет, удалось ли вам запустить эксплойт. 🍏 Другой контейнер запускает задание. Задание использует nsjail и создает новое окружение для каждого TCP соединения. Подробности работы и инструкции для проведения CTF смотрите на https://github.com/google/kctf

Всем привет! Поздравляем всех с пятницей! Сегодня можно сбавить обороты, побаловать себя новыми вкусами из ближайшей кофейни и запланировать дела на следующую неделю. А так как lulz toolz в последнее время у нас было достаточно, сегодня мы хотим поделиться полезной штукой, тест которой можно взять как тему для следующей недели! Итак, сегодня расскажем про Denial of Service Container - Dostainer! 🍩 Маленькая утилита оформленная в контейнере, организующая стресс-тест вашего k8s кластера. 🍩 Контейнер содержит несколько скриптов, аллоцирующих всю доступную оперативную память и дисковое пространство 🍩 Контейнер так же содержит fork-бомбу, генерирующую множество процессов С помощью этой утилиты можно провести нагрузочное тестирование вашего кластера целиком или отдельных его нод, на которые приземлится под с контейнером. Стоит отметить, что утилита призвана искать бреши в ресурсных квотах. Таким образом, если ваш деплой приложений подвергается наложению resource quotas по умолчанию, вам выполнение этого теста не страшно. ⚠️Внимание!⚠️ Однако, если запустить контейнер без limits для ресурсов, он может отправить ноду или весь кластер в отказ! Будьте осторожны и не планируйте стресс-тесты на PROD’е в пятницу 😉 Подробнее на GitHub разработчика 👇 https://github.com/uchi-mata/dostainer

Всем привет! Управление уязвимостями – одновременно простая (много инструментов, чтобы их найти) и сложная (за что браться в первую очередь, реально ли эта уязвимость exploitable и т.д.) задача. Еще одной «проблемой» становится отсутствие «единой точки управления», которая позволит если не управлять сканированиями, то хотя бы агрегировать информацию в себе. Одними из примеров решений, решающих такую задачу являются Defect DOJO (open source), Archery (open source) и ThreadFix (entrerprise). Есть еще один интересный представитель подобного класса решений – Vulcan Cyber! 🍭 Прочитать про него можно на сайте (в самом низу есть набор whitepaper) 🍭 Интеграций много, ознакомиться с ними можно по ссылке 🍭 Есть возможность получения free account (с некоторыми ограничениями, указанными по ссылке) Единственный «нюанс» - решение облачное и подойдет в РФ далеко не всем, но проект достаточно интересный благодаря предлагаемому функционалу

Привет! В феврале 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

Всем привет! В 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 и т.д.

Привет! В приложении отчет, подготовленный компанией 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)

Всем привет! С момента большого взрыва, когда из ничего появилась наша вселенная, вместе с ней начало существовать и само время! Миллиарды лет оно движется стабильно и неумолимо, и всегда только в одном направлении. А это значит, что чтобы мы ни делали, она наступает всегда. Пятница! И сколь неизбежно наступление пятницы, столь неумолимо.... Время забавных постов! Сегодня спешим поделиться чудесной, прелестно-прекрасной, абсолютно бесполезной, и от того не менее изящной утилитой Kubecraft! «Название кажется подозрительно знакомым» - скажете вы «Все верно!» - ответим мы! Визуализация объектов в кластере Kubernetes через стандартный Minecraft клиент! Просто загружаете образ сервера в кластер, выполняете expose приложения наружу, подключаетесь по этому адресу и вуаля! В мир Minecraft с неба падают свиньи, коровы и куры ваших приложений в кластере! Почувствуй себя Kubernetes фермером! Разобраться легко: 🍩 Хрюшки - pods 🍩 Коровки - replicasets 🍩 Курочки - services 🍩 Лошадки - deployments Щас бы подам хвосты накрутить, ух! Но если это нужно, то можно и управлять workload’ами. Например, удалить deployment, забив лошадь... 😱 2021 год, будущее уже здесь! Ссылочка на GitHub проекта ниже! Приятных исследований 😊👇 https://github.com/stevesloka/kubecraft

Всем привет! 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

Всем привет! Бывают случаи, когда необходимо создать контейнер из другого контейнера (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 Более подробно про это можно почитать в статье. В целом практика, хоть и существует, не является безопасной и рекомендуемой. А вы используете такие подходы? Если да, то зачем и почему без этого нельзя обойтись?

Привет! Компания 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

Всем привет! Сегодня за инструменты. 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

Большинство из нас регулярно пользуется продуктами HashiCorp вроде Terraform, Vault и Consul, а вот про Nomad многие только слышали. Это оркестратор, в том числе для контейнеров, концептуально отличный от Kubernetes. Краткий экскурс в терминах k8s: https://www.hashicorp.com/blog/a-kubernetes-user-s-guide-to-hashicorp-nomad

Всем привет! Нашли простую и лаконичную статью от Isaac Z. Schlueter (одного из авторов npm), в которой приводятся рекомендации о том, как минимизировать ущерб или не допустить реализацию supply chain attack (о них мы недавно писали) на примере использования npm. Если кратко, то: 🍭 Использование scope для внутренних пакетов (предопределенное имя, начинающееся с @) 🍭 Использование. npmrc файла в корне проекта с указанием @mycompany:registry = https://registry.mycompany.local/, что позволит использовать локальный реестр «по умолчанию» 🍭 Корректно настраивать proxy 🍭 Анализировать причины нарушения сборок (звучит очевидно, но происходит не всегда)

Привет! Многим нравится осуществлять конфигурацию кластером Kubernetes с использованием терминала, но, есть те, кто верит, что «лучше 1 раз увидеть, чем сто раз услышать!». Именно для тех, кто ищет удобный web ui для Kubernetes, рекомендуем обратить внимание на проект Headlamp. Согласно статье, он: 🍭 100% open source 🍭 Активно поддерживается 🍭 Может быть расширен при помощи плагинов 🍭 Позволяет делать read/write – операции, а не read-only Более подробно с решением можно познакомиться, почитав документацию 😊