Привет!

Недавно CNCF анонсировала новую сертификацию – Kubernetes and Cloud Native Associate (KCNA). Сертификация будет подтверждать понимание базовых основ Kubernetes и Cloud Native. Экзамен будет представлять из себя тест с множественным выбором ответов.

Ключевые темы, которые надо знать:
🍭 Kubernetes Fundamentals (46%). Ресурсы, архитектура, API, контейнеры, планировщик (scheduler)
🍭 Container Orchestration (22%). Основы оркестрации, runtime, безопасность, сеть, Service Mesh и хранилище (storage)
🍭 Cloud Native Architecture (16%). Основы Cloud Native архитектура, autoscaling, serverless, community и governance, стандарты
🍭 Cloud Native Observability (8%). Телеметрия и observability, Prometheus и управление затратами
🍭 Cloud Native Application Delivery (8%). Основы application delivery, GitOps и CI/CD

Точный срок запуска KCNA пока что неизвестен, планируемое время – конец 2021 года. Экзамен может стать отличной отправной точкой для изучения сред контейнерной оркестрации и дальнейшего получения сертификаций: CKA, CKAD и CKS 😊

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

Pod-reaper – название говорит само за себя! Утилита (контейнер) для «убийства» pod в соответствии с заданными правилами!

Конфигурация Pod-reaper осуществляется с использованием переменных окружения. Вариативность неплоха, например: NAMESPACE – где искать «жертв»; EVICT – не убиваем, а выселяем (eviction); MAX_PODS – ограничиваем максимальное количество «жертв» и многие другие!

Но самое интересное – это правила! Доступен следующий набор:
🍭 Chaos Chance – убийство «случайной жертвы». Скорее всего отсылка к Chaos Engineering
🍭 Container Status – убиваем pod с определенным статусом, например, CrashLoopBackOff, ErrImagePull и т.д.
🍭 Duration – если жертва работает (run) больше положенного срока – она становится кандидатом на убийство!
🍭 Unready – похоже на предыдущее, только призывом к убийству является срок «неготовности» (unready)

Жертва будет убита, только если она соответствует всем настроенным правилам. Логический «OR» сделать тоже можно – запустив несколько Pod-reaper на кластере.

Помимо этого можно настроить уровень логирования. Доступны: Debug, Info, Warning, Error, Fatal and Panic.

С точки зрения возможностей решению требуется [‘list’, ‘delete’] на [‘pods’] и все это в качестве ClusterRoleBinding или для конкретного Namespace.

P.S. Всем прекрасного вечера и отличных выходных! 😊

Привет!

Kubernetes Pod Inspector – утилита, которая позволяет получить информацию о запущенных процессах внутри контейнера и об его файловой системе.

Устанавливается просто – через deployment, конфигурация которого приведена в repo. Можно запускать утилиту с определенной Service Account. В repo приведен пример манифеста, в котором можно посмотреть на полномочия, которые требуются для Kubernetes Pod Inspector:

rules:
- apiGroups: [""] # 
  resources: ["pods"]
  verbs: ["get", "watch", "list"]
- apiGroups: [""]
  resources: ["pods/exec"]
  verbs: ["create"]
- apiGroups: ["metrics.k8s.io"]
  resources: ["pods", "nodes"]
  verbs: ["get", "watch", "list"]

У утилиты есть графический интерфейс, который показывает необходимую информацию:
🍭 Перечень pods, с дополнительной информацией (status, age, CPU, memory, IP и т.д.)
🍭 Отображение файлов и папок внутри pod/container
🍭 Перечень процессов, которые запущены внутри pod/container

Кроме просмотра можно, например, скачать какой-нибудь файл из pod/container 😊

Всем привет!

Процесс поиска ошибок в deployments может быть трудоемким, особенно если не знаешь куда посмотреть...

Для решения этой проблемы ребята из learnk8s подготовили отличную блок схему, которая может помочь разобраться или подскажет "куда смотреть"!

Возможно, что вы ее уже видели раньше, но есть хорошие новости - она обновляется, по ссылке доступна версия от ноября 2021 года! А если не видели - рекомендуем обратить на нее внимание 😊 Схему можно скачать в PDF и/или PNG формате!

Привет!

Часто, когда говорят про OPA и K8S вместе, на ум приходит Gatekeeper и его возможности по управлению запуском сущностей на основе REGO-правил!

А что, если использовать OPA чуть раньше, например, в CI-процессе (shift left security)? Это вполне возможно, ведь OPA и Gatekeeper это не одно и тоже: Open Policy Agent дает нам возможность писать правила и проверять «что-то» на соответствие этим правилам (a software component that allows users or other systems to query policies for decisions).

В статье приводится простой и наглядный пример использования OPA в GitHub Actions:
🍭 Создаем политику, которая анализирует Kind на «пустоту», «строку» и запрещает «:latest»
🍭 Тестируем это локально, используя OPA eval
🍭 Переносим это в CI (да, в статье это GitHub Actions, но такой подход можно реализовать где угодно)

На выходе получаем еще одну точку анализа манифестов на соответствие политикам информационной безопасности, еще до их deploy (пусть даже и в тестовой среде). В сочетании с Gatekeeper можно добиться интересной синергии 😊

Привет!

- Хэй, чтобы обезвредить бомбу тебе надо ввести ЛЮБУЮ корректную tar-команду. 10 секунд… Гуглить нельзя!
- Извини. Мы обречены…

Комикс из repo отлично иллюстрирует знакомую многим ситуацию: вроде помнишь, как пишется команда, но то ключ забудешь, то какие параметры нужны…

Если у вас не так, то вы – молодец! А если узнали себя – не переживайте, вы не одиноки! Ведь не зря появился проект Cheat (с 8,4к «звезд» на GitHub). Суть его проста – напоминать об основных Linux-командах.

Например, cheat curl выдаст нам:
// To download and rename a file:

curl <url> -o <outfile>

// To download multiple files:

curl -O <url> -O <url>

// To download all sequentially numbered files (1-24):

curl http://example.com/pic[1-24].jpg

// To download a file and pass HTTP authentication:

curl -u <username>:<password> <url>

// To download a file with a proxy:

curl -x <proxy-host>:<port> <url>

Сам по себе Cheat не будет работать, ему нужны cheatsheets, которых огромное количество, и вы точно найдете нужное! Можно настроить под собственные нужды и пользоваться. Подробнее о том, как это сделать показано в repo.

И все же ) А вы ошибаетесь/забываете пусть даже и любимые команды? Пишите в комментариях!

Привет!

Vault-CRD – custom resource definition для Kubernetes, который позволяет упростить управление секретами с использованием HashiCorp Vault. CRD работает с Docker Pull Secret (Docker CFG), Ingress Certificates и JKS Key Store/

Возможные сценарии:
🍭 Создание секрета
1. Vault-CRD получает события для новых Vault-ресурсов
2. Vault-CRD запрашивает секрет из HashiCorp Vault
3. Vault-CRD создает Secret
🍭 Обновление секрета
1. У Vault-CRD есть scheduled задача по просмотру созданных им Secret
2. Указанный Secret сравнивается с тем, что есть в Vault и обновляется при необходимости

Аутентификация самого Vault-CRD в HashiCorp Vault возможна с использованием Token (для тестов подойдет, а дальше лучше не использовать из-за проблемы Secret Zero) или с использованием Kubernetes Authentication (предпочтительный вариант, проверкой занимается условно-доверенная третья сторона).

Доступны следующие типы секретов, которые могут быть сгенерированы при помощи Vault-CRD: Key/Value, PKI, Cert. Поддерживаются следующие версии Secret Engines Vault: K/V1 и K/V2.

Еще одна интересная функция: Change Adjustment Callback – можно сделать так, что deployment будет пересоздан при изменении Secret. Как обычно, больше подробностей можно посмотреть в repo и в документации.

P.S. Всем отличной пятницы и выходных!!! 😊

Всем привет!

Недавно вышло обновление Gatekeeper до версии 3.7.0. Одним из интересных нововведений стала возможность делать mutating-операции.

В статье приводится пример использования нового функционала.

В начале статьи приводится краткое описание mutation, состава политик:
🍭 Mutation scope – то, что мы хотим поменять
🍭 Intent – поле и значение, которое подвергнется изменению
🍭 Conditions – условия, при которых изменение произойдет

Далее в статье создается несколько простых политик, которые добавляют labels в спецификацию pod или меняют значение securityContext.Privileged в значение false.

Общую информацию про admission controllers можно почитать тут, больше информации про обновления в Gatekeeper предоставлено вот тут.

Важно (!) Функционал все еще находится в стадии Alpha и его НЕ рекомендуется использовать в production средах.

Привет!

И причем тут канарейки? Все так, речь пойдет про deployment strategies!

В статье, на примере Kubernetes, рассматриваются такие стратегии как:
🍭 Rolling Update. Один за одним переводим pod’ы старой версии на pod’ы новой версии, сохраняя доступность целевого ресурса. Да, при этом часть пользователей увидит новый функционал, а часть – старый
🍭 Recreate. «Жесткий вариант» - убиваем старую версию и «раскатываем» новую. Да, будет некоторый downtime
🍭 Blue-Green. Существует 2 версии – Blue (текущая) и Green (вот-вот, почти). Но активной является только одна – Blue. Как только все тесты в Green успешно пройдены – переключаем трафик!
🍭 Canary! А вот и она! Новой версии ПО предоставляется небольшой трафик для оценки нововведений со стороны пользователей и/или поиска ошибок/недоработок. Если «Ок» – увеличиваем поток трафика, если нет – дорабатываем и разбираемся с ошибками. Для тех, кому все-таки интересно при чем тут канарейки – грустная статья

Помимо графических схем, поясняющих ту или иную deployment-strategy в статье есть примеры для самостоятельного воспроизведения и технические подробности того, что «происходит под капотом» ☺️

Привет!

Разработка helm-чартов не самый простой процесс, особенно с точки зрения «отладки».

Где-то «съедет» форматирование, где-то забудешь указать необходимые данные, где-то ошибешься с типом (например, «словарь» вместо «списка» и т.д.)

Если это Вам знакомо, то рекомендуем обратить внимание на статью «Kubernetes Helm Charts Testing».

В ней рассматриваются способы проверок helm-чартов и, конечно же, автоматизация:
🍭 KubeEval. Наверное, один из лучших инструментов по теме. Позволяет сопоставить генерируемые helm-chart’ом манифесты со спецификацией Kubernetes и показать, где ошибка/чего не хватает
🍭 Добавим немного ИБ-проверок? Запросто! Conftest! Framework, который позволяет писать OPA-политики на REGO и проверять манифесты на соответствие (кстати, такое можно делать и просто при помощи OPA, об этом мы писали вот тут)
🍭 А что делать если пользователь некорректно указал значение в Values (например, опечатался, в CPU: 250Mi)? Можно использовать инструмент Schema Validation, который позволяет проанализировать данные Values и указать на ошибки
🍭 Тестирование? Есть и такое – helm-unitetst и kubetest...

Вариантов много. Возможно, что не все они нужны, но, как минимум, KubeEval уже значительно облегчит жизнь 😊

Важно (!): в статье не рассматривается процесс написания helm-чартов и применимые лучшие практики, а только способы поиска ошибок

Привет!

Helm позволяет удобно структурировать все, что нужно для deploy и управлять изменениями.

Бывает, что при первом deploy надо создать секреты, используемые для аутентификации сервисов. Это можно сделать "вручную", а можно чуть иначе!

В статье описаны возможные способы автогенерации секретов с использованием возможностей helm:
🍭 Использование генераторов случайных чисел, поддерживаемых Helm
🍭 А если это не первый deployment и секрет уже был создан? Не вопрос, можно использовать "условное" (conditional) создание секрета - несколько if и lookup. Helm проверит существование секрета и создаст его, только если не обнаружит данных
🍭 Явное задание пользователем секрета в Values, но так лучше не делать, если только для тестов

P.S. Всем отличной пятницы и волшебных выходных! 😊

Привет!

Observeability - важный аспект, который помогает нам понимать что происходит в кластере и может быть полезен при поиске ошибок.

У Kubernetes есть сущность - Event - которая помогает более точно понять, что (не)произошло и почему.

В статье автор описывает что это такое и чем это может быть полезно на примере:
🍭 Failed Events. Например, pod не был создан или проблемы в работе node
🍭 Evicted Events. "Переселение" нагрузок не всегда является проблемой, но лучше понимать, что стало причиной
🍭 Storage-Specific Events. Все, что связано с использованием Storage
🍭 Scheduling Events. Почему не получилось выбрать node для нагрузки
🍭 Node-Specific Events. Проблемы с nodes: недоступность, перезапуски и т.д.

Важно помнить, что Events бывают разные: Normal, Information и Warning. Не все из них одинаково полезны и рекомендуются к анализу.

В завершении статьи автор показывает, как можно получить доступ к рассматриваемому объекту и как можно фильтровать запросы.

Всем привет! Если вы ещё не погрузились в тематику защиты контейнеров или только начинаете это делать, мы подготовили небольшое обзорное видео в рамках нашей рубрики Security Small Talk.

Итак, о чем вы узнаете из ролика?
🍬 Что именно нужно защищать и почему обычных СЗИ для этого мало.
🍬Как хакеры атакуют Kubernetes, чем опасны подделки запросов к kube-apiserver или kubelet и что будет, если киберпреступник заберётся внутрь контейнера.
🍬 Готовый фреймворк для защиты кластера на всех уровнях — от узла до контейнера.
🍬Верхнеуровневое знакомство с Open Source и коммерческими решениями.

Ролик доступ по ссылке.

Всем привет!

Сегодня в рубрике «Срочно в закладки» шикарное пополнение! Несмотря на то что предмет сегодняшнего поста не новый, он от этого не становится менее полезным! Кто то с ним прекрасно знаком, для кого-то, возможно, он станет открытием, но несомненно, для всех он будет прекрасным помощником в неблагодарном деле обеспечения безопасности!
Встречайте, матрица безопасности MITRE ATT&CK® (Adversarial Tactics, Techniques & Common Knowledge)

Кто такой? Чем знаменит?

Когда то давным давно, специалисты по безопасности одной крупной заграничной организации задумались, а можно ли описать типовые паттерны поведения нарушителя информационной безопасности? Можно ли собрать все возможные потенциальные действия злоумышленника и сгруппировать из по стадиям начиная с разведки и заканчивая успешной эксплуатацией каких-либо уязвимостей и получением контроля над критичными системами?
Благодаря огромному количеству проведённой ими аналитической работы выяснилось что в большинстве случаев, злоумышленники используют примерно одинаковую тактику и методы на каждом этапе атаки на любую систему!
Например:

🍩 Reconnaissance. Злоумышленник сканирует внешние адреса организации в поиске открытых портов
🍩 Resource Development. Далее он пытается разведать состав и конфигурацию инфраструктуры
🍩 Initial Access. Затем он пытается получить контроль через публичные endpoint’ы приложений
🍩 Execution. Получив контроль он старается выполнить свой вредоносный код

Таким образом злоумышленник постепенно получает полный контроль над критическими системами, не забывая при этом замести следы.
И вот спустя долгие годы дотачивания и актуализации у нас появилась матрица MITRE ATT&CK®, которая структурирует и подробно описывает каждый этап деятельности злоумышленника с подробным описанием техник, используемых на каждом шаге!
Благодаря этому сакральному знанию, проверенным годами в реальных условиях защиты business critical систем и приложений, мы теперь имеем наглядное руководство о том как могут быть взломаны практически любые системы! А имея подобную mind карту, нас теперь не нужно ставить себя на место атакующего и придумывать как взламывать собственную систему. Мы знаем пошагово что будет делать злоумышленник и можем точно знать что и где на нам защищать!

Данный дидактический материал очень рекомендуется к ознакомлению! По ссылке доступны матрицы для Windows, macOS, Linux, PRE, Azure AD, Office 365, Google Workspace, SaaS, IaaS платформ, сети и контейнеров!

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

https://attack.mitre.org

Всем привет!

В ноябре 2021 года вышла новая версия GitLab - 14.5, в которой много интересных нововведений не только для Dev, но и для Ops и Security-команд!

Сводную информацию можно почитать на официальном ресурсе, отдельно хотелось бы выделить следующее:
🍭 Добавлена возможность сканирования IaC при помощи KICS от Checkmarx (не путать с защитой АСУ ТП от Kaspersky ☺️)
🍭 Добавлены Secret Detection Patterns
🍭 GitLab Kubernetes Agent! Да, они были, но… теперь они доступны в Community-версии продукта!
🍭 Гранулированный контроль доступа Kubernetes-агентов с использованием Impersonate (не доступно в Community)
🍭 Добавление параметра exist в include – теперь можно еще более гибко настраивать вызовы pipeline’ов и job из внешних repo

И еще много-много-много всего, как для Community-версии, так и для ее «старших» братьев! Крайне рекомендуем к прочтению и ознакомлению! ☺️

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

Регулярные выражения (regular expressions, regexp) – популярный и важный инструмент, который может быть использован для поиска подстроки в строке или при parsing результатов для последующей обработки.

Некоторые ИБ-решения, в том числе основаны на их использовании, например, поиск секретов в Trufflehog использует этот функционал.

Есть один нюанс – поначалу они могут показаться чем-то очень сложным и неудобным, но стоит лишь привыкнуть… Для более быстрого погружения есть интересный интерактивный курс от RegexLearn! Курс комбинирует в себе теорию и практику, продолжает развиваться. Например, модули Practice и Playground обещают скоро добавить.

Если вы никогда не сталкивались с regexp, но вам интересно – неплохое место для старта, а если вы профессионал написания «регулярок», то попробуйте разгадать кроссворд! Неплохое развлечение для вечера пятницы! 😊

P.S. Всем отличной пятницы и выходных! И да, до Нового Года осталось совсем чуть-чуть, 3 недели!

Привет

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

В статье приводится наглядная схема, описывающая то, что происходит при запуске команды "kubectl create pod nginx":
🍭 Аутентификация запроса
🍭 Kube-apiserver создает объект Pod, обновляет данные в ETCD
🍭 Kube-scheduler получает информацию о том, что Pod был создан, без Node
🍭 Kube-scheduler "подбирает" оптимальную Node, сообщает Kube-apiserver, информация в ETCD обновляется
🍭 Новая информация передается Kube-apiserver'ом Kubelet'у той Node, что была выбрана Kube-scheduler
🍭 Kubelet создает Pod на Node, взаимодействуя с Container Runtime Engine
🍭 После завершения работы Kubelet оповещает Kube-apiserver, обновляется информация в ETCD

Важно (!) схема очень-очень-очень упрощенная, просто для общего понимания.

Если хочется больше и детальнее - рекомендуем посмотреть невероятную статью "What happens when I type kubectl run", в которой подробно описывается, что происходит "под капотом", пусть даже и на базовых операциях ☺️

Привет!

Чем заняться на новогодних праздниках? Конечно же – учиться! Тем более, что интересных курсов очень много. Одним из таких порадовали ребята из Sysdig!

Они выпустили курс «Falco 101», который очень лаконично описали: «All you need to learn to get started with Falco».

Суммарно курс состоит из ~ 5,5 часов видеоматериалов и включает в себя такие разделы, как:
🍭 What is runtime security
🍭 Falco installation and basic settings
🍭 Falco event sources
🍭 Falco rules: basics and deep dives

И другие! Кстати, недавно мы писали про лабораторные работы от Sysdig, посвященные Falco. Их можно использовать вместе с курсом для совмещения теории и практики 😊

​​Сотни продуктов пострадали от уязвимости в Log4J и это, в основном, известные и часто используемые.

А сколько внутренних проектов уязвимо? Еще предстоит узнать.

Как оперативно находить подобные уязвимости в своих проектах, исправлять опасные настройки Kubernetes с помощью KSPM (близкий родственник CSPM) и контролировать контейнеры на уровне Runtime ?

Расскажет Aqua Security в серии коротких вебинаров:

Aqua: Начинаем погружение!
Серия 30 минутных вебинаров по безопасности Cloud Native:
1. Сканирование образов контейнеров
2. Безопасность Kubernetes (KSPM)
3. Новый термин - CNAPP
4. Compliance for Cloud Native
5. Runtime Security и многое другое.

Ближайший вебинар уже завтра, регистрация -
https://info.aquasec.com/jump-start-russia

Всем привет!

Продолжаем тему с интересными обучениями, которые доступны бесплатно и могут дать представление о чем-то новом!

Сегодня – GitOps! Точнее – курс от CodeFresh, посвященный этому подходу и его реализации при помощи ArgoCD.

Курс состоит из 5 основных блоков:
🍭 About GitOps. Декларативное описание инфраструктуры, использование Git в качестве «источника истины», обзор плюсов и минусов подхода
🍭 ArgoCD basics. Обзор возможностей ArgoCD для управления нагрузками на кластере
🍭 Using ArgoCD. Реализация операций «второго дня» с использованием Argo
🍭 Progressive Delivery. Использование Argo Rollouts для Blue/Green и Canary Deployment
🍭 Summary and examination. Обзор пройденного материала, небольшой тест для закрепления

Если курс понравится, можно ознакомиться еще с двумя – GitOps at Edge и GitOps at Scale (по мере их появления) ☺️

Всем привет!

Еще один интересный обучающий проект, достойный внимания – Styra Academy! Отличный курс, который рассказывает про OPA, как и зачем использовать этот инструмент.

Курс состоит из нескольких частей:
🍭 Overview of OPA. Какие задачи решает, какими возможностями обладает
🍭 Rego Expressions. Основа языка Rego, используемого для написания OPA-политик
🍭 Basic Rego Rules. Описание концепции вычисления правил, создание «цепочки» правил
🍭 Partial Rego Rules. Использование Partial Object и Functional Rules
🍭 Rego Iteration. Взаимодействие с Arrays, Objects и Sets
🍭 Rego Packages. «Упаковка» политик в предопределенные packages

Курс содержит теорию, практические задания и предоставляется бесплатно! ☺️