Как ограничить контейнеры Kubernetes для просмотра списка блочных устройств на операционной системе хоста (minion K8s)?

Question

Во время пользовательской разработки flexvolume для K8s я заметил, что контейнеры могут просматривать полный список блочных устройств, представленных на миньоне K8s (хосте), где он работает. В основном вывод команды "lsblk" на хосте os также виден, если выполнить "lsblk" над контейнерами. Также, если контейнеру c1 присвоено значение v1, а c2 имеет v2 и оба c1, c2 работают на одном и том же хосте K8s, тогда c1 os может видеть v1, v2 оба в выводе "lsblk". Если c1 имеет доступ только к v1, а не к v2, как и ожидалось, но для определенных аспектов безопасности мы не хотим, чтобы c1 os просматривал какие-либо блочные устройства, к которым обращается c2 или, в частности, хост K8s. K8s использует докер в качестве службы контейнеризации.

Пожалуйста, кто-нибудь может направить сюда для достижения ожидаемой конфигурации. Является ли K8s Namespace подходом? если да, можете ли вы привести какой-либо пример? Заранее спасибо.

Answer 1

• Постоянные тома и тома / пути хоста не имеют пространства имен
• Однако постоянные тома утверждают, что PVC принадлежат одному пространству имен
• Вы можете использовать хранилище через PVC, чтобы каждое пространство имен имело доступ к своим собственным PVC
• Отдельные контейнеры / контейнеры по пространствам имен
• Не использовать тома хоста в производстве
• Используйте podSecurityPolicy, чтобы разрешить определенные типы томов и запретить другие, такие как HostPaths

Кроме того, PV, который уже связан с одним PVC, не может быть связан с другой, независимо от пространства имен. Это означает, что даже если пользователь пытается создать ПВХ, который требует существующего PV из другого Пространство имен, это не удастся. При использовании Trident PV и PVC уничтожено в то же время по умолчанию. Это поведение можно изменить так что PV сохраняются, но PV, который был связан с ПВХ один раз, а затем unbound больше никогда не может быть связан.

https://netapp.io/2018/06/15/highly-secure-kubernetes-persistent-volumes/

использовать pod security polcieis, чтобы запретить модулям не обращаться к путям хоста, а только к некоторым определенным типам томов и pvs

https://kubernetes.io/docs/concepts/policy/pod-security-policy/#volumes-and-file-systems

AllowedHostPaths - See Volumes and file systems.

Volumes and file systems
Volumes - Provides a whitelist of allowed volume types. The allowable values correspond to the volume sources that are defined when creating a volume. For the complete list of volume types, see Types of Volumes. Additionally, * may be used to allow all volume types.

The recommended minimum set of allowed volumes for new PSPs are:

configMap
downwardAPI
emptyDir
persistentVolumeClaim
secret
projected