Безопасность: Yaml Bomb: пользователь может перезапустить kube-api, отправив configmap

Question

Создать yaml-bomb.yaml файл:

apiVersion: v1
data:
  a: &a ["web","web","web","web","web","web","web","web","web"]
  b: &b [*a,*a,*a,*a,*a,*a,*a,*a,*a]
  c: &c [*b,*b,*b,*b,*b,*b,*b,*b,*b]
  d: &d [*c,*c,*c,*c,*c,*c,*c,*c,*c]
  e: &e [*d,*d,*d,*d,*d,*d,*d,*d,*d]
  f: &f [*e,*e,*e,*e,*e,*e,*e,*e,*e]
  g: &g [*f,*f,*f,*f,*f,*f,*f,*f,*f]
  h: &h [*g,*g,*g,*g,*g,*g,*g,*g,*g]
  i: &i [*h,*h,*h,*h,*h,*h,*h,*h,*h]
kind: ConfigMap
metadata:
  name: yaml-bomb
  namespace: default

Отправить ConfigMap запрос на создание в API Kubernetes с помощью cmd kubectl apply -f yaml-bomb.yaml.

kube-api Использование ЦП / памяти очень высокое,даже позже перезапускаются.

Как мы можем предотвратить такую ​​бомбу?

Answer 1

Это атака миллиардов смехов , которая может быть исправлена ​​только в процессоре YAML.

Обратите внимание, что Википедия здесь не так, когда говорится:

Атака «Миллиард смеха» должна существовать для любого формата файла, который может содержать ссылки, например, эта бомба YAML:

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

В качестве примера, сравните поведение онлайн PyYAMLсинтаксический анализатор и онлайн-анализатор NimYAML (полное раскрытие: моя работа) при вставке фрагмента кода.PyYAML не отвечает из-за загрузки памяти от расширяющихся псевдонимов, в то время как NimYAML не расширяет псевдонимы и, следовательно, отвечает быстро.

Удивительно, что Kubernetes страдает от этой проблемы;Я бы предположил, так как он написан на Go, что они могут правильно обрабатывать ссылки.Вы должны сообщить об ошибке, чтобы исправить это.

Answer 2

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

Интересно запустить это в кластере Kubernetes на моей локальной машине.показал, что всплеск ЦП был на стороне клиента (это процессорный процессор kubectl), а не на стороне сервера.

Если бы проблема была на стороне сервера, то возможные меры были бы использовать RBAC для минимизации доступа к созданию ConfigMap,и потенциально использовать контроллер доступа, такой как OPA , для просмотра манифестов до их применения к кластеру.

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

РЕДАКТИРОВАТЬ - Я думаю, где проблема проявляется, может быть до используемой версии кластера.Применение на стороне сервера завершено до бета-версии (должно быть включено по умолчанию) в 1.16.Таким образом, в кластере 1.16, возможно, это коснулось бы стороны сервера, а не стороны клиента.

РЕДАКТИРОВАТЬ - Просто установите кластер 1.16, по-прежнему показывая использование ЦП в качестве клиентской стороны в kubectl ...

РЕДАКТИРОВАТЬ - I 'Мы подали проблему для этого здесь и подтвердили, что DoS может быть достигнут на стороне сервера, используя curl вместо kubectl