Есть такая игра TrackMania, я вам уже про неё когда-то давно писал. Это очень аркадная гонка. Настолько аркадная, что автомобили на трассе никак друг с другом не взаимодействуют (вы не можете столкнуться с соперником, просто проедете сквозь него), и задача игрока состоит в том, чтобы сражаться со сложностью трассы. А трассы обычно включают в себя прыжки, мёртвые петли, движение по стенам и так далее.
Разумеется, нужно пройти трассу быстрее, чем остальные. "Пройти трассу" с точки зрения движка игры означает следующее: корпус автомобиля в любом порядке пересекает чекпоинты, а затем попадает в область финиша. Ещё физический движок у игры идемпотентный: одинаковый набор управляющих воздействий всегда в точности приводит к тому же положению автомобиля и тем же векторам линейной и угловой скорости.
Это создаёт ситуацию, при которой повтор прохождения игроком какой-либо трассы можно записать просто как цепочку нажатий на клавиши управления в заданные моменты времени. Так что игроки могут этими повторами обмениваться и соревноваться асинхронно: один проходит трассу за 2 минуты и 19 секунд, загружает свой результат в сеть, а другой через неделю соревнуется и с ним и побеждает, проходя трассу за 2 минуты 18 секунд.
Вокруг этой игры создалось очень большое и активное сообщество людей, которые друг с другом соревнуются и ставят рекорды. Эти игроки проводят в TrackMania десятки часов в неделю, и зачастую сами себе создают челленджи. Например, пройти все трассы в игре, никогда не поворачивая вправо. Или пройти задним ходом. Или даже с закрытыми глазами, ориентируясь по звукам и таймеру. Ещё в игре есть редактор трасс, и поэтому сообщество создаёт очень сложные многоуровневые треки для всех желающих.
Так вот, интересный момент. Как я уже говорил, движок засчитывает прохождение по довольно формальным признакам. Поэтому технически совсем не обязательно проехать на машине по дороге. Если вы каким-то образом заставите машину взлететь и проскакать с более быстрой скоростью — это валидный рекорд. И сообщество тоже такое принимает и даже всячески восхищается игроками, которые смогли обмануть игровой движок и найти, что называется, shortcut. Профессиональные игроки владеют набором специальных багов. Например, если определённым образом поставить машину боком под правильным углом с правильной скоростью, трение торможения уменьшится, и можно будет пройти какой-то кривой участок быстрее. Ещё можно под нужным углом удариться о поверхность и отскочить от неё куда требуется. И таких обманов движка пара десятков. Нередко игрокам приходится их комбинировать, поэтому они сидят десятки и сотни часов, проходя одну и ту же трассу, чтобы получить идеальное стечение обстоятельств ради улучшения времени на одну сотую секунды. Не преувеличиваю.
При этом, однако же, читерство и "внешние" обманы в игре очень сильно критикуются. Если тебя заподозрят в использовании программы, которая за тебя нажимает клавиши, или в какой-нибудь подделке памяти — это смерть для твоей репутации в сообществе.
Вот какое дело получается: разработчики заложили формальные правила игры (ехать на машине по дороге), и нарушение этих правил поощряется. Но нарушение правил игрового движка уже жёстко критикуется. Чисто практически разница между этими правилами очень условная: и то, и другое это отступление от игры в том виде, в котором игра задумана. Но людям нужно было где-то поставить границу, после которой издевательство над игрой уже не обладает зрелищностью и спортивной составляющей, так и получилось.
На видео ниже норвежский про-игрок с ником Wirtual рассказывает об одном из таких случаев, по-моему, очень интересно и напряжённо вышло :)
#games
https://www.youtube.com/watch?v=_b67SC7Y4qA
• Если помните, то несколько месяцев назад я делился с вами очень крутым материалом, где подробно описан опыт автора по ручному развертыванию Kubernetes без использования автоматизированных инструментов. Так вот, есть еще одна статья, не менее интересная и полезная. На этот раз автор описывает настройки аудита в Kubernetes, его возможности и примеры конфигураций, которые помогут вам сформировать эффективную политику аудита для вашего кластера.
➡Что такое аудит;
➡Политика аудита;
➡Параметры фильтрации;
➡Уровни логирования;
➡Стадии omitStages;
➡Подавление системного шума;
➡Фильтрация по пользователям;
➡Защита чувствительных данных;
➡Детализация для важных API;
➡Настройка API-сервера;
➡Заключение.
#Kubernetes
• Популярность Kubernetes растет, порог входа снижается, но вопросам безопасности порой оказывают недостаточное внимание.
•KubeHound - это как Bloodhound, но только для Kubernetes. Тулза предназначена для построения графов и вычисления путей атак для компрометации кластера. Принцип работы следующий:
➡KubeHound анализирует Kubernetes-кластер;
➡Собирает данные о ролях, привязках, сервисных аккаунтах, настройках Pod и сетевых политиках;
➡Формирует граф атак, определяя цепочки эксплуатации, показывая найденные уязвимости и их комбинации.
➡Выводит отчет, выделяя риски и рекомендациями по исправлению.
• Куча дополнительной информации по использованию KubeHound можно найти по ссылкам ниже:
➡️https://github.com/DataDog/KubeHound
➡️https://kubehound.io
• Дополнительно: подборка бесплатных инструментов с открытым исходным кодом для обеспечения безопасности Kubernetes.
#Kubernetes
👩💻 Kubernetes The Hard Way.
• Автор этого гайда работал над ним около двух лет, осуществил тысячи перезапусков и пересобрал сотни кластеров — всё это вылилось в одну, но очень насыщенную статью. Kubernetes вручную, от и до, без kubeadm и прочих поблажек.
- Удобные alias’ы, функции и обёртки;
- Десятки скриптов, которые реально работают в бою;
- Важные моменты, о которых молчат в туториалах.
➡Введение;
➡Почему «The Hard Way»;
➡Архитектура развертывания;
➡Создание инфраструктуры;
➡Базовая настройка узлов;
➡Загрузка модулей ядра;
➡Настройка параметров sysctl;
➡Установка компонентов;
➡Настройка компонентов;
➡Проверка готовности компонентов;
➡Работа с сертификатами;
➡Создание корневых сертификатов;
➡Создание сертификатов приложений;
➡Создание ключа подписи ServiceAccount;
➡Создание всех сертификатов;
➡Создание конфигураций kubeconfig;
➡Создание всех kubeconfig;
➡Проверка блока сертификатов;
➡Создание static pod-ов управляющего контура;
➡Создание всех static pod-ов управляющего контура;
➡Создание static pod-ов ETCD кластера;
➡Запуск службы Kubelet;
➡Проверка состояния кластера;
➡Настройка ролевой модели;
➡Загрузка конфигурации в кластер;
➡Загрузка корневых сертификатов в кластер;
➡Маркировка и ограничение узлов.
#Kubernetes
• Недавно на хабре был обновлен очень объемный гайд по установке Kubernetes, который включает в себя очень много полезной информации для новичков. Стоит отметить, что Kubernetes — это большая и довольно сложная тема, но если вы изучите это пошаговое руководство, то у вас появился работающий стенд для экспериментов, что послужит отличным началом для изучения k8s: https://habr.com/ru/articles/725640
• Обратите внимание, что руководство содержит много дополнительного материала:
➡Основы Kubernetes;
➡Руководство начинающим для понимания основных концепций Kubernetes;
➡Различия между Docker, containerd, CRI-O и runc;
➡Визуальное руководство по диагностике неисправностей в Kubernetes;
➡Записки о containerd;
➡Зачем нужен контейнер pause в Kubernetes;
➡Как я клонировал Томми Версетти, или запускаем GUI/GPU приложения в Kubernetes;
➡Отказоустойчивый кластер с балансировкой нагрузки с помощью keepalived.
• Ну и вот еще очень содержательный репозиторий, который содержит сотни инструментов для работы с Kubernetes и контейнерами: Awesome Open Source K8s And Container Tools.
#Kubernetes
👩💻 Руководство по современным сетевым политикам Kubernetes.
• Сетевые политики — основополагающий аспект защиты кластеров Kubernetes. Политики L4 обеспечивают базовый контроль над трафиком на основе IP-адресов и портов, в то время как политики L7 позволяют гранулярно контролировать трафик на уровне приложений с помощью надёжной криптографической идентификации. Комбинируя оба типа политик и используя service mesh, можно реализовать модель «нулевого доверия», отвечающую современным вызовам в области безопасности.
• Это руководство для тех, кто хочет узнать больше об управлении сетевым трафиком Kubernetes на основе политик. Вы узнаете о разных типах политик и о том, почему они важны, о плюсах и минусах каждой из них и о том, как их определять и когда следует комбинировать.
➡Первоисточник || Источник.
#Kubernetes
👩💻 Техническая история Kubernetes: секреты создателя.
• Эта история от первого ведущего архитектора проекта, Брайана Гранта, который постил в Twitter серию тредов о технической истории проекта. Он рассказал о появлении разных фичей в K8s и логике, которая стояла за принятием отдельных решений.
• В честь юбилея оркестратора Брайан собрал все твиты в одну статью. Это её перевод, из которого вы узнаете, как появились контроллеры рабочих нагрузок, декларативная модель ресурсов, descheduler и многое другое:
➡️https://habr.com/ru/post/851176/
#Kubernetes
👩💻 Инструменты для обеспечения безопасности Kubernetes.
• ПО для обеспечения безопасности Kubernetes… их так много, и у каждого свои цели, область применения и лицензии... Однако, хочу поведать Вам о некоторых интересных решениях с открытым исходным кодом, которые полностью бесплатны:
• Trivy — простой, но мощный сканер уязвимостей для контейнеров, легко интегрируемый в CI/CD-пайплайн. Его примечательная особенность — простота установки и работы: приложение состоит из единственного бинарника и не требует установки базы данных или дополнительных библиотек. Обратная сторона простоты Trivy состоит в том, что придется разбираться, как парсить и пересылать результаты в формате JSON, чтобы ими могли воспользоваться другие инструменты безопасности Kubernetes.
• Portieris — это admission controller для Kubernetes; применяется для принудительных проверок на доверие к контенту. Portieris использует сервер Notary в качестве источника истины для подтверждения доверенных и подписанных артефактов (то есть одобренных контейнерных образов). При создании или изменении рабочей нагрузки в Kubernetes Portieris загружает информацию о подписи и политику доверия к контенту для запрошенных образов контейнеров и при необходимости на лету вносит изменения в JSON-объект API для запуска подписанных версий этих образов.
• Kube-bench — приложение на Go, проверяющее, безопасно ли развернут Kubernetes. Ищет небезопасные параметры конфигурации среди компонентов кластера (etcd, API, controller manager и т.д.), сомнительные права на доступ к файлам, незащищенные учетные записи или открытые порты, квоты ресурсов, настройки ограничения числа обращений к API для защиты от DoS-атак и т.п.
• Kube-hunter — Kube-hunter «охотится» на потенциальные уязвимости (вроде удаленного выполнения кода или раскрытия данных) в кластерах Kubernetes. Kube-hunter можно запускать как удаленный сканер — в этом случае он оценит кластер с точки зрения стороннего злоумышленника — или как pod внутри кластера. Отличительной особенностью Kube-hunter'а является режим «активной охоты», во время которого он не только сообщает о проблемах, но и пытается воспользоваться уязвимостями, обнаруженными в целевом кластере, которые потенциально могут нанести вред его работе. Так что пользуйтесь с осторожностью!
• Kubeaudit — это консольный инструмент, изначально разработанный в Shopify для аудита конфигурации Kubernetes на предмет наличия различных проблем в области безопасности. Например, он помогает выявить контейнеры, работающие без ограничений, с правами суперпользователя, злоупотребляющие привилегиями или использующие ServiceAccount по умолчанию. У Kubeaudit есть и другие интересные возможности. К примеру, он умеет анализировать локальные файлы YAML, выявляя недостатки в конфигурации, способные привести к проблемам с безопасностью, и автоматически исправлять их.
• Kyverno — движок политик безопасности Kubernetes с открытым исходным кодом, который помогает вам определять политики с помощью простых манифестов Kubernetes. Он может проверять, изменять и генерировать ресурсы Kubernetes. Таким образом, это может позволить организациям определять и применять политики так, чтобы разработчики и администраторы придерживались определенного стандарта.
#Kubernetes
👩💻 Play with Kubernetes — сервис для практического знакомства с K8s.
• PWK полностью повторяет идею (и даже интерфейс) своего «прародителя» Play with Docker (о котором я упоминал вчера): его основной сайт — это так называемая «игровая площадка» (playground), предоставляющая в веб-браузере доступ к виртуальной Linux-машине для возможности проведения экспериментов с кластерами Kubernetes. По сути это доступный бесплатно SaaS-аналог Minikube со своими удобствами (работа прямо в браузере) и ограничениями
• Предлагаемая в онлайн-сервисе лабораторная работа ориентирована на начинающих и посвящена основным концепциям и возможностям Kubernetes:
- Что вообще позволяет делать эта система: запуск контейнеров, балансировка нагрузки, выкатывание новых версий образов, автомасштабирование…;
- Архитектура Kubernetes;
- Ресурсы Kubernetes: узлы, поды, сервисы, пространства имён, секреты;
- Декларативный подход;
- Сетевая модель Kubernetes;
и т.п.
• Выглядит же прохождение лабораторной работы аналогично тому, как всё было в Play with Docker: слева у вас есть документ-инструкция (в том числе и команды для ввода), а справа — терминал (точнее, их два — для двух узлов Kubernetes), позволяющий «поиграть» в администратора K8s-кластера и видеть, что и как происходит на самом деле. Последнему, безусловно, способствует возможность выполнять произвольные уточняющие команды на любых этапах выполнения работы.
➡️https://labs.play-with-k8s.com
#Kubernetes
👩💻Kubenomicon.
• Поделюсь с Вами очень интересным проектом, который описывает методы атак на Kubernetes. Проект сырой, но постоянно дополняется необходимой информацией. Особенно будет полезно изучить начинающим специалистам: https://kubenomicon.com/
#Kubernetes
👩💻 Top 4 Kubernetes Service Types in one diagram.
• ClusterIP — открывает доступ к сервису по внутреннему IP-адресу в кластере. Этот тип делает сервис доступным только внутри кластера;
• NodePort — открывает сервис на том же порту каждого выбранного узла в кластере с помощью NAT. Делает сервис доступным вне кластера через <NodeIP>:<NodePort>. Является надмножеством ClusterIP;
• LoadBalancer — создает внешний балансировщик нагрузки в текущем облаке (если это поддерживается) и назначает фиксированный внешний IP-адрес для сервиса. Является надмножеством NodePort;
• ExternalName — открывает доступ к сервису по содержимому поля externalName (например, foo.bar.example.com), возвращая запись CNAME с его значением. При этом прокси не используется. Для этого типа требуется версия kube-dns 1.7+ или CoreDNS 0.0.8+.
➡ Подробнее тут: https://kubernetes.io/ru/
#Kubernetes