Все мы знакомы с контейнерами и любим их. Контейнеры используют одно и то же ядро хоста (host kernel), что делает их довольно мобильным и лёгким решением. С другой стороны, мы бы предпочли снизить риск причинения вреда хост‑машине или операционной системе, чего можно достичь при помощи sandbox‑технологий, и gVisor является одной из них.

Давайте начнем с небольшой мотивации

Проверьте CVE-2020–14 386 — это уязвимость ядра Linux, приводящая к выходу из контейнера. В целом, эта уязвимость использует преимущество способности CAP_NET_RAW повреждать память, что приводит к получению злоумышленниками root‑доступа.

В Docker эта возможность включена по умолчанию (вероятно, это связано с тем фактом, что она обычно используется сетевыми инструментами, такими как ping и tcpdump, и может быть повторно включена для устранения неполадок).

Рабочие нагрузки, выполняемые с помощью gVisor, не были затронуты CVE — и это подводит нас к следующей части: пониманию, что такое gVisor и как можно его использовать.

Что такое gVisor?

Контейнерная среда sandbox gVisor — это среда процессов, которая запускает контейнеры.

Это, по сути, ядро приложения (написанное на Go ???? ), которое реализует значительную часть интерфейса системных вызовов Linux и обеспечивает дополнительный уровень изоляции между запущенными приложениями и операционной системой хоста.

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

Как это работает?

Каждая sandbox имеет свой собственный изолированный экземпляр Sentry и Gofer.

Gofer — обеспечивает доступ файловой системы к контейнерам.

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

Sentry — ядро приложения для контейнеров. 

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

Когда приложение выполняет системный вызов, вызовы перенаправляются на Sentry, который выполнит необходимую работу по его обслуживанию.

Например, Sentry не может открывать файлы напрямую: операции файловой системы, которые выходят за пределы sandbox’a, отправляются Gofer.

Платформа и runsc

Платформа 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 с помощью нескольких шагов:

1. Убедитесь, что у вас есть пул узлов с включенной sandbox gvisor. Например, если используется команда CLI, обязательно укажите --sandbox type=gvisor (см.: https://cloud.google.com/kubernetes-engine/docs/concepts/sandbox-pods).

gcloud container node-pools create smt-enabled \
    --cluster=CLUSTER_NAME \
    --machine-type=MACHINE_TYPE \
    --node-labels=cloud.google.com/gke-smt-disabled=false \
    --image-type=cos_containerd \
    --sandbox type=gvisor

2. Убедитесь, что gVisor включен. Это можно сделать с помощью следующей команды:

› kubectl get runtimeclasses
NAME     HANDLER   AGE
gvisor   gvisor    1d

Если вы найдете тип времени выполнения gVisor, похожий на приведенный выше  — это хороший знак.

3. Убедитесь, что поле спецификации вашего pod’а YAML spec.template.spec.runtimeClassName установлено на gvisor. Например:

# httpd.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: httpd
  labels:
    app: httpd
spec:
  replicas: 1
  selector:
    matchLabels:
      app: httpd
  template:
    metadata:
      labels:
        app: httpd
    spec:
      runtimeClassName: gvisor
      containers:
      - name: httpd
        image: httpd

Совет специально для GKE, убедитесь, что вся конфигурация собрана воедино — можно проверить с помощьюkubectl exec ваши pod'ы рабочей нагрузки и убедиться, что команда везвращает пустой ответ:

curl -s "http://metadata.google.internal/computeMetadata/v1/instance/attributes/kube-env" -H "Metadata-Flavor: Google"

Подводим итоги

gVisor может стать отличным решением для защиты ваших рабочих нагрузок с помощью сверхпрочной настройки в среде Docker и Kubernetes благодаря спецификации времени выполнения OCI. Наслаждайтесь вашими новыми (более) защищенными рабочими нагрузками!