- PVSM.RU - https://www.pvsm.ru -
Сегодня мы с огромной радостью представляем доклад Sysdig об использовании контейнеров за 2019 год (Sysdig 2019 Container Usage Report [1]). Kubernetes продолжает набирать обороты, активнее осваиваются облачные архитектуры, и все это меняет не просто паттерны использования, но и процессы и организационные структуры. Удивительно, но в этом году двукратно увеличилось число контейнеров, срок жизни которых не превышает 5 минут. Чем динамичнее становятся сервисы, тем лучше облачные команды сознают необходимость интеграции безопасности в процессы DevOps. В рамках доклада об использовании за 2019 год мы впервые исследуем детали безопасности и соответствия — в дополнение к ряду деталей о том, как клиенты используют контейнеры, Kubernetes и проч.
Sysdig Secure DevOps Platform [2] предоставляет реальный взгляд на инфраструктуру, приложения и контейнеры. Наш доклад охватывает компании по всему миру и во многих сферах деятельности. В этом году мы включили детали как по SaaS, так и по локальным пользователям Sysdig, чтобы представить вам картину коммерческого использования на примере двух с лишним миллионов развернутых контейнеров.
Подробнее о результатах.
В доклада за 2018 год мы описывали, как Open Container Initiative (OCI) [3] помогала ввести альтернативные среды запуска контейнеров. В 2019 году это случилось и с большим размахом: проект containerd отхватил значительную долю в 18%. Справедливости ради стоит отметить, что containerd используется Docker'ом. Прежде его движок реализовал как высокоуровневые, так и низкоуровневые функции среды запуска. Теперь они разбиты на два отдельных проекта: containerd и runc.
В этом году дебютировала CRI-O. Среди прочего нас удивил низкий уровень освоения на сегодняшний день. CRI-O, облегченная среда исполнения Kubernetes, появилась в Red Hat в 2016 году и была принята в CNFC© [4] в 2019-м. Мы думаем, уровень освоения вырастет, как только пользователи Red Hat OpenShift мигрируют с v3 на v4, где CRI-O замещает прежде принятый движок Docker'а.
За прошедший год среднее число контейнеров на физический сервер выросло до 30, удвоившись, по сравнению с 15 — за 2018 год и 10 в 2017-м.
Мы считаем, что эта цифра увеличится, основываясь на нескольких факторах:
В 2019 году максимальная плотность контейнеров на узел составляла 250, а это — 38-процентное увеличение, по сравнению с 2018 годом.
Неудивительно, что как инструмент оркестрации де-факто Kubernetes забрал аж 77% доли используемых оркестраторов. Это число увеличиться до 89%, если добавить Red Hat OpenShift и Rancher — оба построены на Kubernetes. А вот текущая ситуация в цифрах:
Если разделить данные для компаний, которые разворачивают платформу Sysdig локально, картина оркестрации меняется значительным образом. В этом сегменте Red Hat OpenShift Container Platform [5] выбивается в лидеры. Основная причина в том, что организации-пользователи — обычно крупные и осторожные, желают пользоваться преимуществами Kubernetes, но предпочитают делать это с коммерчески поддерживаемыми локальными решениями типа "Платформа как сервис" (PaaS), например OpenShift.
Также в докладе за 2019 год мы исследуем статистику использования общедоступных облаков. Скачайте его, чтобы узнать детали [1].
"Внедряйте безопасность заранее" стало навязчивой фразой. Она описывает подход, когда безопасность встраивают на ранних стадиях жизненного цикла разработки. Вообще, организации, работающие с контейнерами, понимают, как необходимо внедрять безопасность и соответствие в рабочий процесс DevOps. Чтобы получить представление о безопасности и соответствии в сфере контейнеров и Kubernetes, мы анализируем данные из области сканирования на уязвимости, безопасности среды запуска и соответствия CIS.
Клиенты сканируют образы, чтобы обнаружить, блокировать и устранить уязвимости контейнеров в конвейерах CI/CD и реестрах контейнеров. В полном докладе мы рассматриваем используемые реестры, процент образов, извлекаемых из общедоступных и частных репозиториев. Также даем соотношение успешное/неуспешное сканирование образов на уязвимости. Вот несколько выводов.
Извлечение образов: общественные vs частные репозитории
Сколько контейнеров извлекается из общедоступных или частных репозиториев? Мы выяснили, что 40% образов происходят из общедоступных источников.
Использовать образы контейнеров из открытых репозиториев чревато — потому, что лишь немногие из них соответствуют стандартам или проверены на уязвимости в плане безопасности. Возьмем, к примеру, Docker Hub [6]: образы, помеченные "Certified", "Official" и "Verified Publisher" больше достойны доверия. Однако из трех миллионов образов, размещенных на сервере, менее 1% имеют такие обозначения. С целью снизить риск, облачные команды создают политики для определения, какие реестры контейнеров могут быть одобрены к использованию в их организациях.
Сканирование образа
Независимо от источника, сканировать образа на предмет известных уязвимостей перед развертыванием в производственную среду — лучшая практика, пренебрегать которой нельзя. Чтобы оценить масштаб рисков или уязвимостей, мы взяли образцы прошедших и не прошедших проверку образов, просканированных за 5-дневный период. Больше половины образов проверку не прошли, а значит, в них были выявлены известные уязвимости высокой и очень высокой степени опасности.
После того, как разработчики рассмотрят известные проблемы, облачные команды должны установить политики, определяющие аномальное поведение и заставляющие срабатывать оповещение безопасности в производственной среде. Безопасность среды запуска для Kubernetes — это нечто новое для компаний, но понимают они, что к чему, быстро. За последний год из Docker Hub 6,7 млн раз извлекли Falco [7], открытый проект CNCF для безопасности среды запуска, вклад Sysdig. Это на 252% больше, чем за предшествующий год.
Мы смотрели на нарушение политик в контексте объема оповещений, которые клиенты получили от Sysdig Secure, который автоматизирует безопасность среды запуска с политиками Falco. Он определяет типы рисков для безопасности, с которыми чаще всего сталкиваются пользователи контейнеров. Среди них самые распространенные это:
1 — Попытки получить доступ к чувствительным томам, каталогам или файлам; 2 — Начало работы при слишком большом количестве разрешений или попыток расширить привилегии; 3 — Запуск командной оболочки с привязанного терминала
В полном докладе об использовании мы детально рассматриваем 10 нарушений, ранжируя их по частотности, а заодно описываем каждое из них, объясняем потенциальную угрозу.
Чтобы снизить риск и удовлетворить стандартам соответствия, включающим PCI-DSS, HIPAA и GDPR, организациям следует регулярно проверять серверы и контейнеры при помощи лучших практик. Аудиты, выполненные с использованием встроенных контрольных показателей CIS для проверок Docker [8] в Sysdig Secure показывают, что улучшать еще есть что. Например, мы выяснили, что обычно на контейнерных серверах встречаются:
Open-source изменил лицо обработки данных в масштабах организаций. Он не просто стимулирует инновации по всей инфраструктуре, но и особенно в разработке приложений. Sysdig автоматически вскрывает процессы внутри контейнеров, чтобы увидеть решения, составляющие облачные сервисы, которые наши клиенты запускают в производственной среде. И вот топ-10 из них:
Из новинок этого года — Node.jv и Go (он же golang), которые в плане использования опережают Java. Java заслуженно считается одним из выдающихся языков программирования. Команды DevOps и облачные команды, похоже, предпочитают опции поновее, вроде Go, созданные инженерами Google, — отчасти, потому что они проще в использовании. Например, Node.jv, среда для выполнения JavaScript, упрощает написание кода, который одинаково хорошо работает как на серверах, так и в браузерах. Он также хорошо подходит для нового поколения баз данных типа CouchDB и MongoDB, поддерживающих написанные на JavaScript запросы.
Параметры того, как долго (или как мало) живут контейнеры, образы контейнеров и сервисы, одна из самых популярных тем нашего доклада за 2018 год. Он отражает, насколько современные приложения динамичнее, — как с точки зрения разработки, так и с точки зрения среды выполнения.
Сравнивая год за годом сроки жизни контейнеров, мы обнаружили, что число контейнеров, живущих менее 10 секунд, удвоилось и составляет 22%. При этом число контейнеров, которые живут 5 минут и менее, также удвоилось.
Многим контейнерам требуется короткий срок жизни, чтобы только выполнить функцию и сразу самоуничтожиться. Секунды — это, вроде бы, мало, но для некоторых процессов большего не требуется. Мы считаем, что этому росту поспособствовало увеличенное использование Kubernetes Jobs, запускающих конечные задачи типа пакетных работ. Скажем больше, мы ожидаем увеличения количества маложивущих контейнеров, особенно на бессерверных платформах, которые хорошо подходят для запуска краткосрочных задач.
Эфемерная природа контейнеров — это одно из уникальных преимуществ технологии. В то же время она сильно усложняет задачи типа "увидеть проблемы с безопасностью, работоспособностью и производительностью". Инструменты мониторинга, безопасности и соответствия в реальном времени, обеспечивающие наблюдаемость в реальном времени, в свете коротко живущих процессов, — это ключ к успешным операциям.
Контейеры — идеальный компаньон для гибкого движения. Они помогают ускорить разработку и релиз кода, зачастую в виде контейнеризированных микросеврисов. Мы выяснили, что более половины образов контейнеров заменяются — или пересматриваются — в течение недели или меньше. Это показатель того, как сократилось время между релизами кода. Далее, это указывает на то, что конвейеры CI/CD помогают командам разработчиков поставлять обновления ПО в необычайно высоких темпах.
Специальные метрики кода позволяют разработчикам и командам DevOps настраивать код так, чтобы он собирал уникальны метрики. Из трех основополагающих решений: JMX, StatsD и Prometheus, — за прошедший год Prometheus [9] выбился в лидеры по используемости. На самом деле, с годами использование метрик Prometheus у наших клиентов, которые используют специальные метрики, выросло на 130%. Метрики JMX (для приложений на Java) и StatsD используются все реже (в этом году на 45% и 17% соответственно), по мере того как ширится использование новых фреймворков для программирования, поддерживающих Prometheus.
Чтобы узнать топовые метрики и exporters Prometheus, которыми пользуются клиенты Sysdig, смотрите полный доклад.
Настройки аварийных ситуаций у клиентов Sysdig наглядно демонстрируют, в чем облачные команды наибольшие угрозы для операций контейнеров. Самые распространенные аварийные настройки сместились в пользу инфраструктуры Kubernetes, продолжая в то же время фокусироваться на использовании ресурсов и работоспособности. Вот Топ-3 из более чем 800 уникальных аварийных настроек, распространенных у клиентов Sysdig:
Плюс к этому, оповещения могут быть настроены на конкретные метки или облачные ярлыки / Kubernetes. Скажем, используя пример из вышеприведенных оповещений, вы можете привязать оповещение cpu.used.percent к индивидуальному пространству имен типа "istio-system", или конкретному имени Pod'а типа "envoy" внутри пространства имен. Посмотрите топ привязок для оповещений в полном докладе.
Сколькими кластерами управляют пользователи? Сколько Pod'ов на каждом узле? Использует ли кто-нибудь Kubernetes Jobs? Доклад за 2019 год отвечает на эти и другие вопросы. Вот пример того, что клиенты разворачивают с Kubernetes.
Какие-то клиенты устанавливают всего несколько кластеров — один больше и несколько поменьше, — тогда как другие располагают внушительным парком из множества кластеров разнообразных размеров. Таблицы ниже показывают распределение числа кластеров и количества узлов на кластер у клиентов платформы Sysdig:
Большое число клиентов, управляющих единственным кластером или небольшим их числом, указывает на то, что многие предприятия еще только начинают осваивать Kubernetes. На результат наблюдения повлияло и использование управляемых сервисов Kubernetes в общедоступных облаках. С сервисами типа Amazon Elastic Kubernetes Service (EKS), Google Kubernetes Engine (GKE), Azure Kubernetes Service (AKS) и IBM Cloud Kubernetes Service (IKS) пользователи могут раскручивать и дробить кластеры так быстро, как им надо.
Pod'ы — это наименьший разворачиваемый объект в Kubernetes. Они состоят из одного или нескольких контейнеров с общим хранилищем и сетью, также как и спецификацией относительного того, как запускать контейнеры. Вот анализ по пользователям платформы Sysdig:
Важно! Эта таблица обновилась, чтобы исправить ошибку в оригинальном образе. Большое спасибо Крису Коллинзу — он же @ChrisInDurham [10] — за то, что заметил проблему!
Pod существует на физическом сервере до завершения всех своих процессов, но может быть удален при перемещении на другой сервер в случае недостатка ресурсов или отказа физического сервера. Вот снимок распределения Pod'ов на сервер у пользователей платформы Sysdig:
Информация по числу пространств имен Kubernetes, развертываний, StatefulSets и задач доступна в полном докладе.
С последнего нашего доклада об использовании плотность контейнеров удвоилась, и очевидно, что скорость освоения повышается по мере привыкания к использованию. Ключевые выводы из нашего третьего ежегодного доклада подчеркивают потребность предприятий в шагах по подготовке к ожидаемому бурному росту:
Для того, чтобы узнать все детали, скачайте полный доклад Sysdig об использовании за 2019 год [1].
Автор: nAbdullin
Источник [11]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/security/339622
Ссылки в тексте:
[1] Sysdig 2019 Container Usage Report: https://sysdig.com/resources/papers/2019-container-usage-report/
[2] Sysdig Secure DevOps Platform: https://sysdig.com/platform/
[3] Open Container Initiative (OCI): https://www.opencontainers.org/
[4] CNFC©: https://www.cncf.io/
[5] Red Hat OpenShift Container Platform: https://www.openshift.com/products/container-platform/
[6] Docker Hub: https://hub.docker.com/search?q=&type=image
[7] Falco: https://falco.org/
[8] контрольных показателей CIS для проверок Docker: https://www.cisecurity.org/benchmark/docker/
[9] Prometheus: https://www.prometheus.io/
[10] @ChrisInDurham: https://twitter.com/ChrisInDurham
[11] Источник: https://habr.com/ru/post/479682/?utm_source=habrahabr&utm_medium=rss&utm_campaign=479682
Нажмите здесь для печати.