Все мы знакомы с контейнерами и любим их. Контейнеры используют одно и то же ядро хоста (host kernel), что делает их довольно мобильным и лёгким решением. С другой стороны, мы бы предпочли снизить риск причинения вреда хост‑машине или операционной системе, чего можно достичь при помощи sandbox‑технологий, и gVisor является одной из них.  Проверьте CVE-2020–14 386 — это уязвимость ядра Linux, приводящая к выходу из контейнера. В целом, эта уязвимость использует преимущество способности CAP_NET_RAW повреждать память, что приводит к получению злоумышленниками root‑доступа. В Docker эта возможность включена по умолчанию (вероятно, это связано с тем фактом, что она обычно используется сетевыми инструментами, такими как ping и tcpdump, и может быть повторно включена для устранения неполадок). Рабочие нагрузки, выполняемые с помощью gVisor, не были затронуты CVE — и это подводит нас к следующей части: пониманию, что такое gVisor и как можно его использовать. Контейнерная среда sandbox gVisor — это среда процессов, которая запускает контейнеры. Это, по сути, ядро приложения (написанное на Go 🎉 ), которое реализует значительную часть интерфейса системных вызовов Linux и обеспечивает дополнительный уровень изоляции между запущенными приложениями и операционной системой хоста. Эта архитектура обеспечивает значительную безопасность при одновременном снижении затрат, связанных с виртуализацией. Каждая sandbox имеет свой собственный изолированный экземпляр Sentry и Gofer. Gofer — обеспечивает доступ файловой системы к контейнерам. Ведёт процесс, который запускается с каждым контейнером. Взаимодействует с Sentry. Процесс Sentry запускается в ограниченном контейнере seccomp без доступа к ресурсам файловой системы. Gofer выступает посредником всех доступов к этим ресурсам, обеспечивая дополнительный уровень изоляции. Sentry — ядро приложения для контейнеров.  Поставляет все функциональные возможности ядра, необходимые для приложения, включая системные вызовы, доставку сигналов, управление памятью и многое другое. Когда приложение выполняет системный вызов, вызовы перенаправляются на Sentry, который выполнит необходимую работу по его обслуживанию. Например, Sentry не может открывать файлы напрямую: операции файловой системы, которые выходят за пределы sandbox’a, отправляются Gofer. Платформа gVisor реализует перехват системных вызовов, базовое переключение контекста и функциональность сопоставления памяти. Входной точкой для запуска изолированного контейнера является исполняемый файл runsc. Он реализует спецификацию времени выполнения OCI, которая используется Docker и Kubernetes, что приводит к беспрепятственной интеграции. Практический курс, охватывает все аспекты безопасности проекта на Kubernetes.   Настраивая контекстrunsc, мы можем выбирать между несколькими реализациями для платформы: ptrace — утилизация PTRACE_SYSEMU для выполнения пользовательского кода, не позволяющая ему выполнять системные вызовы хоста. Очень распространённая утилита, и это, обычно, лучший выбор при запуске внутри VM или в том случае, если виртуализация не поддерживается. KVM — использование Linux KVM, позволяющее Sentry действовать как в качестве гостевой ОС, так и в качестве VMM (которая отвечает за создание и управление VM на физическом хост-компьютере). Обеспечит лучшую производительность и преимущественно будет использоваться на голом металле, а не на виртуальной машине. GKE Sandbox — использует пользовательскую реализацию платформы, которая обеспечивает лучшую производительность, чем ptrace и KVM.   Это хороший вопрос. AppArmor, SELinux и Seccomp — лишь несколько замечательных примеров таких инструментов, которые могут помочь нам определить детализированные политики приложений с собственной производительностью. В основном они полагаются на перехватчики (hooks), реализованные в ядре для принудительного исполнения. Кроме того, помимо дополнительных накладных расходов, можно столкнуться с некоторыми проблемами совместимости с gVisor. На практике чрезвычайно сложно универсально определить его, что делает его пригодным для небольшого количества приложений, в которых поверхность достаточно мала для применения индивидуальной политики безопасности. Убедили, как мне этого добиться? Благодаря спецификации времени выполнения OCI, интегрировать gVisor проще простого. Показываем, как можно запустить (и проверить) безопасные рабочие процессы на GKE с помощью нескольких шагов: Убедитесь, что у вас есть пул узлов с включенной sandbox gvisor. Например, если используется команда CLI, обязательно укажите --sandbox type=gvisor (см.: https://cloud.google.com/kubernetes-engine/docs/concepts/sandbox-pods). Убедитесь, что gVisor включен. Это можно сделать с помощью следующей команды: Если вы найдете тип времени выполнения gVisor, похожий на приведенный выше  — это хороший знак. Убедитесь, что поле спецификации вашего pod’а YAML spec.template.spec.runtimeClassName установлено на gvisor. Например:  Совет специально для GKE, убедитесь, что вся конфигурация собрана воедино — можно проверить с помощьюkubectl exec ваши pod'ы рабочей нагрузки и убедиться, что команда везвращает пустой ответ: gVisor может стать отличным решением для защиты ваших рабочих нагрузок с помощью сверхпрочной настройки в среде Docker и Kubernetes благодаря спецификации времени выполнения OCI. Наслаждайтесь вашими новыми (более) защищенными рабочими нагрузками! Прочность цепи равна прочности самого слабого звена. Кто самое слабое звено в вашем кластере — безопасник, который не знает Kubernetes? Девопс, который не настраивает безопасность? Разработчик, который пишет манифесты для своего приложения?   Узнайте об этом на курсе Слёрма по безопасности в Kubernetes — старт в любое время! А всех, кто уже работал с Kubernetes и хочет изучить кластер подробнее, мы приглашаем на курс «Kubernetes: Мега». На нём рассмотрим авторизацию в кластере, автоскейлинг, резервное копирование и другие вещи, касающиеся продвинутой эксплуатации k8s. Вас ждут 13 онлайн-встреч со спикерами по 1-1,5 часа, более 6 часов практики на стендах, групповой чат с куратором и итоговая сертификация.  Что еще будет:  создадим отказоустойчивый кластер в ручном режиме; авторизация в кластере; настройка autoscaling; резервное копирование;  Stateful приложения в кластере; интеграция Kubernets и Vault для хранения секретов; HorizontalPodAutoscaler; ротация сертификатов в кластере; Blue-Green Deploy и Canary Deploy; настройка Service mesh. Для всех, кто собирается запускать Kubernetes в продакшн и отвечать за его работу в дальнейшем. Применение углубленных знаний о k8s поможет компании сэкономить сотни тысяч рублей, а также повысить вашу ценность, как специалиста.  Для администраторов кластеров и баз данных, DevOps’ов, специалистов по безопасности, архитекторов и инфраструктурных разработчиков, которые давно работают с k8s, хотят глубже понять тонкости и научиться реализовывать сложные сценарии. Главный результат познания Kubernetes — уменьшается time-to-market продукта. Это важно, потому что обычно ожидание становится критичным для команды эксплуатации, пока продукт непрерывно улучшают. С K8s можно быстро поднять себе в stage-кластере инфраструктуру, протестироваться на ней, поэкспериментировать и что-то выкатить.  Обучение состоит исключительно из практических примеров, а теория направлена на на более глубокое понимание, что же находится под капотом Kubernetes. Мы в тестовом режиме запустили подписку, в которую входят 20 курсов Слёрм. За 50 000 рублей вы можете пройти интересные вам программы из списка в течение трех месяцев. Стоимость видеокурса «Kubernetes: Мега» без подписки — 70 000 рублей, а с подпиской вы получите гораздо больше знаний на 20 000 дешевле. Оформите подписку до 21 марта и успейте собрать все сливки! Узнать подробности и записаться.