DevOps FM

«Kube FM» — подкаст, позволяющий расширить знания о Kubernetes, следить за новейшими инструментами и тенденциями. Подкаст ведет амбассадор CNCF Барт Фаррелл. Есть текстовая расшифровка и много полезных ссылок к выпуску. В первом (и пока единственном 😢) выпуске рассматриваются новые функции Kubernetes 1.28 и рассказывается о том, что требуется для выпуска новой версии Kubernetes. В гостях Грейс Нгуен (Grace Nguyen) — Kubernetes 1.28 release lead. #подкаст

☄️ «Возможно, отключение всего — более эффективное средство устранения неполадок. И именно устранение неполадок должно быть вашей главной заботой. Так вы выигрываете время для понимания проблемы. Это возможно не во всех случаях, но даже если вы сместите фокус с проблемы, вы сможете выиграть немного времени» Это слова SRE-инженера Рикардо Кастро. Категорично настолько, будто это сказал его однофамилец Фидель 😜 Но смысл в этом есть. 👉 Читайте об опыте SRE-инженера в нашей новой статье. #devops #sre @DevOpsKaz

Всем DevOps! 🖖 Очень вероятно, что вам знаком этот инструмент (все-таки 38k звездочек на GitHub), но кажется не лишним рассказать еще раз :) dive — open-source инструмент для изучения образа Docker, содержимого слоев и поиска способов уменьшить размер образа Docker/OCI. Чтобы проанализировать образ Docker, просто запустите dive с тегом / id / digest образа: dive <your-image-tag> Или вы можете использовать dive напрямую с помощью команды docker: alias dive="docker run -ti --rm -v /var/run/docker.sock:/var/run/docker.sock wagoodman/dive" dive <your-image-tag> # for example dive nginx:latest Или вы можете создать свой образ и сразу приступить к его анализу: dive build -t <some-tag> 💻 Ссылка на GitHub

Наглядное объяснение работы «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.

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)

В эфире — новости! ⚡️ ▪️Релиз Docker Desktop 4.23. Добавление поддержки АSР.NЕТ, обновленный Configuration Integrity Check, улучшение быстрого поиска и многое другое. Все подробности — в Release Notes. ▪️Kubernetes выпустили довольно полезную заметку — «Сравнение локальных инструментов разработки Kubernetes: elepresence, Gefyra и mirrord». ▪️Релиз PostgreSQL 16. Больше методов вертикального и горизонтального масштабирования рабочих нагрузок, а также новые способы получения аналитической информации и оптимизации управления своими данными. Подробности о релизе — здесь. ▪️Grafana Loki набрала 20 тысяч звезд на GitHub. Уже даже 20.1k. В честь такого юбилея — 20 забавных фактов об этом проекте. ▪️Релиз ClickHouse 23.8. 29 новых функций. 19 оптимизаций производительности. 63 исправления ошибок. Подробности в анонсе или в этом видео.

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

Отличные новости для всех, кто готовится к экзаменам CKA, CKAD и CKS или просто хочет освоить Kubernetes — бесплатная open-source платформа, которая поможет на этом пути. Вот что есть на платформе: ➖ Создание всех необходимых ресурсов (VPC, subnets, EC2) автоматически. ➖ Настройка кластеров под различные сценарии в несколько кликов. ➖ Эквивалент http://killer.sh, но абсолютно бесплатно. ➖ Возможность легко добавлять свои собственные сценарии. ➖ Тесты для проверки правильности выполнения заданий. ➖ Контроль времени для максимально реалистичных мок-экзаменов. На данный момент доступны сценарии: • CKA mock экзамена • CKS hands-on lab • CKS mock экзамена #devops #sre #cka #cks #ckad #kubernetes #killersh @DevOpsKaz

Делимся ещё одним подкастом про облачные технологии Вообще этот подкаст про информационную безопасность, но тема нового выпуска — вопросы безопасности ИТ- и ИБ-аутсорсинга в разрезе облаков: SaaS, PaaS и IaaS. Что узнаете: • как выбрать провайдера, и на какие ключевые моменты стоит обратить внимание; • как распределить риски между организацией и провайдером; • почему важно подготовить «план Б», который предусматривает отказ от услуг облачного провайдера; • какие требования предъявляет регуляторика к аутсорсингу. Подкаст доступен как в видео, так и в аудиоформате :) #подкаст

Сегодня даже подборка статей будет тематическая 🖥 ▪️Статья «Что для меня значит быть программистом» — "вот вам исповедь погромиста. Уж не знаю, типичный я программист или какой-то чудак. Пишу так, как вижу, а обобщать на всех прогеров или нет - решать вам." ▪️Статья «Четыре типажа программистов» — "мой основной тезис: все разработчики, грубо говоря, делятся на 4 больших типажа и каждому из этих типажей есть своя область применения. Попытка направить неправильный типаж на решение неподходящих для него задач ведет к провалу (неэффективная работа, или сотрудник покидает команду). Хотите знать почему так — добро пожаловать под кат. Приготовьтесь, текста много." ▪️Статья «Мой путь из инженера в программисты» — "автор поныл, как тяжело живется инженерам на Руси и решил уходить в программисты. У него получилось. Пост о том, как именно." ▪️Статья «20 вещей, которые я узнал за 20 лет работы инженером-программистом» — "наткнулся на любопытный материал, в котором автор систематизировал и записал свой опыт инженера-программиста в 20 тезисов. Я работаю в коммерческой разработке ПО больше 25 лет, и этот текст отозвался во мне практически каждой буквой — большинство советов я тоже регулярно практикую, не облекая их в формат ёмких афоризмов. В общем, решил сделать перевод." ▪️Статья «Самые позорные ошибки в моей карьере программиста (на текущий момент)» — "как говорится, если тебе не стыдно за свой старый код, значит, ты не растешь как программист — и я согласна с таким мнением. Я начала программировать для развлечения более 40 лет назад, а 30 лет назад и профессионально, так что ошибок у меня набралось очень много. Будучи профессором информатики, я учу своих студентов извлекать уроки из ошибок — своих, моих, чужих. Думаю, пришло время рассказать о моих ошибках, чтобы не растерять скромность. Надеюсь, кому-то они окажутся полезны."

Сегодня, 13 сентября 2023 года, праздник — День программиста! Поздравляем всех причастных! 🥳 Fun Fact № 1: точной даты у Дня программиста нет. Но это всегда 256-ой день от начала года. Как правило, выпадает 13 сентября. Но в високосные годы дата меняется на 12-е число. Fun Fact № 2: если вы думаете, что это «праздник» и знают про него только внутри профессионального сообщества, то нет :) В России это официальная дата — есть целый президентский указ № 1034 от 11.09.2009 г. «О Дне программиста» В общем, всё серьезно 😎

Приручаем GitLab 💻 «Каждый раз, подключаясь на проект, где используется GitLab, видишь одни и те же ошибки или проблемы. На Habr можно найти множество информации, связанной с кейсами, туториалами или просто интересными историями про GitLab. Но сколько бы ни было написано, найти место где было бы собрано всё и сразу — не получилось». Алексей, DevOps-инженер компании Nixys, решил это исправить и написал статью, в которой рассказал про прикольные фишки Gitlab и инциденты, которые упростят вашу жизнь. ➡️ Приятного чтения!

Секретный пост! Точнее, пост про секреты. И здесь хочется просто порекомендовать две отличные статьи: ▪️Статья «How Secrets Leak in CI/CD Pipelines» — как происходит утечка секретов в пайплайнах. ▪️Статья «How Secrets Leak out of Docker Images» — как происходит утечка секретов из Docker-образов.

Целый сайт, посвященный безопасности контейнеров! Кто автор? Да-да, Рори МакКьюн, мы уже писали про его блог и рассказывали про его серию статей «Container security fundamentals». На этом сайте собрано много полезных материалов — Container CVE List, списки инструментов для обеспечения безопасности контейнеров, стандарты безопасности, чеклисты... В общем, очень полезная ссылка, которую стоит сохранить, чтобы больше никогда не открывать, и поделиться с коллегами 🤝

Всем DevOps! 🖖 По традиции начнем эту неделю с новостей. ▪️Мы как-то писали, что у Yandex Cloud есть бесплатные курсы. Сейчас появилось еще несколько новых, например, курс по работе с базой данных ClickHouse. Вообще у этих курсов три больших раздела: «DevOps-инженерам», «Data-инженерам и аналитикам», «Security и DevSecOps-инженерам» — посмотрите, вдруг мы что-то не назвали, а вам будет интересно. ▪️Релиз Grafana Loki 2.9. Информацию об изменениях в релизе можно найти в Release Notes. И не забудьте ознакомиться с руководством по обновлению. ▪️Исследований про DevOps и облачные технологии в России становится всё больше, что не может не радовать. Появилось исследование о применении облачных технологий в промышленности. В нём участвовали представители 15 крупнейших промышленных холдингов России. 🔗 Если интересуетесь этой темой, рекомендуем статью «Как DevOps помог исправить 30 точек операционной неэффективности в промышленности». ▪️Релиз Argo 1.6. В этом выпуске было много небольших улучшений и изменений. Подробную информацию вы можете найти здесь и в Changelog. Если мы пропустили что-то важное, обязательно дополняйте в комментариях :) Желаем отличной недели! 🔥

Среда, конечно, маленькая пятница и хочется чего-нибудь ненапряжного, но такая классная серия статей не может ждать до четверга. «Сети для самых маленьких» (ну почти, предполагается, что вы, как минимум, читали о эталонной модели OSI, о стеке протоколов TCP/IP, знаете о типах существующих VLAN’ов, о наиболее популярном сейчас port-based VLAN и о IP адресах) Ну вы просто посмотрите на содержание! 🥰 0. Планирование 1. Подключение к оборудованию cisco 2. Коммутация 3. Статическая маршрутизация 4. L2 и STP 5. NAT и ACL 6. Динамическая маршрутизация 7. VPN 8. BGP и IP SLA 8.1. Микровыпуск №3. IBGP 9. Мультикаст 10. Базовый MPLS 11. MPLS L3VPN 11.1. Микровыпуск №6. MPLS L3VPN и доступ в Интернет 12. MPLS L2VPN 12.1. Микровыпуск №7. MPLS EVPN 12.2. Микровыпуск №8. EVPN Multihoming 13. MPLS Traffic Engineering 14. Путь пакета 15. QoS ECMP и балансировка в датацентрах Как построить Гугл. Или сети современных датацентров Где сохранить пакет? Чипы и буферы Ко многим частям даже есть видео. В общем, замечательный фундаментальный цикл (первая статья — 2012 год, последняя — 2020), рекомендуем. ➡️ Приятного чтения!

Всем DevOps! 🖖 Наверняка вы слышали про историю с OpenTF. Вкратце: четыре недели назад HashiCorp перевела Terraform (и другие свои продукты) с лицензии открытого исходного кода на лицензию Business Source (BUSL). Три недели назад объединение разных компаний выпустило манифест OpenTF, в котором просило HashiCorp вернуться к лицензии с открытым исходным кодом. Две недели назад, не получив ответа от HashiCorp, был создан приватный форк Terraform и заявлено, что он будет сделан публичным через 1-2 недели. Собственно, это и случилось 🥳 Форк OpenTF уже доступен — ссылка на репозиторий. Релизов пока нет, почему — можно узнать здесь.

Часть 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/), чтобы обновить результаты.

Всем 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

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 с использованием устаревших репозиториев пакетов (как проверить).