+ 1 подкаст 🎧

На этот раз про Site Reliability Engineering. Есть текстовая расшифровка.

Владислав Юкис (Vladyslav Ukis), руководитель отдела R&D компании Siemens Healthineers / эксперт в области SRE, и ведущие подкаста говорят об отношениях между SRE и DevOps, балансе принципов SRE с организационной структурой и о том, как GenAI повлияет на SRE.

А еще Владислав Юкис писал про SRE для блога Stack Overflow. Можете глянуть эту заметку — «Who builds it and who runs it? SRE team topologies».

Другие подкасты можно найти по тегу #подкаст

Всем DevOps! 🖖

Рекомендуем отличную схему дебага в Kubernetes. Разумеется, не покрывает все случаи, но с частью — точно поможет.

А можно просто распечатать и на стену повесить, украсить рабочее место ткскзт :)

На превью ~ 1/10 всей схемы, полностью и в хорошем качестве можно посмотреть здесь.

#интересное

Неплохая (и бесплатная!) возможность познакомиться с Yandex Cloud — проводят вебинар «Как начать работу в Yandex Cloud: пошаговая инструкция для новичков».

Расскажут про то, как устроена платформа Yandex Cloud, какие сервисы есть на платформе, что нужно для начала работы и как выполнить базовые задачи на старте: создать облако, запустить ВМ, настроить сеть и пр.

Когда? 07.09 в 16:00 МСК

Нужно зарегистрироваться.

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

15.08.2023 Kubernetes представили репозитории, принадлежащие сообществу Kubernetes, для пакетов Debian и RPM: pkgs.k8s.iо. Новые репозитории пакетов заменяют репозитории пакетов, размещенные в Google (apt.kubernetes.iо и yum.kubernetes.iо).

С 31.08.23 Kubernetes официально прекращает поддержку устаревших репозиториев пакетов (apt.kubernetes.iо и yum.kubernetes.iо) и планирует заморозить содержимое репозиториев с 13 сентября 2023 года.

Это изменение затронет:

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

• пользователей Linux, которые выполняли установку kubectl с использованием устаревших репозиториев пакетов (как проверить).

#новости

Всем DevOps! 🖖

Собрали 10 сканеров для поиска уязвимостей безопасности и неправильных конфигураций в Kubernetes, делимся!

Часть 1

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

Kube-bench — это сканер, который проверяет, развернут ли Kubernetes в соответствии с best practices безопасности, определенными в CIS Kubernetes Benchmark. Kube-bench был удостоен награды InfoWorld Basic Award 2018.

Тесты настраиваются с помощью файлов YAML, что позволяет легко обновлять этот инструмент по мере развития спецификаций тестов.

Quick start

• Внутри контейнера:

docker run - pid=host -v /etc:/etc:ro -v /var:/var:ro -t aquasec/kube-bench:latest - version 1.18

• Внутри Kubernetes-кластера:

kubectl apply -f https://github.com/aquasecurity/kube-bench/blob/main/job.yaml

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

Kube-hunter ищет слабые места безопасности в кластерах Kubernetes. Этот инструмент был разработан для повышения осведомленности и наглядности проблем безопасности в средах Kubernetes. НЕ следует запускать kube-hunter в кластере Kubernetes, которым вы не владеете! Находясь за пределами кластера, kube-hunter сканирует домен или диапазон адресов на наличие открытых портов, связанных с Kubernetes, и проверяет наличие проблем конфигурации, которые делают ваш кластер уязвимым для злоумышленников.

Quick start

• На любой машине выберите удаленное сканирование и укажите IP-адрес или доменное имя вашего
кластера Kubernetes. Это даст вам обзор вашей настройки Kubernetes с точки зрения злоумышленника:

pip install kube-hunter

• На машине в кластере:

docker run -it — rm — network host aquasec/kube-hunter

• В поде внутри кластера:

kubectl create -f https://github.com/aquasecurity/kube-hunter/blob/main/job.yaml

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

Kubeaudit — это инструмент командной строки и пакет Go для аудита кластеров Kubernetes на предмет различных проблем безопасности.

Kubeaudit поставляется с большим списком «аудиторов», которые проверяют различные аспекты, такие как SecurityContext подов. Полный список аудиторов есть в репозитории.

Quick start

• Через Homebrew:

brew install kubeaudit

• Через Helm:

helm upgrade — install kubeaudit secureCodeBox/kubeaudit

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

С помощью Kube-scan можно получить оценку риска ваших рабочих нагрузок. Kube-scan дает оценку риска от 0 (нет риска) до 10 (высокий риск) для каждой рабочей нагрузки. Kube-scan предназначен для того, чтобы помочь понять, какие из рабочих нагрузок подвергаются наибольшему риску и почему, а также позволяет определить приоритетность обновлений политики безопасности вашего модуля, определений модулей и файлов манифеста, чтобы держать риск под контролем.

Quick start

kubectl apply -f https://raw.githubusercontent.com/octarinesec/kube-scan/master/kube-scan.yaml
kubectl port-forward --namespace kube-scan svc/kube-scan-ui 8080:80

Затем установите для браузера значение http://localhost:8080

▪️ Kubesec
Репозиторий: https://github.com/controlplaneio/kubesec

Kubesec — это open-source инструмент для оценки риска безопасности рабочих нагрузок Kubernetes на основе их конфигурации YAML.

Kubesec количественно оценивает риск для ресурсов Kubernetes, проверяя файлы конфигурации и файлы манифеста, используемые для развертываний и операций Kubernetes.

Quick start

• Docker Container:

docker.io/kubesec/kubesec:v2 https://hub.docker.com/r/kubesec/kubesec/tags

• Linux/MacOS/Win binary: https://github.com/controlplaneio/kubesec/releases

• Kubernetes Admission Controller: https://github.com/controlplaneio/kubesec-webhook

• Kubectl Plugin: https://github.com/controlplaneio/kubectl-kubesec

Пример использования командной строки:
kubesec scan k8s-deployment.yaml

#open_source

Часть 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.

#лонгрид