Характеристики компаний, работающих с Kubernetes Итак, чтобы лучше понимать суть проблем, с которыми могут столкнуться компании, работающие с Kubernetes, давайте сначала перечислим их основные характеристики. - Компания подразделяется на команды. Вот лишь некоторые из них:
- Разработчики занимаются созданием приложений и сервисов, наполняя продукты разнообразными фичами, после чего передают их на этап Production.
- QA-специалисты тестируют фичи и сервисы, полученные от разработчиков. Задача этой команды состоит в том, чтобы выявить все проблемы и недостатки продукта на ранних стадиях.
- Специалисты из команды Ops и SRE обеспечивают надежную бесперебойную работу сервисов.
- Специалисты по безопасности отвечают непосредственно за безопасность приложений и всех данных, применяющихся в работе.
Каждая из команд имеет свои специфические цели, задачи и KPI. Как правило, отделы неравнозначны в количестве сотрудников, а каждая из команд имеет свой инструментарий, который дает определенный взгляд на систему или ее часть – что зачастую вызывает расхождения в степени информированности и взглядах на систему. - Как правило, компании имеют не только огромное количество собственных сервисов, разрабатывающихся внутри компании, но и разнообразные инфраструктурные сервисы, позволяющие организовать дополнительную поддержку собственным сервисам и инфраструктуре в целом. При этом каждый из сервисов компании – будь то собственный, инфраструктурный или системный – должен работать бесперебойно, понятно и безопасно.
- Наконец, в жизненном цикле микросервисов могут использоваться различные кластеры, выполняющие разные роли: 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, а также предоставить организациям единую базу знаний и удобный инструмент для взаимодействия разных специалистов. Создавайте надежные и безопасные системы проще и эффективнее!
|
