Если вы работаете с Kubernetes, то монтирование файловой системы хоста в контейнер в виде тома должно не давать вам спать по ночам.
Позвольте мне объяснить почему.
Что такое “volume” (том)?
Поскольку контейнеры должны быть эфемерными и без статических данных, им необходим какой-то способ сохранения данных за пределами контейнера.
В некоторых случаях им даже требуется постоянное хранилище данных, доступ к которому можно получить даже после перезапуска контейнера.
Существует множество различных типов томов, например, тип тома awsElasticBlockStore.
Этот тип внешнего тома монтирует том EBS в ваш контейнер.
Если ваш контейнер перезапустится, новый контейнер смонтирует том EBS, чтобы забрать данные, сохраненные в предыдущем контейнере.
Но есть также возможность использовать локальное хранилище для сохранения данных.
Это означает использование файловой системы хоста воркер ноды Kubernetes.
Использование локального типа тома HostPath влечет за собой некоторые интересные последствия для безопасности.
В документации Kubernetes даже содержится конкретное предупреждение:
HostPath volumes present many security risks, and it is a best practice to avoid the use of HostPaths when possible. When a HostPath volume must be used, it should be scoped to only the required file or directory, and mounted as ReadOnly.
Если вы заинтересованы в глубоком понимании того, как работает монтирование контейнеров, я бы рекомендовал изучить основы пространства имен linux, в частности пространство имен mount.
Но это не обязательно для понимания остальной части этой статьи.
Как создать том?
Том может быть объявлен в yaml-манифесте Kubernetes.
Вы можете указать .spec.volumes вместе с .spec.containers[*].volumeMounts, чтобы определить, что это за том и куда его монтировать внутри контейнера.
Вот пример пода, создающего контейнер, который монтирует корневой каталог хоста в /host внутри контейнера.
apiVersion: v1 kind: Pod metadata: name: test-pd spec: containers: - image: alpine name: test-container command: ["tail"] args: ["-f", "/dev/null"] volumeMounts: - mountPath: /host name: test-volume volumes: - name: test-volume hostPath: # расположение каталога на хосте path: / # это поле является необязательным type: Directory
Если мы запустим этот под и провалимся в оболочку, мы увидим, что у нас есть доступ к корневой файловой системе хоста.
После этого мы можем прочитать содержимое /etc/shadow.
Полное содержимое не выводится, так как оно не соответствует ожидаемому формату лога, но это можно обойти, используя kubectl logs <pod> –tail=<номер строки> для просмотра полного содержимого.
Митигация рисков
Существует несколько способов защиты от возможных неправильных конфигураций, связанных с томами HostPath.
Масштабирование тома HostPath на определенный каталог.
Обязательно укажите каталог spec.volumes.hostpath.path, который является существенным. В противном случае избегайте использования HostPaths вообще.
Убедитесь, что том HostPath доступен только для чтения.
При монтировании тома вы можете установить его в режим только для чтения.
volumeMounts:
– mountPath: /var/log/host
name: test-volume
readOnly: true
Используйте оптимизированную для контейнеров ОС, например, Google’s Container Optimized OS или AWS’s Bottlerocket, которые по умолчанию включают корневые файловые системы только для чтения.
Ограничение доступа к томам HostPath через контроллер допуска.
Поскольку PodSecurityPolicies уже устарели, и на данный момент нет определенного стандарта, я рекомендую использовать Open Policy Agent Gatekeeper или Kyverno для определения политик вокруг томов HostPath.
Вот политика Kyverno ClusterPolicy, которая полностью запрещает HostPath:
https://kyverno.io/policies/pod-security/baseline/disallow-host-path/disallow-host-path/
см. также:
- ☸️ Какие типы сервисов существуют в Kubernetes?
- ☸️ Kubernetes и RBAC: ограничение доступа пользователя в одном namespace
- ☸️ Red-Kube – эмуляция Red Team для K8S на основе Kubectl
- ☸️ KubeArmor – система обеспечения безопасности выполнения контейнеров
- ☸️ Как быстро проверить файлы конфигурации Kubernetes
- ☸️ kube-beacon: выполняет аудит безопасности на основе спецификации CIS Kubernetes Benchmark
