Популярность облачных платформ и контейнеров растет с каждым днем. Вместе с этим появляется необходимость в активном контроле и защите используемых решений.
Есть много инструментов, которые могут сделать работу в K8s безопасной, а процессы — прозрачными и эффективными. Но в статье поговорим о самом недооцененном, но тем не менее актуальном способе для анализа безопасности в Kubernetes: о сборе Kube-Audit логов.
Привет, Хабр!
Меня зовут Рустем Галиев, я Senior DevOps Engineer в IBM, и мы продолжаем разбираться, как искать и эксплуатировать уязвимости в контейнеризированных средах на примере практических атак. Первую часть статьи можно найти тут, а ссылку на третью добавлю сюда, когда выложу.
Почему иногда argocd-vault-plugin не расшифровывает секреты и что с этим делать. Разберём особенность работы плагина на примере чарта Apache Airflow.
Привет, Хабр!
Меня зовут Рустем Галиев, я Senior DevOps Engineer в IBM.
В последние годы контейнеризация стала неотъемлемой частью инфраструктуры для современных приложений. Технологии контейнеризации, такие как Docker и Kubernetes, предоставляют удобный способ упаковки, развёртывания и масштабирования приложений, а также обеспечивают лёгкость миграции и управление зависимостями. Но, как и любая другая технология, контейнеры имеют свои уязвимости. Ошибки в конфигурации, слабые политики безопасности и недостаточная изоляция контейнеров могут превратить их в привлекательные цели для злоумышленников.
Эта статья расскажет, как искать и эксплуатировать уязвимости в контейнеризированных средах, рассматривая ключевые аспекты контейнерной безопасности, включая распространенные уязвимости, ошибки в конфигурации, а также методы для их выявления и эксплуатации. Мы обсудим примеры практических атак, таких как контейнерный брейкаут, межконтейнерные атаки, перехват данных и несанкционированное использование секретов, а также дадим рекомендации по предотвращению этих угроз.
Статью разделил на три части, ссылки на вторую и третью добавлю, после того как выложу.
Научные и прикладные исследования в сфере нано- материалов и технологий ( НМ и НТ), области вычислительной техники проводятся широким фронтом во всем мире и РФ не является исключением. Известный закон Мура показывает, что люди практически исчерпали возможности полупроводниковых материалов, и носителей информации на которых базируется электронная техника. Рост быстродействия вычислений за счет уменьшения элементов и увеличения их количества на единице площади подошел к своему физическому пределу.
Специалисты это понимают и предпринимают определенные попытки для сохранения темпов развития цивилизации. Разыскивают и создают новые материалы, физические принципы, разрабатывают теории, позволяющие находить выход из приближающегося кризиса. Но их мало и возможности их ограничены. Дело не только в финансах и отсутствии новых перспективных теорий. Огромное значение приобретает этическая сторона, что мы уже видим в биологических исследованиях, в искусственном интеллекте и других направлениях. (Кодекс этики ИИ и всеобщая декларация о биоэтике и правах человека и др.)
Оказалось, что эта сфера очень слабо разработана и предпринимаемые меры оказываются без четкого обоснования, а часто сильно запаздывающими.
В предлагаемой публикации автор касается всего лишь одной сферы деятельности людей, связанной с вычислениями и вычислительными средствами. (см. здесь).
Откуда у контейнера берётся файловая система? Чтобы разобраться, инженер Google Михал Питр воспроизвёл действия Docker и создал файловую систему своими руками. От полноценной реализации его результат отличается тем, что в нём не используется пространство имён для дополнительной изоляции.
Под катом — перевод, который поможет разобраться, как именно Docker создаёт новую файловую систему с помощью OverlayFS.
Dev и Ops, DevOps, DEVOPS – как много о нем сейчас разговоров. И не зря!
DevOps – это перспективное направление, которое будет продолжать развиваться и влиять на IT-индустрию в ближайшие годы, а то и десятилетия.
Это подтверждается ростом числа вакансий, связанных с DevOps, и увеличением спроса на специалистов в этой области. Например, анализ данных с hh.ru показывает, что количество DevOps-вакансий за год значительно выросло.
Несмотря на растущий спрос, на рынке наблюдается дефицит квалифицированных специалистов в области DevOps. Это связано с тем, что работа в DevOps требует широкого спектра навыков, включая знание различных инструментов автоматизации, умение работать в команде и адаптироваться к быстроменяющимся условиям.
DevOps: кто это? Разработчик? Системный Администратор? Менеджер? Или все вместе? 😱
DevOps – это не просто должность или роль, это целая методология!
Предлагаю начать с разбора понятия DevOps, продолжим с разбора профессии DevOps-инженер, и завершим его ролью и стеком технологий.
Привет, Хабр! Сегодня мы рассмотрим механизмы garbage collection в Kubernetes: как удалять orphaned pods, утилизировать устаревшие данные и управлять томами.
Garbage Collection в Kubernetes — это автоматизированный процесс очистки неиспользуемых ресурсов, который предотвращает засорение кластера «мусором». Без GC кластер может превратиться в лабиринт забытых подов, устаревших ConfigMaps и ненужных томов, что очевидно приведет к снижению производительности и увеличению затрат.
Привет, Хабр! В прошлых постах мы разобрали особенности Docker на разных системах и его не менее интересного собрата Podman от Red Hat. Сегодня поговорим о ещё одном творении той же компании — OpenShift, который позиционируется, как "корпоративная" версия Kubernetes. Но так ли всё радужно, как рассказывают на презентациях?
Очень удобным способом настройки кластеров kubernetes является использование GitOps подхода. Его суть заключается в том, что выделяется отдельный git репозиторий, который становится хранилищем всех манифестов, определяющих состояние кластера. Таким образом мы получаем единое хранилище истины и единую точку конфигурации для управления кластером. Одним из пионеров и проповедников этого подхода являлась компания WeaveWorks, в рамках которой было разработано множество интересных решений, среди которых есть и GitOps-оператор FluxCD. Именно он и реализует цикл синхронизации манифестов из git репозитория с кластером.
Давно ли вам приходилось перезапускать стейджинговую систему, на которой развернута масса приложений и работает не одна сотня команд? Мы частенько издевались над стейджем, но никогда не выключали его целиком. И в процессе плановой замены сетевого стека в кластере k8s stage решили сделать масштабную проверку возврата системы и всех запущенных на ней приложений в работоспособное состояние после «внезапного отключения питания в локальном ЦОД».
Кабели никто перерезать не собирался, но идея «выключить и включить» традиционно выглядела как «приключение на 20 минут». Именно так всё и случилось: кластер k8s не смог вернуться в рабочий режим, приложения не запускались, и причины тому крылись не внутри, а снаружи.
Под катом хронология двухдневных драматических событий, варианты действий и некоторые размышления после проведённых «учений».
Привет, Хабр! Я Маша Башан, Python разработчик в команде dBrain. Сегодня расскажу, как в dBrain мы внедрили собственную стратегию тестирования, которая в разы сокращает количество действий работающих с платформой инженеров. Мы применили альтернативный вариант тестирования — с помощью сервиса Apache Airflow.
Каждый стартап рано или поздно сталкивается с необходимостью обработки платежей онлайн.
В эпоху SaaS, PaaS, IaaS и других «As a Service» инициатив (их число постоянно растет), многие полагаются на бизнес модель платных подписок, так как она обеспечивает возможность регулярно в автоматическом режиме собирать платежи с пользователей и дает лучшую прогнозируемость финансовых потоков.
На рынке сейчас много поставщиков продуктов для решения данной задачи, однако есть среди них один, чьи продукты обычно рассматривают в первую очередь. Я говорю о Stripe.
В этой статье я хочу предложить читателю технический взгляд на решение проблемы обработки онлайн подписок с помощью языка программирования Scala и фреймворка Akka в распределенном серверном приложении для Кубернетиса.
Kubernetes действительно поражает своими могучими возможностями к расширению. Вы наверняка уже знаете про operator-паттерн, а также фреймворки kubebuilder и operator-sdk с помощью которых можно его реализовать. Если вкратце, то они позволяют расширять ваш Kubernetes через определение кастом-ресурсов (CRDs) и написание дополнительного контроллера, который будет выполнять вашу бизнес-логику для реконсиляции и управления этими ресурсами. Этот подход широко изучен, а в интернете можно найти огромное количество информации о том, как написать такой оператор.
Однако это не единственный метод расширения Kubernetes API. Так, для более сложных кейсов, например реализации императивной логики, сабресурсов и формирования ответов на лету, можно рассмотреть механизм API aggregation layer, который поддерживается в Kubernetes. В рамках aggregation layer можно разработать свой собственный extension API server и бесшовно интегрировать его в общий Kubernetes API.
В этой статье мы разберем, что такое API aggregation layer, для решения каких задач его стоит использовать, когда его использовать не стоит и как мы использовали эту модель для реализации собственного extension API server в платформе Cozystack.
Не кажется ли вам, что декларативная конфигурация и программирование инфраструктуры не так уж хороши, как их расхваливают?
Я достаточно долго занимался декларативной конфигурацией в Kubernetes: размышлял о ней, работал с kubectl apply, KRM, kustomize, Google Cloud Config Sync, kpt, porch, ... В то же время параллельно развивалась декларативная автоматизация — эта работа велась в Google, где на протяжении многих лет широко использовалась декларативная конфигурация. При этом вне Google появился Terraform, и на этом лоскутном одеяле также возникло множество других инструментов.
Что же такое декларативная конфигурация, в каких случаях она хороша, и как к ней подступиться?
Привет, Хабр, я Вера Орлова — отвечаю за безопасность контейнеров и маркетплейс аддонов в Kubernetes в компании Cloud.ru. В статье расскажу, какие основные проблемы при работе с контейнерами существуют и какие вызовы встают перед разработчиками платформ контейнерной безопасности. Поделюсь, на какие аспекты защиты обращаем внимание в первую очередь мы, а также расскажу про наш подход к профилактике потенциальных уязвимостей и реальных проблем безопасности.
Надеюсь, тем, кто только начинает погружаться в эту область, мой рассказ поможет разобраться в теме и составить собственный список мер и необходимых для безопасности сервисов.
Однажды, в ходе планового обновления кластера Kubernetes, мы обнаружили, что почти все POD'ы (около 500 из 1000) на новых(обновленных) узлах не смогли запуститься. Минуты ожидания быстро превратились в часы. Мы активно искали первопричину...3 hours later... Спустя три часа POD'ы всё ещё находились в состоянии ContainerCreating.
Пользоваться общей инфраструктурой Docker очень удобно. Тысячи готовых образов, доступных вам через одну команду в консоли, в любом месте, где есть интернет. Ничего удивительного в том, что это вошло в обиход большого числа разработчиков. Но образы контейнеров занимают много места, и качать некоторые из них довольно долго. Зачастую хочется иметь свой или хотя бы локальный реестр. Да и безопаснее это... Наверное?
Зная, что в Docker private registry отсутствует авторизация, я решил разобраться, как легким способом можно блокировать различные действия для клиентов и разрешать все админам. Мне нужно было ограничить получение какой-либо информации по репозиториям, находящимся в реестре, выгрузку образов из реестра, а также запретить загрузку репозиториев, которые уже существуют в реестре. Начнем с основы основ — загрузки и выгрузки образов с помощью API v2.
Привет, всем! В данной статье мы расскажем о Highly Available исполнении CI/CD платформы Gitorion. В данном случае платформа размещается в двух дата центрах. При отказе любого из дата центров команда разработчиков может продолжить непрерывную интеграцию и доставку в выжившем дата центре.
Каждый, кто работал с Helm чартами, сталкивался с необходимостью валидации values.yaml. Стандартный подход с использованием JSON Schema работает, но часто становится громоздким и ограниченным. В этой статье я хочу представить Helm CEL — плагин, который позволяет использовать Common Expression Language (CEL) от Google для валидации конфигурации Helm чартов.
