Часть 2

▪️ Kube-score
Репозиторий: https://github.com/zegl/kube-score

Kube-score выполняет статический анализ кода для всех определений объектов Kubernetes. Результатом является список рекомендаций о том, что можно улучшить, чтобы сделать приложение более безопасным и отказоустойчивым.

Онлайн-демо

Quick start

• Docker:

docker pull zegl/kube-score

• Homebrew:

brew install kube-score

• Krew:

kubectl krew install score

Полный список проверок см. в README_CHECKS.md

▪️ KubiScan
Репозиторий: https://github.com/cyberark/KubiScan

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

Quick start

Установка:

- alias kubiscan='python3 https://github.com/cyberark/KubiScan/blob/master/KubiScan.py 

Примеры

• Поиск подов с привилегированной учетной записью:

kubiscan -rp

• Проверка наличия этой учетной записи в списке рискованных:

kubiscan -rs

• Поиск всех правил, которые есть в этой учетной записи службы:

kubiscan -aaes “risky-sa” -ns “default” -k “ServiceAccount”

▪️ Krane
Репозиторий: https://github.com/Shopify/krane

Krane — это инструмент командной строки, написанный на Ruby. Krane — простой инструмент для статического анализа Kubernetes RBAC. Он выявляет потенциальные риски безопасности в конструкции RBAC K8 и дает предложения по их снижению. Панель управления Krane отображает текущее состояние безопасности RBAC и позволяет перемещаться по определению.

Quick start

Установка:

gem install krane

Затем:
krane deploy <app’s namespace> <kube context>

▪️ Illuminatio
Репозиторий: https://github.com/inovex/illuminatio

Illuminatio — утилита для автоматического тестирования сетевых политик Kubernetes. Просто запустите illuminatio clean run, и illuminatio просканирует ваш кластер Kubernetes на наличие сетевых политик, создаст соответствующие тестовые примеры и выполнит их, чтобы определить, действуют ли политики.

Quick start

Установка:

pip3 install illuminatio

Или через плагин Kubectl:

-> ln -s $(which illuminatio) /usr/local/bin/kubectl-illuminatio
-> kubectl plugin list — name-only | grep illuminatio

Можно проверять:
illuminatio clean run

▪️ Kubei
Репозиторий: https://github.com/Erezf-p/kubei

В кластере Kubernetes Kubei используется для анализа непосредственных угроз. Большая часть Kubei написана на языке программирования Go.

Kubei — это инструмент сканирования уязвимостей и сравнительного анализа CIS Docker, который позволяет пользователям получить точную и немедленную оценку рисков своих кластеров Kubernetes.

Quick start

Для развертывания Kubei в кластере:

kubectl apply -f https://raw.githubusercontent.com/Portshift/kubei/master/deploy/kubei.yaml

Затем перенаправьте порты в веб-приложение Kubei:

kubectl -n kubei port-forward $(kubectl -n kubei get pods -lapp=kubei -o jsonpath=’{.items[0].metadata.name}’) 8080

В браузере перейдите по адресу http://localhost:8080/view/ и нажмите «GO», чтобы запустить сканирование.

Чтобы проверить состояние Kubei и ход текущего сканирования, выполните следующую команду:

kubectl -n kubei logs $(kubectl -n kubei get pods -lapp=kubei -o jsonpath=’{.items[0].metadata.name}’)

Обновите страницу (http://localhost:8080/view/), чтобы обновить результаты.

#open_source

Целый сайт, посвященный безопасности контейнеров!

Кто автор? Да-да, Рори МакКьюн, мы уже писали про его блог и рассказывали про его серию статей «Container security fundamentals».

На этом сайте собрано много полезных материалов — Container CVE List, списки инструментов для обеспечения безопасности контейнеров, стандарты безопасности, чеклисты...

В общем, очень полезная ссылка, которую стоит сохранить, чтобы больше никогда не открывать, и поделиться с коллегами 🤝

#блог

Секретный пост! Точнее, пост про секреты.

И здесь хочется просто порекомендовать две отличные статьи:

▪️Статья «How Secrets Leak in CI/CD Pipelines» — как происходит утечка секретов в пайплайнах.

▪️Статья «How Secrets Leak out of Docker Images» — как происходит утечка секретов из Docker-образов.

#статьи

Сегодня даже подборка статей будет тематическая 🖥

▪️Статья «Что для меня значит быть программистом» — "вот вам исповедь погромиста. Уж не знаю, типичный я программист или какой-то чудак. Пишу так, как вижу, а обобщать на всех прогеров или нет - решать вам."

▪️Статья «Четыре типажа программистов» — "мой основной тезис: все разработчики, грубо говоря, делятся на 4 больших типажа и каждому из этих типажей есть своя область применения. Попытка направить неправильный типаж на решение неподходящих для него задач ведет к провалу (неэффективная работа, или сотрудник покидает команду). Хотите знать почему так — добро пожаловать под кат. Приготовьтесь, текста много."

▪️Статья «Мой путь из инженера в программисты» — "автор поныл, как тяжело живется инженерам на Руси и решил уходить в программисты. У него получилось. Пост о том, как именно."

▪️Статья «20 вещей, которые я узнал за 20 лет работы инженером-программистом» — "наткнулся на любопытный материал, в котором автор систематизировал и записал свой опыт инженера-программиста в 20 тезисов. Я работаю в коммерческой разработке ПО больше 25 лет, и этот текст отозвался во мне практически каждой буквой — большинство советов я тоже регулярно практикую, не облекая их в формат ёмких афоризмов. В общем, решил сделать перевод."

▪️Статья «Самые позорные ошибки в моей карьере программиста (на текущий момент)» — "как говорится, если тебе не стыдно за свой старый код, значит, ты не растешь как программист — и я согласна с таким мнением. Я начала программировать для развлечения более 40 лет назад, а 30 лет назад и профессионально, так что ошибок у меня набралось очень много. Будучи профессором информатики, я учу своих студентов извлекать уроки из ошибок — своих, моих, чужих. Думаю, пришло время рассказать о моих ошибках, чтобы не растерять скромность. Надеюсь, кому-то они окажутся полезны."

#статьи

Делимся ещё одним подкастом про облачные технологии

Вообще этот подкаст про информационную безопасность, но тема нового выпуска — вопросы безопасности ИТ- и ИБ-аутсорсинга в разрезе облаков: SaaS, PaaS и IaaS.

Что узнаете:

• как выбрать провайдера, и на какие ключевые моменты стоит обратить внимание;
• как распределить риски между организацией и провайдером;
• почему важно подготовить «план Б», который предусматривает отказ от услуг облачного провайдера;
• какие требования предъявляет регуляторика к аутсорсингу.

Подкаст доступен как в видео, так и в аудиоформате :)

#подкаст

Worst practices DevOps ♾

Желаем классной пятницы и отличных выходных! 🔥

#memes

GitLab Critical Security Release: 16.3.4 (Community Edition) и 16.2.7 (Enterprise Edition)

Злоумышленник мог запустить пайплайн от имени произвольного пользователя с помощью scheduled security scan policies. Уровень опасности — critical (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N, 9.6).

Сообщение от GitLab c инструкцией (в том числе есть информация, что делать с версиями до 16.2)

#новости

Наглядное объяснение работы «native sidecar-контейнеров». Лучше, конечно, прочитать и оригинал текста :)

Kubernetes Native Sidecars

Fun Fact: объекта поля Sidecar нет даже в Kubernetes 1.28. Встроенные sidecar-контейнеры — это просто старые добрые init-контейнеры, но с некоторыми новыми свойствами:

▪️ Чтобы сделать init-контейнер sidecar-контейнером, необходимо добавить атрибут «restartPolicy: Always» в его спецификацию.

▪️ Поскольку сайдкары являются init-контейнерами, они соблюдают порядок запуска в списке Pod.initContainers.

▪️ Однако они не блокируют следующий запуск контейнера (init или обычного).

▪️ В отличие от init-контейнеров, в случае сбоя сайдкары будут перезапущены.

▪️ В отличие от не встроенных сайдкаров (исторически имитируемых обычными контейнерами), встроенные sidecar-контейнеры не блокируют завершение пода.

▪️startup|readiness|liveness пробы теперь можно настроить для init-контейнеров, но только для тех, у которых для параметра restartPolicy установлено значение «Always».

Другими словами, единственная «true init» особенность новых встроенных Sidecars, заключается в том, что они следуют порядку запуска инициализации. В остальном их поведение сильно отличается от init-контейнеров.

Эта конструкция открывает путь к более продвинутому типу init-контейнера. В Sidecar PEP даже упоминается новый тип, называемый «infra containers», который может быть использован для унификации поведения старых init и новых контейнеров Sidecar.

Вот как новое поведение можно визуализировать с помощью одного пода:

• Два обычных контейнера работают до завершения
• Два init-контейнера ic1 и ic2 работают до завершения.
• ... и смешанный с двумя сайдкарами sc1 (периодически выходит из строя и перезапускается) и sc2 (работает до завершения)

Обратите внимание, как:

• Первый сайдкар постоянно перезапускается.
• Оба сайдкара принудительно уничтожаются после завершения работы обоих обычных контейнеров.
• Окончательный статус пода — «Succeeded», несмотря на то, что оба сайдкара сообщают о non-zero exit codes.

#лонгрид

«Kube FM» — подкаст, позволяющий расширить знания о Kubernetes, следить за новейшими инструментами и тенденциями.

Подкаст ведет амбассадор CNCF Барт Фаррелл. Есть текстовая расшифровка и много полезных ссылок к выпуску.

В первом (и пока единственном 😢) выпуске рассматриваются новые функции Kubernetes 1.28 и рассказывается о том, что требуется для выпуска новой версии Kubernetes. В гостях Грейс Нгуен (Grace Nguyen) — Kubernetes 1.28 release lead.

#подкаст