Привет!
В апреле 2020 года был представлен первый вариант Threat Matrix for Kubernetes.
Прошел год, исследования продолжаются, k8s меняется, появляются новые тактики и техники, а некоторые, ранее определенные, становятся менее актуальными.
В связи с этим команда представила обновленный Threat Matrix for Kubernetes!
➕ Что было добавлено:
🍭 Image from a private registry
🍭 Malicious admission controller
🍭 Access managed identity credential
🍭 Exposed sensitive interfaces
🍭 Sidecar injection
🍭 CoreDNS poisoning
🍭 ARP poisoning and IP spoofing
➖ Что стало deprecated:
🍭 Exposed dashboard
🍭 Access Kubernetes dashboard
🍭 Access tiller endpoint
С подробностями можно ознакомиться в блоге Microsoft!
В апреле 2020 года был представлен первый вариант Threat Matrix for Kubernetes.
Прошел год, исследования продолжаются, k8s меняется, появляются новые тактики и техники, а некоторые, ранее определенные, становятся менее актуальными.
В связи с этим команда представила обновленный Threat Matrix for Kubernetes!
➕ Что было добавлено:
🍭 Image from a private registry
🍭 Malicious admission controller
🍭 Access managed identity credential
🍭 Exposed sensitive interfaces
🍭 Sidecar injection
🍭 CoreDNS poisoning
🍭 ARP poisoning and IP spoofing
➖ Что стало deprecated:
🍭 Exposed dashboard
🍭 Access Kubernetes dashboard
🍭 Access tiller endpoint
С подробностями можно ознакомиться в блоге Microsoft!
Microsoft News
Secure containerized environments with updated threat matrix for Kubernetes
The updated threat matrix for Kubernetes adds new techniques found by Microsoft researchers, as well as techniques that were suggested by the community.
Привет!
Как часто вы это слышали: «Сложно, все непонятно, можно как-нибудь попроще, да за 5 минут!». Возможно, что ребята из SNYK тоже это слышали и решили… Сделать просто, понятно и за 5 минут!
По ссылке доступен короткий ролик, который (помимо отличной музыки в начале!) очень доступно объясняет:
🍭 Что плохого может случиться, если container running as root?
🍭 Варианты митигации: ограничение host path mount, OPA rules, runtime protection или использование securityContext?
🍭 Чем runAsNonRoot отличается от комбинации runAsUser/runAsGroup?
🍭 Почему лучше использовать uid, а не имя в директиве USER Dockerfile’a?
🍭 Как использовать SNYK IaC для идентификации трудностей (да, не обошлось без рекламы, но инструментом можно воспользоваться for free)?
Помимо этого, в ссылках под видео можно найти cheatsheet для k8s, а ребята обещают продолжать снимать подобные ролики «Просто и понятно!»
Как часто вы это слышали: «Сложно, все непонятно, можно как-нибудь попроще, да за 5 минут!». Возможно, что ребята из SNYK тоже это слышали и решили… Сделать просто, понятно и за 5 минут!
По ссылке доступен короткий ролик, который (помимо отличной музыки в начале!) очень доступно объясняет:
🍭 Что плохого может случиться, если container running as root?
🍭 Варианты митигации: ограничение host path mount, OPA rules, runtime protection или использование securityContext?
🍭 Чем runAsNonRoot отличается от комбинации runAsUser/runAsGroup?
🍭 Почему лучше использовать uid, а не имя в директиве USER Dockerfile’a?
🍭 Как использовать SNYK IaC для идентификации трудностей (да, не обошлось без рекламы, но инструментом можно воспользоваться for free)?
Помимо этого, в ссылках под видео можно найти cheatsheet для k8s, а ребята обещают продолжать снимать подобные ролики «Просто и понятно!»
YouTube
Kubernetes Quick Hits: SecurityContext and why not to run as root
In this, the first of our series of our Kubernetes Quick Hits videos, Eric Smalling–Sr. Developer Advocate at Synk–runs through topics 1 and 2 from our recently published cheatsheet, 10 Kubernetes Security Context settings you should understand: https://snyk.io/blog/10…
Привет!
В репозитории доступен набор базовых сетевых политик, которые можно использовать при освоении инструмента Network Policy, например:
🍭 DENY all traffic to an application
🍭 LIMIT traffic to an application
🍭 ALLOW all traffic to an application
🍭 ALLOW all traffic from a namespace
🍭 ALLOW traffic from some pods in another namespace
🍭 DENY all non-whitelisted egress traffic in a namespace и другие
Удобно, что автор не только предоставляет политики, но и наглядно объясняет как и что работает, приводит примеры ДО и ПОСЛЕ применения политик.
Для экспериментов удобно использовать инструмент от Cilium, который позволяет создавать Network Policy в «графическом редакторе» (о нем мы писали ранее)
P.S. Надеемся, что найдутся те, кто будет поддерживать и развивать этот repo!
В репозитории доступен набор базовых сетевых политик, которые можно использовать при освоении инструмента Network Policy, например:
🍭 DENY all traffic to an application
🍭 LIMIT traffic to an application
🍭 ALLOW all traffic to an application
🍭 ALLOW all traffic from a namespace
🍭 ALLOW traffic from some pods in another namespace
🍭 DENY all non-whitelisted egress traffic in a namespace и другие
Удобно, что автор не только предоставляет политики, но и наглядно объясняет как и что работает, приводит примеры ДО и ПОСЛЕ применения политик.
Для экспериментов удобно использовать инструмент от Cilium, который позволяет создавать Network Policy в «графическом редакторе» (о нем мы писали ранее)
P.S. Надеемся, что найдутся те, кто будет поддерживать и развивать этот repo!
GitHub
GitHub - ahmetb/kubernetes-network-policy-recipes: Example recipes for Kubernetes Network Policies that you can just copy paste
Example recipes for Kubernetes Network Policies that you can just copy paste - ahmetb/kubernetes-network-policy-recipes
Привет!
В продолжении темы с Network Policy, есть tutorial в котором отлично объясняется что это такое и как это реализовать!
После небольшой вводной части (Pod, Service, Ingress, Egress, Network Policy и т.д.) будет приведена демонстрация, в которой:
🍭 Создается demo-приложение, состоящее из front и back end
🍭 Создаются и применяются политики «ingress deny by default» для backend – ограничение трафика к backend
🍭Создаются и применяются политики «backend ingress allow frontend» - разрешение трафика к backend со стороны frontend
🍭 Создаются и применяются политики «pods allow everything in a namespace» - разрешение трафика внутри namespace, но не за его пределами
🍭 Создаются и применяются политики «backend ingress allow monitoring namespace» - разрешение трафика из другого namespace от определенного pod
🍭 Создаются и применяются схожие политики, но только для Egress
Все показано с примерами кода, с применением/отменой политик, объяснением "почему это работает так", а также с важными аспектами, на которые стоит обратить внимание (например, что такое Stateful Policy Enforcement).
Tutorial продолжает развиваться, в планах выпустить:
🍭 Part 2: Securing access in and out of your cluster
🍭 Part 3; Special cases: Host-networking, Loadbalancers, Health-checking
🍭 Part 4: How to troubleshoot NetworkPolicy and monitor Compliance
P.S. В самой repo можно найти все необходимые файлы для самостоятельного повтора демонстраций
В продолжении темы с Network Policy, есть tutorial в котором отлично объясняется что это такое и как это реализовать!
После небольшой вводной части (Pod, Service, Ingress, Egress, Network Policy и т.д.) будет приведена демонстрация, в которой:
🍭 Создается demo-приложение, состоящее из front и back end
🍭 Создаются и применяются политики «ingress deny by default» для backend – ограничение трафика к backend
🍭Создаются и применяются политики «backend ingress allow frontend» - разрешение трафика к backend со стороны frontend
🍭 Создаются и применяются политики «pods allow everything in a namespace» - разрешение трафика внутри namespace, но не за его пределами
🍭 Создаются и применяются политики «backend ingress allow monitoring namespace» - разрешение трафика из другого namespace от определенного pod
🍭 Создаются и применяются схожие политики, но только для Egress
Все показано с примерами кода, с применением/отменой политик, объяснением "почему это работает так", а также с важными аспектами, на которые стоит обратить внимание (например, что такое Stateful Policy Enforcement).
Tutorial продолжает развиваться, в планах выпустить:
🍭 Part 2: Securing access in and out of your cluster
🍭 Part 3; Special cases: Host-networking, Loadbalancers, Health-checking
🍭 Part 4: How to troubleshoot NetworkPolicy and monitor Compliance
P.S. В самой repo можно найти все необходимые файлы для самостоятельного повтора демонстраций
GitHub
GitHub - networkpolicy/tutorial: Kubernetes Network Policy Tutorial
Kubernetes Network Policy Tutorial. Contribute to networkpolicy/tutorial development by creating an account on GitHub.
Всем привет!
Мы здесь на канале много говорим про оркестраторы, технологии защиты контейнеров и многие полезные штуки для их работы. Но сегодня мы хотели бы затронуть другой не маловажный аспект: эффективность самих образов контейнеров.
Без лишних слов, встречайте: dive
Простая, но в то же время мощнейшая утилита для анализа эффективности слоёв контейнеров и общей эффективности работы с вашими Dockerfile. Проекту почти 4 года и он достаточно активно развивается как автором, так и сообществом. Умеет из коробки следующее:
🍬 Отображать изменения в каждом слое образа
🍬 Отображать содержимое фс контейнера для каждого слоя
🍬 Рассчитывать потенциальные потери места на фс контейнера
🍬 Отображать файлы с пересекающимися изменениями между слоями
🍬 Считать общую эффективность по размеру образа
Утилита умеет работать не только с docker, но и с podman (libpod), запускаться как консольная команда, работать из контейнера и встраиваться в CI процессы. Добавим ко всему этому возможность с помощью yaml файлов настроить по желанию интерфейс и даже собрать образ контейнера "на лёту" с последующим анализом - получается уникальная программа раскрывающая весь потенциал docker inspect по максимуму.
Мы здесь на канале много говорим про оркестраторы, технологии защиты контейнеров и многие полезные штуки для их работы. Но сегодня мы хотели бы затронуть другой не маловажный аспект: эффективность самих образов контейнеров.
Без лишних слов, встречайте: dive
Простая, но в то же время мощнейшая утилита для анализа эффективности слоёв контейнеров и общей эффективности работы с вашими Dockerfile. Проекту почти 4 года и он достаточно активно развивается как автором, так и сообществом. Умеет из коробки следующее:
🍬 Отображать изменения в каждом слое образа
🍬 Отображать содержимое фс контейнера для каждого слоя
🍬 Рассчитывать потенциальные потери места на фс контейнера
🍬 Отображать файлы с пересекающимися изменениями между слоями
🍬 Считать общую эффективность по размеру образа
Утилита умеет работать не только с docker, но и с podman (libpod), запускаться как консольная команда, работать из контейнера и встраиваться в CI процессы. Добавим ко всему этому возможность с помощью yaml файлов настроить по желанию интерфейс и даже собрать образ контейнера "на лёту" с последующим анализом - получается уникальная программа раскрывающая весь потенциал docker inspect по максимуму.
GitHub
GitHub - wagoodman/dive: A tool for exploring each layer in a docker image
A tool for exploring each layer in a docker image. Contribute to wagoodman/dive development by creating an account on GitHub.
Привет!
r2c подготовили небольшой курс «Intro to Semgrep», в котором любой желающий может ознакомиться с написанием правил и интеграцией в CI. В качестве «подопытного» выбран небезызвестный Juice Shop.
Курс состоит из 4-х частей:
🍭 Getting Set Up – подготовительные работы для запуска Semgrep, интеграция с Slack
🍭 Add Semgrep to CI via GitHub Action – добавление инструмента в CI, первые проверки
🍭 Writing Our First Rule – основы написания правил, добавление в проект своего правила
🍭 Auditing Routes – использование инструмента в notify only mode - еще несколько упражнений по написанию проверок, чуть более сложных, чем на предыдущем этапе
Курс простой, может быть использован для знакомства с Semgrep. Все, что необходимо иметь - собственный account на GitHub. И все! Можно приступать!
P.S. В курсе все объясняется, с небольшими примерами, приведено множество ссылок на полезные материалы (преимущественное документация Semgrep, но это все же чуть проще, чем "погружаться с 0")
r2c подготовили небольшой курс «Intro to Semgrep», в котором любой желающий может ознакомиться с написанием правил и интеграцией в CI. В качестве «подопытного» выбран небезызвестный Juice Shop.
Курс состоит из 4-х частей:
🍭 Getting Set Up – подготовительные работы для запуска Semgrep, интеграция с Slack
🍭 Add Semgrep to CI via GitHub Action – добавление инструмента в CI, первые проверки
🍭 Writing Our First Rule – основы написания правил, добавление в проект своего правила
🍭 Auditing Routes – использование инструмента в notify only mode - еще несколько упражнений по написанию проверок, чуть более сложных, чем на предыдущем этапе
Курс простой, может быть использован для знакомства с Semgrep. Все, что необходимо иметь - собственный account на GitHub. И все! Можно приступать!
P.S. В курсе все объясняется, с небольшими примерами, приведено множество ссылок на полезные материалы (преимущественное документация Semgrep, но это все же чуть проще, чем "погружаться с 0")
Привет!
И сноваседая ночь про безопасность Dockerfile! «Сколько можно, да про это уже все написали, да что там нового!» - можете подумать вы.
В целом – согласны, но есть нюанс. В интернете много статей, которые отлично описывают теорию. Есть статьи, где разбирается использование инструментов для проверки образов… А в этой статье собрано все: теория, практика, примеры (как надо и как НЕ надо), инструменты и их базовое использование.
В первой части «Best practices to write Dockerfiles» описываются лучшие практики ИБ при написании Dockerfile (из официальной документации, опыта community).
Далее автор разбирает инструменты-помощники:
🍭 BuildKit: пример инъекции секретов, SSH-взаимодействия
🍭 Hadolint
🍭 Dockle: с небольшим сравнением альтернативных решений
🍭 DockerSlim: включая AppArmor и SecComp
🍭 dive (о котором мы писали ранее)
🍭 Возможности интеграции плагинов в IDE
🍭 OPA и Conftest: написание проверок анализа конфигурации Dockerfile
Ссылки на все вышеупомянутое можно найти в статье. Материал хорош тем, что теперь не надо хранить 10 вкладок в «Избранном», можно добавить только одну ☺️
И снова
В целом – согласны, но есть нюанс. В интернете много статей, которые отлично описывают теорию. Есть статьи, где разбирается использование инструментов для проверки образов… А в этой статье собрано все: теория, практика, примеры (как надо и как НЕ надо), инструменты и их базовое использование.
В первой части «Best practices to write Dockerfiles» описываются лучшие практики ИБ при написании Dockerfile (из официальной документации, опыта community).
Далее автор разбирает инструменты-помощники:
🍭 BuildKit: пример инъекции секретов, SSH-взаимодействия
🍭 Hadolint
🍭 Dockle: с небольшим сравнением альтернативных решений
🍭 DockerSlim: включая AppArmor и SecComp
🍭 dive (о котором мы писали ранее)
🍭 Возможности интеграции плагинов в IDE
🍭 OPA и Conftest: написание проверок анализа конфигурации Dockerfile
Ссылки на все вышеупомянутое можно найти в статье. Материал хорош тем, что теперь не надо хранить 10 вкладок в «Избранном», можно добавить только одну ☺️
Medium
A practical guide to writing secure Dockerfiles
Tools, techniques, and procedures to write secure Dockerfiles
Всем привет!
В нашем канале мы много говорили про безопасность контейнеров и систем оркестрации, про образы и их качество, про процессы, DevOps, делились best practices и много чего ещё.
Но одну тему мы поднимаем не так часто, и виной тому не лень или скукота темы, а скорее то что в отечественном enterprise сегменте эта тема до сих пор не так востребована и распространена как в остальном мире!
Догадываетесь о чем речь? 😊
«Да как тут угадать?» скажете вы, и будете правы, слишком уж неоднозначная подводка получилась.
Ну не будем томить, сегодня будет длинный пост и речь в нем пойдет про безопасность облаков или Cloud Security Posture!
Не секрет, что облачные провайдеры за последнюю декаду развернулись во всей красе. Сегодня нам доступны как готовые шаблоны виртуальных машин для домашнего использования, так и огромные мощности для SaaS, PaaS, IaaS и прочих -aaS.
Все это расположено в монументальных датацентрах по всей планете и поставляется нам с различными уровнями поддержки и ответственности поставщика.
Но чем больше и эфемерней становится инфраструктура, тем сложнее в ней обеспечить безопасность и уследить за всеми событиями.
Ведь одно дело, если мы создали две виртуальные машины, включили и настроили аудит событий, настроили правила фильтрации сетевого трафика и организовали контроль runtime активностей.
И совсем другое дело, когда огромная инфраструктура с виртуальными хостами, гипервизорами, оркестраторами, контейнерами, базами данных и кучей вспомогательных виртуальных сервисов размазаны по датацентрам на разных континентах, и все это находится на разных уровнях абстракции и доступно при этом толпе пользователей с различными уровнями доступа!
Пласт сложностей настолько огромен, что никаким внедрением навесного средства защиты здесь не справиться!
🍩 Что же делать?!
Для начала «разложить слона на части!»
Определить цели, задачи, риски и угрозы, сгруппировать и осмыслить собственные сервисы и их взаимодействия и после этого приступить в «поеданию слона»!
И вот тут мы рады поделимся методическим материалом!
Компания Palo Alto выпустила руководство для чайников по организации облачной безопасности: Cloud Security and Compliane for dummies
В книге достаточно понятно описываются такие вопросы как например:
🍩 Типы облаков и их различия
🍩 Какие угрозы в них бывают
🍩 Лучшие практики
🍩 Упраление рисками
🍩 Огранизация безопасности как процесса
И многое другое!
⚠️ Нужно заметить что методики и рекомендации не привязаны к вендорам или тулзам и ставят целью помочь разобраться в темном лесу Cloud security и понять какие первые шаги предпринять.
Так как документ ограниченного характера, распространять его в открытом виде не представляется возможным, однако после быстрой , ни к чему не обязывающей регистрации на портале, книга становится доступна любому желающему.
Ссылка ниже, уверяем, вы найдёте что-то полезное для себя! 👇
https://www.paloaltonetworks.com/resources/ebooks/cloud-security-compliance-for-dummies
В нашем канале мы много говорили про безопасность контейнеров и систем оркестрации, про образы и их качество, про процессы, DevOps, делились best practices и много чего ещё.
Но одну тему мы поднимаем не так часто, и виной тому не лень или скукота темы, а скорее то что в отечественном enterprise сегменте эта тема до сих пор не так востребована и распространена как в остальном мире!
Догадываетесь о чем речь? 😊
«Да как тут угадать?» скажете вы, и будете правы, слишком уж неоднозначная подводка получилась.
Ну не будем томить, сегодня будет длинный пост и речь в нем пойдет про безопасность облаков или Cloud Security Posture!
Не секрет, что облачные провайдеры за последнюю декаду развернулись во всей красе. Сегодня нам доступны как готовые шаблоны виртуальных машин для домашнего использования, так и огромные мощности для SaaS, PaaS, IaaS и прочих -aaS.
Все это расположено в монументальных датацентрах по всей планете и поставляется нам с различными уровнями поддержки и ответственности поставщика.
Но чем больше и эфемерней становится инфраструктура, тем сложнее в ней обеспечить безопасность и уследить за всеми событиями.
Ведь одно дело, если мы создали две виртуальные машины, включили и настроили аудит событий, настроили правила фильтрации сетевого трафика и организовали контроль runtime активностей.
И совсем другое дело, когда огромная инфраструктура с виртуальными хостами, гипервизорами, оркестраторами, контейнерами, базами данных и кучей вспомогательных виртуальных сервисов размазаны по датацентрам на разных континентах, и все это находится на разных уровнях абстракции и доступно при этом толпе пользователей с различными уровнями доступа!
Пласт сложностей настолько огромен, что никаким внедрением навесного средства защиты здесь не справиться!
🍩 Что же делать?!
Для начала «разложить слона на части!»
Определить цели, задачи, риски и угрозы, сгруппировать и осмыслить собственные сервисы и их взаимодействия и после этого приступить в «поеданию слона»!
И вот тут мы рады поделимся методическим материалом!
Компания Palo Alto выпустила руководство для чайников по организации облачной безопасности: Cloud Security and Compliane for dummies
В книге достаточно понятно описываются такие вопросы как например:
🍩 Типы облаков и их различия
🍩 Какие угрозы в них бывают
🍩 Лучшие практики
🍩 Упраление рисками
🍩 Огранизация безопасности как процесса
И многое другое!
⚠️ Нужно заметить что методики и рекомендации не привязаны к вендорам или тулзам и ставят целью помочь разобраться в темном лесу Cloud security и понять какие первые шаги предпринять.
Так как документ ограниченного характера, распространять его в открытом виде не представляется возможным, однако после быстрой , ни к чему не обязывающей регистрации на портале, книга становится доступна любому желающему.
Ссылка ниже, уверяем, вы найдёте что-то полезное для себя! 👇
https://www.paloaltonetworks.com/resources/ebooks/cloud-security-compliance-for-dummies
Palo Alto Networks
Cloud Security and Compliance for Dummies Guide
Evaluate your cloud security and compliance options. Read the pivotal step-by-step guide on how to secure your cloud, now and in the future.
Всем привет!
Можно долго ругать (или хвалить) Dependency-Check, но сегодня не об этом ☺️ В статье приведен интересный пример того, как можно визуализировать информацию о зависимостях и сделать аналитику более интерактивной для восприятия!
🍭 Потребуется Neo4J база данных, установленный Dependency-Check
🍭 Сканируем исходный код, получаем данные, загружаем в БД
🍭 …
🍭 Visualize it! При помощи разных запросов
Примеры реализации и запросов, а также ссылка на repo проекта доступна в статье.
P.S. Поздравляем вас с наступающими праздниками, желаем отлично отдохнуть и набраться сил!!! ☺️☺️☺️
Можно долго ругать (или хвалить) Dependency-Check, но сегодня не об этом ☺️ В статье приведен интересный пример того, как можно визуализировать информацию о зависимостях и сделать аналитику более интерактивной для восприятия!
🍭 Потребуется Neo4J база данных, установленный Dependency-Check
🍭 Сканируем исходный код, получаем данные, загружаем в БД
🍭 …
🍭 Visualize it! При помощи разных запросов
Примеры реализации и запросов, а также ссылка на repo проекта доступна в статье.
P.S. Поздравляем вас с наступающими праздниками, желаем отлично отдохнуть и набраться сил!!! ☺️☺️☺️
Medium
How to create a Software Bill of Materials in Neo4J
Graph databases are very useful when we try to represent data in a friendly visual way. One of the best use cases i can think of for a…
Привет!
По ссылке доступен repo, который поможет познакомиться с OPA Gatekeeper и Kyverno. Помимо теории доступны небольшие примеры, которые можно воссоздать, используя Minikube.
Материал кратко раскрывает такие темы, как:
🍭 Что такое OPA и OPA Gatekeeper
🍭 Что такое Kyverno
🍭 Верхнеуровневое сравнение OPA Gatekeeper и Kyverno
🍭 Создание отдельных Minikube инсталляций, установка решений
🍭 Создание простых политик (контроль наличия label) с OPA Gatekeeper и Kyverno
Код всех примеров можно найти в самом repo. Кроме того, в материалах можно найти много полезных ссылок, которые могут быть интересны для ознакомления
По ссылке доступен repo, который поможет познакомиться с OPA Gatekeeper и Kyverno. Помимо теории доступны небольшие примеры, которые можно воссоздать, используя Minikube.
Материал кратко раскрывает такие темы, как:
🍭 Что такое OPA и OPA Gatekeeper
🍭 Что такое Kyverno
🍭 Верхнеуровневое сравнение OPA Gatekeeper и Kyverno
🍭 Создание отдельных Minikube инсталляций, установка решений
🍭 Создание простых политик (контроль наличия label) с OPA Gatekeeper и Kyverno
Код всех примеров можно найти в самом repo. Кроме того, в материалах можно найти много полезных ссылок, которые могут быть интересны для ознакомления
GitHub
GitHub - developer-guy/policy-as-code-war: OPA Gatekeeper vs Kyverno
OPA Gatekeeper vs Kyverno. Contribute to developer-guy/policy-as-code-war development by creating an account on GitHub.
Привет!
По ссылке доступна статья, в которой описывается возможная атака на Vanilla Kubernetes.
Автор предлагает следующее:
🍭 Поиск публично доступных kubelet API
🍭 Использование kubelet API для реализации RCE
🍭 Запуск shell в контейнере, запущенном на node
🍭 Идентификация credentials, получение доступа к API-серверу с cluster-admin привилегиями
🍭 Запуск привилегированного контейнера с последующим escape на node
Некоторые из этапов атаки можно реализовать из-за default настроек, которые могут быть (или уже) «отключены», например, анонимная аутентификация к kubelet при установке через kubeadm. Альтернативный пример – Tiller и Helm v2 (который был deprecated в ноября 2020), но все равно есть те, кто его использует. Поэтому на наш взгляд статья неплохо подойдет в качестве обучающего материала.
Статья подробная, с примерами и ссылками на интересные материалы.
P.S. В статье есть этап поиска публично доступных API с использованием Shodan. Напоминаем, что подобные упражнения (даже с благими целями) могут привести к ответственности, вплоть до уголовной. Поэтому крайне рекомендуем начинать с Minikube-части, тем самым эмулируя ситуацию, когда «мы уже нашли интересующий нас API»
По ссылке доступна статья, в которой описывается возможная атака на Vanilla Kubernetes.
Автор предлагает следующее:
🍭 Поиск публично доступных kubelet API
🍭 Использование kubelet API для реализации RCE
🍭 Запуск shell в контейнере, запущенном на node
🍭 Идентификация credentials, получение доступа к API-серверу с cluster-admin привилегиями
🍭 Запуск привилегированного контейнера с последующим escape на node
Некоторые из этапов атаки можно реализовать из-за default настроек, которые могут быть (или уже) «отключены», например, анонимная аутентификация к kubelet при установке через kubeadm. Альтернативный пример – Tiller и Helm v2 (который был deprecated в ноября 2020), но все равно есть те, кто его использует. Поэтому на наш взгляд статья неплохо подойдет в качестве обучающего материала.
Статья подробная, с примерами и ссылками на интересные материалы.
P.S. В статье есть этап поиска публично доступных API с использованием Shodan. Напоминаем, что подобные упражнения (даже с благими целями) могут привести к ответственности, вплоть до уголовной. Поэтому крайне рекомендуем начинать с Minikube-части, тем самым эмулируя ситуацию, когда «мы уже нашли интересующий нас API»
Medium
Attacking Kubernetes clusters using the Kubelet API
Knock-knockin’ on kubelet’s door. From the doormat to full node access.
Всем привет!
В начале года SNYK запустил серию опросов для подготовки отчета о состоянии ИБ в Cloud Native. В символичную дату, 4 мая (Да прибудет с Вами Сила!) ребята сделали отчет «State of Cloud Native Application Security» доступным и интерактивным!
Некоторые findings:
🍭 99% респондентов считают обеспечение ИБ значимым аспектом их Cloud Native стратегии
🍭 78% workloads представляют из себя контейнеры и serverless
🍭 50% опрошенных практикуют Infrastructure as Code
🍭 56% - были проблемы ИБ, связанные с misconfiguration
🍭 60% - повышение озабоченности об ИБ при переходе в Cloud Native
🍭 72% команд устраняют критичные недостатки за 1 неделю (рассматриваются команды, обладающие значительной автоматизации процессов)
Остальную информацию, выводы и инфографику можно посмотреть в самом отчете ☺️
В начале года SNYK запустил серию опросов для подготовки отчета о состоянии ИБ в Cloud Native. В символичную дату, 4 мая (Да прибудет с Вами Сила!) ребята сделали отчет «State of Cloud Native Application Security» доступным и интерактивным!
Некоторые findings:
🍭 99% респондентов считают обеспечение ИБ значимым аспектом их Cloud Native стратегии
🍭 78% workloads представляют из себя контейнеры и serverless
🍭 50% опрошенных практикуют Infrastructure as Code
🍭 56% - были проблемы ИБ, связанные с misconfiguration
🍭 60% - повышение озабоченности об ИБ при переходе в Cloud Native
🍭 72% команд устраняют критичные недостатки за 1 неделю (рассматриваются команды, обладающие значительной автоматизации процессов)
Остальную информацию, выводы и инфографику можно посмотреть в самом отчете ☺️
Snyk
Cloud Native Application Security Report | Snyk
New research reveals 60% of organizations have increased security concerns since adopting cloud native. Read the full State of Cloud Native Application Security report for all of the latest trends.
import this
- при помощи такой команды можно увидеть «Zen of Python» и на наш взгляд она отлично подходит для описания того, что приведено в статье «Nine Pillars of DevOps Best Practices».
Автор собрал общие практики, про которые важно помнить при развитии DevSecOps и "разбил" их по нескольким категориям
🍭 Leadership Practices for DevOps
Тезисы о том, на что обращать внимание при работе с командой
🍭 Collaborative Culture Practices for DevOps
Тезисы о развитии взаимодействия, обмена опытом и эффективности
🍭 Design-for-DevOps Practices for DevOps
Тезисы об «облике» программного обеспечения
🍭 Continuous Integration Practices for DevOps
Тезисы о сборке программного обеспечения
🍭 Continuous Testing Practices for DevOps
Тезисы о тестах и их использовании
🍭 Elastic Infrastructure Practices for DevOps
Тезисы о создании масштабируемого и поддерживаемого контура разработки
🍭 Continuous Monitoring Practices for DevOps
Тезисы про мониторинг, его автоматизацию
🍭 Continuous Security Practices for DevOps
Тезисы про обеспечения ИБ, ответственность сторон и автоматизацию
🍭 Continuous Delivery Practices for DevOps
Тезисы про оптимизацию и корректное выстраивание процесса deployment
На первый взгляд может показаться, что «это общие слова ни о чем». Но если читать вдумчиво, то из этого может получиться неплохой инструмент оценки того, что реализовано, что можно и нужно реализовать, что важно не забыть. Надеемся, что статья будет вам полезной!
P.S. Поздравляем всех с наступающим праздником 9-го мая!!! С Днем Победы!!!
- при помощи такой команды можно увидеть «Zen of Python» и на наш взгляд она отлично подходит для описания того, что приведено в статье «Nine Pillars of DevOps Best Practices».
Автор собрал общие практики, про которые важно помнить при развитии DevSecOps и "разбил" их по нескольким категориям
🍭 Leadership Practices for DevOps
Тезисы о том, на что обращать внимание при работе с командой
🍭 Collaborative Culture Practices for DevOps
Тезисы о развитии взаимодействия, обмена опытом и эффективности
🍭 Design-for-DevOps Practices for DevOps
Тезисы об «облике» программного обеспечения
🍭 Continuous Integration Practices for DevOps
Тезисы о сборке программного обеспечения
🍭 Continuous Testing Practices for DevOps
Тезисы о тестах и их использовании
🍭 Elastic Infrastructure Practices for DevOps
Тезисы о создании масштабируемого и поддерживаемого контура разработки
🍭 Continuous Monitoring Practices for DevOps
Тезисы про мониторинг, его автоматизацию
🍭 Continuous Security Practices for DevOps
Тезисы про обеспечения ИБ, ответственность сторон и автоматизацию
🍭 Continuous Delivery Practices for DevOps
Тезисы про оптимизацию и корректное выстраивание процесса deployment
На первый взгляд может показаться, что «это общие слова ни о чем». Но если читать вдумчиво, то из этого может получиться неплохой инструмент оценки того, что реализовано, что можно и нужно реализовать, что важно не забыть. Надеемся, что статья будет вам полезной!
P.S. Поздравляем всех с наступающим праздником 9-го мая!!! С Днем Победы!!!
DevOps.com
Best of 2021 – Nine Pillars of DevOps Best Practices
By following the nine pillars of practices in this blog, organizations can achieve the performance potential that DevOps has to offer.
В августе Linux исполнится 30 лет. И если кто ещё не читал книжку Just for fun - крайне рекомендую. Без Линуса Торвальдса не было бы не то что Docker и Kubernetes, даже git. Страшно вспомнить время, когда мы всей командой переходили с CVS на SVN и поглядывали на первые, но уже такие удобные сборки git, а старшие коллеги матерились, что и так все работает, пусть не очень удобно.
Но пост не о том. Сам мастер Торвальдс хоть и говорит все время, что он простой инженер, своими действиями, а не указами и философиями, влияет не только на этот мир. Даже на Марсе самая распространенная ОС - Linux ;) Не хочу вытаскивать отдельные цитаты из интервью, обе части достойны прочтения. Enjoy!
https://www.tag1consulting.com/blog/interview-linus-torvalds-linux-and-git и
https://www.tag1consulting.com/blog/interview-linus-torvalds-open-source-and-beyond-part-2
Но пост не о том. Сам мастер Торвальдс хоть и говорит все время, что он простой инженер, своими действиями, а не указами и философиями, влияет не только на этот мир. Даже на Марсе самая распространенная ОС - Linux ;) Не хочу вытаскивать отдельные цитаты из интервью, обе части достойны прочтения. Enjoy!
https://www.tag1consulting.com/blog/interview-linus-torvalds-linux-and-git и
https://www.tag1consulting.com/blog/interview-linus-torvalds-open-source-and-beyond-part-2
Tag1 Consulting
An Interview With Linus Torvalds: Linux and Git - Part 1 30 Years Of Linux
Thirty years ago, Linus Torvalds was a 21 year old student at the University of Helsinki when he first released the Linux Kernel. His announcement started, “I’m doing a (free) operating system (just a hobby, won't be big and professional…)”. Three decades…
Всем привет!
SNYK «открыли» бесплатный доступ к Snyk Code – SAST, о котором мы писали ранее. Для бесплатного использования дается 100 сканирований в месяц, при этом важно помнить, что решение на 100% облачное, но для собственных тестов может быть интересно.
Поддерживаются следующие языки:
🍭 Java
🍭 JavaScript
🍭 Python
🍭 TypeScript
Доступна интеграция с CI/CD (Jenkins, либо через CLI) и IDE (Visual Studio Code, PyCharm, Intellij IDEA). Из любопытного – очень интересная система рекомендаций о том, «сколько раз был найдена схожая проблема», «как ее решали другие» с примерами исходного кода!
SNYK «открыли» бесплатный доступ к Snyk Code – SAST, о котором мы писали ранее. Для бесплатного использования дается 100 сканирований в месяц, при этом важно помнить, что решение на 100% облачное, но для собственных тестов может быть интересно.
Поддерживаются следующие языки:
🍭 Java
🍭 JavaScript
🍭 Python
🍭 TypeScript
Доступна интеграция с CI/CD (Jenkins, либо через CLI) и IDE (Visual Studio Code, PyCharm, Intellij IDEA). Из любопытного – очень интересная система рекомендаций о том, «сколько раз был найдена схожая проблема», «как ее решали другие» с примерами исходного кода!
Snyk
Snyk Code is now available for free | Snyk
Snyk Code now offers up to 100 vulnerability scans for free. This modern SAST joins Snyk Open Source and Snyk Container in our Free plan.
Всем привет!
Небольшая, но крайне поучительная статья доступна по ссылке. Суть ее очень проста и кроется в названии – «Everyone might be a cluster-admin in your Kubernetes cluster»
На примере реально существующего проекта "Spekt8" (а идея и правда заманчивая - красивая визуализация взаимодействия сущностей внутри кластера) автор показывает, что может произойти, если не задумываясь делать deploy проектов/утилит до их изучения.
Например, предоставление cluster-admin всем pods в default namespace. И да, это требуется согласно инструкции.
Кроме примеров того, как можно развить тему автор подготовил небольшой проект, который наглядно показывает, как эксплуатировать указанную уязвимость. Ознакомиться с ним можно по ссылке.
PS У статьи нет preview, поэтому дублируем ссылку: https://www.jeffgeerling.com/blog/2020/everyone-might-be-cluster-admin-your-kubernetes-cluster
Небольшая, но крайне поучительная статья доступна по ссылке. Суть ее очень проста и кроется в названии – «Everyone might be a cluster-admin in your Kubernetes cluster»
На примере реально существующего проекта "Spekt8" (а идея и правда заманчивая - красивая визуализация взаимодействия сущностей внутри кластера) автор показывает, что может произойти, если не задумываясь делать deploy проектов/утилит до их изучения.
Например, предоставление cluster-admin всем pods в default namespace. И да, это требуется согласно инструкции.
Кроме примеров того, как можно развить тему автор подготовил небольшой проект, который наглядно показывает, как эксплуатировать указанную уязвимость. Ознакомиться с ним можно по ссылке.
PS У статьи нет preview, поэтому дублируем ссылку: https://www.jeffgeerling.com/blog/2020/everyone-might-be-cluster-admin-your-kubernetes-cluster
GitHub
GitHub - geerlingguy/k8s-pod-rbac-breakout: Kubernetes Pod RBAC Breakout
Kubernetes Pod RBAC Breakout. Contribute to geerlingguy/k8s-pod-rbac-breakout development by creating an account on GitHub.
Всем пятница!
Если вы знаете, что общего у Netflix, обезьян и хаоса, то эта статья вам понравится! По ссылке доступна подборка Chaos Engineering Tools, которые можно применять в k8s!
🍭 kube-monkey. Один из первых проектов 2016 года. Суть проста – запускается по расписанию, выбирает deployment-жертвы, у которых в течение дня будут удаляться pods
🍭 chaoskube. Аналогично предыдущему – «убивает» pod в произвольном namespace раз в 10 минут (по умолчанию)
🍭 Chaos Mesh. Более продвинутый инструмент: помимо «убийства» pod может делать cpu/memory burn, сетевые проблемы (delay, packet repeats), нарушать работу IO и не только
🍭 Litmus Chaos. Все по-взрослому, позволяет проводить «эксперименты», обладает полноценной документацией
🍭 Chaos Toolkit. Python-инструменты, обладает набором расширений, один из которых – chaostoolkit-kubernetes. Позволяет управлять контейнерами, сервисами, больше – по ссылке!
🍭 KubeInvaders. А про этот вариант мы уже как-то писали ☺️
Перед использованием указанных выше инструментов НАСТОЙЧИВО РЕКОМЕНДУЕМ ЧИТАТЬ ДОКУМЕНТАЦИЮ, тк последствия могут быть не самые приятные. Всем хорошим выходных! ☺️☺️☺️
Если вы знаете, что общего у Netflix, обезьян и хаоса, то эта статья вам понравится! По ссылке доступна подборка Chaos Engineering Tools, которые можно применять в k8s!
🍭 kube-monkey. Один из первых проектов 2016 года. Суть проста – запускается по расписанию, выбирает deployment-жертвы, у которых в течение дня будут удаляться pods
🍭 chaoskube. Аналогично предыдущему – «убивает» pod в произвольном namespace раз в 10 минут (по умолчанию)
🍭 Chaos Mesh. Более продвинутый инструмент: помимо «убийства» pod может делать cpu/memory burn, сетевые проблемы (delay, packet repeats), нарушать работу IO и не только
🍭 Litmus Chaos. Все по-взрослому, позволяет проводить «эксперименты», обладает полноценной документацией
🍭 Chaos Toolkit. Python-инструменты, обладает набором расширений, один из которых – chaostoolkit-kubernetes. Позволяет управлять контейнерами, сервисами, больше – по ссылке!
🍭 KubeInvaders. А про этот вариант мы уже как-то писали ☺️
Перед использованием указанных выше инструментов НАСТОЙЧИВО РЕКОМЕНДУЕМ ЧИТАТЬ ДОКУМЕНТАЦИЮ, тк последствия могут быть не самые приятные. Всем хорошим выходных! ☺️☺️☺️
Palark
Open Source solutions for chaos engineering in Kubernetes
This article reviews existing tools for implementing chaos engineering in K8s including kube-monkey, chaoskube, Chaos Mesh, Litmus Chaos, Chaos Toolkit, some games, and even more.
Всем привет!
Если вы на пути (или задумываете) о сдаче экзамена Certified Kubernetes Security Specialist (CKS), то этот вебинар может быть вам полезен.
Ребята из Sysdig рассмотрят:
🍭 Обзор вопросов и их типов, которые будут на экзамене
🍭 Знания каких инструментов из перечня CNCF потребуются/помогут
🍭 Как «управлять временем» при сдаче экзамена – на что обращать внимание в первую очередь
🍭 Обзор примеров из жизни
Вебинар назначен на 20 мая, на 19:00!
Если вы на пути (или задумываете) о сдаче экзамена Certified Kubernetes Security Specialist (CKS), то этот вебинар может быть вам полезен.
Ребята из Sysdig рассмотрят:
🍭 Обзор вопросов и их типов, которые будут на экзамене
🍭 Знания каких инструментов из перечня CNCF потребуются/помогут
🍭 Как «управлять временем» при сдаче экзамена – на что обращать внимание в первую очередь
🍭 Обзор примеров из жизни
Вебинар назначен на 20 мая, на 19:00!
Sysdig
Webinars – Sysdig
Explore Sysdig Webinars and learn how Sysdig is converging security and compliance with DevOps for cloud native production deployments.
Всем привет!
Завтра в 16:00 мы проведем вебинар по нашей любимой теме.
На вебинаре:
🍏 Расскажем про недостатки в дефолтных настройках kubernetes
🍏 Покажем атаку на контейнерный кластер в прямом эфире
🍏 Расскажем и покажем, как оценить угрозы кластера и защититься от них
🍏 Пришлем полезных материалов по теме ИБ в контейнерах
Если интересно — присоединяйтесь, будем рады видеть.
Регистрация
Завтра в 16:00 мы проведем вебинар по нашей любимой теме.
На вебинаре:
🍏 Расскажем про недостатки в дефолтных настройках kubernetes
🍏 Покажем атаку на контейнерный кластер в прямом эфире
🍏 Расскажем и покажем, как оценить угрозы кластера и защититься от них
🍏 Пришлем полезных материалов по теме ИБ в контейнерах
Если интересно — присоединяйтесь, будем рады видеть.
Регистрация
Всем привет!
Хотим мы того или нет, но compliance – неотъемлемая часть ИБ. Например, PCI DSS. И, рано или поздно (для тех, кто имеет отношение к индустрии платежных карт) встанет вопрос – а что делать с требованиями в контейнерных средах?
В статье дается несколько рекомендаций относительно того, как именно можно использовать штатные и не очень возможности для повышения уровня ИБ и выполнении требований стандарта.
Например:
🍭 Firewall configuration. Использование CNI, поддерживающего реализацию Network Policy (подробнее об этом можно почитать тут и тут)
🍭 Encryption of transmission over public networks. Использование Cert-manager для управления X.509 сертификатами
🍭 Use of antivirus software (proactive security). Комбинированный подход с использованием Security Context, Falco и OPA для ограничения потенциальных возможностей контейнера и/или идентификации некорректных действий
🍭 Regularly test security systems and processes. Использование подписи образов на базе Notary совместно сда-да опять оно OPA для контроля запуска только дозволенных в качестве реализации “change detection”
Больше советов и деталей можно найти в статье. Главное помнить, что это не детальный «how to», а скорее размышления на тему, да и реализация compliance-требований в мире ИБ во многом наука творческая ☺️
Хотим мы того или нет, но compliance – неотъемлемая часть ИБ. Например, PCI DSS. И, рано или поздно (для тех, кто имеет отношение к индустрии платежных карт) встанет вопрос – а что делать с требованиями в контейнерных средах?
В статье дается несколько рекомендаций относительно того, как именно можно использовать штатные и не очень возможности для повышения уровня ИБ и выполнении требований стандарта.
Например:
🍭 Firewall configuration. Использование CNI, поддерживающего реализацию Network Policy (подробнее об этом можно почитать тут и тут)
🍭 Encryption of transmission over public networks. Использование Cert-manager для управления X.509 сертификатами
🍭 Use of antivirus software (proactive security). Комбинированный подход с использованием Security Context, Falco и OPA для ограничения потенциальных возможностей контейнера и/или идентификации некорректных действий
🍭 Regularly test security systems and processes. Использование подписи образов на базе Notary совместно с
Больше советов и деталей можно найти в статье. Главное помнить, что это не детальный «how to», а скорее размышления на тему, да и реализация compliance-требований в мире ИБ во многом наука творческая ☺️
elastisys
PCI DSS compliance in Kubernetes-based platforms - elastisys
Kubernetes alone does not help achieve PCI DSS compliance. We cover the 12 requirements of how fintech businesses can make it more compliant.
Привет!
По ссылке доступна еще одна awesome-подборка, на этот раз посвященная плагинам для kubectl!
Плагины структурированы по логическим направлениям: RBAC, Linting, Debugging, Networking, Security, Exec и т.д.
Примеры того, что можно найти:
🍭 kubectl-who-can // RBAC – утилита, позволяющая понять полномочия по отношению к сущности Kubernetes
🍭 kubectl-neat // Linting – утилита, упрощающая восприятие JSON/YAML вывода, путем «устранения лишней» информации
🍭 kubectl-debug // Debug – запускает контейнер внутри целевого pod для выполнения debugging
🍭 ksniff // Networking – sniffing трафика с использованием wireshark и tcpdump
🍭 kubectl-kubesec // Security – анализ запущенных требований на соответствие требованиям ИБ
🍭 kubectl-enter // Exec – exec на node с использованием kubectl
И многое другое! Надеемся, что каждый найдет что-то интересное/подходящее для себя ☺️
По ссылке доступна еще одна awesome-подборка, на этот раз посвященная плагинам для kubectl!
Плагины структурированы по логическим направлениям: RBAC, Linting, Debugging, Networking, Security, Exec и т.д.
Примеры того, что можно найти:
🍭 kubectl-who-can // RBAC – утилита, позволяющая понять полномочия по отношению к сущности Kubernetes
🍭 kubectl-neat // Linting – утилита, упрощающая восприятие JSON/YAML вывода, путем «устранения лишней» информации
🍭 kubectl-debug // Debug – запускает контейнер внутри целевого pod для выполнения debugging
🍭 ksniff // Networking – sniffing трафика с использованием wireshark и tcpdump
🍭 kubectl-kubesec // Security – анализ запущенных требований на соответствие требованиям ИБ
🍭 kubectl-enter // Exec – exec на node с использованием kubectl
И многое другое! Надеемся, что каждый найдет что-то интересное/подходящее для себя ☺️
GitHub
GitHub - ishantanu/awesome-kubectl-plugins: Curated list of kubectl plugins
Curated list of kubectl plugins. Contribute to ishantanu/awesome-kubectl-plugins development by creating an account on GitHub.