На рынок вышло российское решение Luntry для облачной безопасности

На рынок вышло российское решение Luntry для облачной безопасности

На рынок вышло российское решение Luntry для облачной безопасности

«Лантри» (`Luntry`) –– российское решение для безопасности и наблюдения за происходящим в Kubernetes (включая OpenShift и Managed Kubernetes) на уровне контейнеров, образов, K8s-ресурсов, сервисов, их взаимосвязи и эволюции.

За последнее время было обнаружено большое количество серьезных уязвимостей в облачных решениях и тех, которые обеспечивают их работу: CVE-2022-0811, CVE-2022-21701, CVE-2022-24348, CVE-2022-0492, CVE-2022-0847, CVE-2022-0185.

Компании активно переходят в Kubernetes, что требует непрерывного контроля происходящего в облаках и выстраивания процессов DevSecOps.

Luntry позволяет:

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

Что предоставляет Luntry для обеспечения надежной и безопасной работы Kubernetes?

  • Управление уязвимостями образов (на базе Kubernetes operators) 
  • Policy Engine (Kyverno или OPA Gatekeeper) 
  • Runtime Security (обнаружение на базе eBPF сенсора)
  • Предотвращение (AppArmor политики)
  • Контроль взаимоотношений между K8s-ресурсами
  • Ведение истории изменений для troubleshooting и root cause analysis
  • Визуализация и защита сети (на базе NetworkPolicy или авторизационных политик ServiceMesh)
  • Анализ RBAC (по субъектам, правам и ролям) 
  • Интеграция с SIEM (выгрузка в syslog в CEF формате)

Luntry – это решение для всех участников непрерывного процесса разработки и жизненного цикла приложений (DevSecOps) и их эффективного взаимодействия.

Бесплатный пилот и развертывание за 10 мин. Напишите разработчикам.

Зачем Яндекс Go создал отдельный язык для расчёта стоимости поездок

Цена поездки в Яндекс Go — это не расстояние, умноженное на минуты и километры. В расчёт вмешиваются геозоны, спрос, скидки, платные дороги, дополнительные остановки и требования вроде перевозки кота, велосипеда или лыж. Чтобы управлять этим хозяйством без бесконечных деплоев, разработчики вынесли алгоритм ценообразования из кода сервиса в собственный язык.

Как объяснили разработчики в статье на Хабре, прайсинг работает не только при заказе машины.

Он пересчитывает стоимость при смене маршрута или способа оплаты, завершении поездки, обращении в поддержку и проверке данных аналитиками. Цена при этом может быть фиксированной, интервальной или считаться по таксометру.

 

Сначала сервисы параллельно собирают параметры поездки: тарифную категорию, геозоны, скидки, повышенный спрос и дополнительные услуги. Зависимости между источниками выстраиваются в граф, а запросы выполняются асинхронно на базе userver. Если некритичный источник не ответил, весь расчёт не падает.

 

Сам алгоритм раньше можно было бы держать в C++, но он меняется в среднем дважды в неделю. Выкатка сервиса на 50 подов занимает около 40 минут, а лес динамических конфигов быстро превратил бы код в музей условных операторов.

Поэтому Яндекс разработал собственный DSL. В нём есть условия, функции, неизменяемые значения и fold вместо циклов. Правила собираются в последовательную цепочку: каждое преобразование получает текущую цену и параметры, а возвращает новый результат с метаданными. Грамматику описали через ANTLR 4, а верификатор Z3 проверяет, что программа не выдаст некорректную цену.

 

Теперь изменение алгоритма не требует пересборки сервиса, ошибочную версию можно быстро откатить, а каждый расчёт — воспроизвести по входным данным и промежуточным результатам.

 

В итоге прайсинг превратился в отдельную платформу, которой уже пользуются Такси, Доставка и сервис зарядки электромобилей.

RSS: Новости на портале Anti-Malware.ru