Как изменился поиск черной кошки в темном Kubernetes

Как изменился поиск черной кошки в темном Kubernetes

В настоящее время многие компании только планируют начать работать или же уже работают с Kubernetes. Между тем, существует целый ряд трудностей, с которым они могут столкнуться во время работы на разных этапах разработки приложений.

В каждой организации Kubernetes уникален и удовлетворяет конкретные потребности. Поэтому чужие истории успеха, рассказывающие об использовании тех или иных инструментов, могут быть совершенно неэффективны для вашей компании.

image

Характеристики компаний, работающих с Kubernetes

Итак, чтобы лучше понимать суть проблем, с которыми могут столкнуться компании, работающие с Kubernetes, давайте сначала перечислим их основные характеристики.

  1. Компания подразделяется на команды. Вот лишь некоторые из них:
    • Разработчики занимаются созданием приложений и сервисов, наполняя продукты разнообразными фичами, после чего передают их на этап Production.
    • QA-специалисты тестируют фичи и сервисы, полученные от разработчиков. Задача этой команды состоит в том, чтобы выявить все проблемы и недостатки продукта на ранних стадиях.
    • Специалисты из команды Ops и SRE обеспечивают надежную бесперебойную работу сервисов.
    • Специалисты по безопасности отвечают непосредственно за безопасность приложений и всех данных, применяющихся в работе.

    Каждая из команд имеет свои специфические цели, задачи и KPI. Как правило, отделы неравнозначны в количестве сотрудников, а каждая из команд имеет свой инструментарий, который дает определенный взгляд на систему или ее часть – что зачастую вызывает расхождения в степени информированности и взглядах на систему.

  2. Как правило, компании имеют не только огромное количество собственных сервисов, разрабатывающихся внутри компании, но и разнообразные инфраструктурные сервисы, позволяющие организовать дополнительную поддержку собственным сервисам и инфраструктуре в целом. При этом каждый из сервисов компании – будь то собственный, инфраструктурный или системный – должен работать бесперебойно, понятно и безопасно.
  3. Наконец, в жизненном цикле микросервисов могут использоваться различные кластеры, выполняющие разные роли: Dev, Test, Stage, Prod. Каждый из кластеров отличен от другого хотя бы немного, что в итоге приводит к созданию нескольких разных окружений, которые могут влиять на все микросервисы в них.

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

Как повысить прозрачность происходящего в приложениях

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

Специалисты из Luntry предлагают вам собственное видение, которое мы реализуем с помощью Luntry, для того чтобы справиться с трудностями, возникающими в рабочем процессе.

  • Понятное окружение. Невозможно контролировать то, что вы не видите. Все окружения должно быть прозрачными и понятным для каждой из команд, которые работают с Kubernetes. Каждый отдел должен понимать, чем один кластер отличается от другого, в чем отличия всех приложений и что они из себя представляют.
  • Понятное поведение. Поведение приложений должно быть понятным и наблюдаемым, предсказуемым, поскольку это дает возможность контролировать развитие как самой инфраструктуры, так и всех приложений. Также это необходимо для своевременного обнаружения аномалий, которые могут свидетельствовать о сбоях, инцидентах безопасности как в собственных сервисах, так и сторонних.
  • Обмен знаниями. Необходимо обеспечить в компании все условия для быстрого обмена знаниями и информацией внутри команды, а также между разными командами и департаментами. Это важно для создания единой картины и общения «на одном языке» при выполнении разного рода задач, что позволяет сократить время на встречи и обсуждения, а также минимизировать недопонимания.
  • Актуальная информация. Команды должны иметь постоянный доступ к актуальной, а не устаревшей информации, чтобы оперативно и самостоятельно принимать решения в разных ситуациях.
  • Безопасность Cloud-native не должна быть блокером и тайной. Нельзя поставить бизнес на паузу на время решения проблем безопасности. Kubernetes позволяет гибко работать с рисками, и наше решение призвано помочь с плавным переходом к внедрению подходов Shift Everywhere Security, Zero Trust, Security-as-Code, не мешая текущему процессу.
  • Kubernetes-native. Все должно проходить в терминах K8s и в контексте его ресурсов, чтобы дать всем командам единое представление о системе на «языке» Kubernetes.

О решении Luntry

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

Luntry позволяет:

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

Что Luntry предоставляет?

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

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

Создавайте надежные и безопасные системы проще и эффективнее!


Один хакер может причинить столько же вреда, сколько 10 000 солдат! Подпишись на наш Телеграм канал, чтобы узнать первым, как выжить в цифровом кошмаре!