简体   繁体   English

如何限制 Kubernetes 容器查看主机(K8s minion)操作系统上的块设备列表?

[英]How to restrict Kubernetes containers to view block devices list on host (K8s minion) os?

During a custom K8s flexvolume development, I observed that containers are able to view complete block devices list present on the K8s minion (host) where it is running over.在自定义 K8s flexvolume 开发过程中,我观察到容器能够查看其运行所在的 K8s minion(主机)上存在的完整块设备列表。 Basically "lsblk" command output on host os is also visible if executed "lsblk" over the containers.如果在容器上执行“lsblk”,主机操作系统上的“lsblk”命令输出基本上也是可见的。 Also if container c1 has a flexvolume v1 assigned and c2 has v2;此外,如果容器 c1 分配了一个 flexvolume v1 并且 c2 分配了 v2; and both c1, c2 runs over same K8s host then c1 os can see v1, v2 both in "lsblk" output.并且 c1、c2 都运行在同一个 K8s 主机上,然后 c1 os 可以在“lsblk”输出中看到 v1、v2。 Where c1 has only access to v1 and not v2 which is as expected but for certain security aspects, we do not want c1 os to view any block devices being accessed by c2 or specifically by K8s host.在 c1 只能访问 v1 而不能访问 v2 时,正如预期的那样,但出于某些安全方面的考虑,我们不希望 c1 os 查看 c2 或 K8s 主机正在访问的任何块设备。 K8s is using docker as containerization service. K8s 使用 docker 作为容器化服务。

Please can anyone guide here to achieve expected configuration.请任何人都可以在这里指导以实现预期的配置。 Is K8s Namespace way to go? K8s 命名空间是否可行? if yes, can you provide any example?如果是,你能提供任何例子吗? Thanks in advance.提前致谢。

  • Persistent volumes and host volumes/paths are not namespaced持久卷和主机卷/路径没有命名空间
  • However, persistent volume claims PVCs belong to a single namespace但是,持久卷声明 PVC 属于单个命名空间
  • You may consume the storage through PVCs so that each namespace has access to its own PVCs您可以通过 PVC 使用存储,以便每个命名空间都可以访问自己的 PVC
  • Separate containers/pods by namespaces按命名空间分隔容器/Pod
  • Dont use host volumes in production不要在生产中使用主机卷
  • Use podSecurityPolicy to allow specific volume types and deny others such as HostPaths使用 podSecurityPolicy 允许特定的卷类型并拒绝其他类型,例如 HostPaths

Additionally, a PV that is already bound to one PVC cannot be bound to another, regardless of namespace.此外,无论命名空间如何,已经绑定到一个 PVC 的 PV 不能绑定到另一个。 This means that even if a user attempts to craft a PVC which claims an existing PV from a different namespace, it will fail.这意味着即使用户尝试制作一个 PVC 来声明来自不同命名空间的现有 PV,它也会失败。 When using Trident, the PV and PVC are destroyed at the same time by default.使用Trident时,默认PV和PVC同时销毁。 This behavior can be changed so that PVs are retained, but a PV that was bound to a PVC once and then unbound can never be bound again.可以更改此行为,以便保留 PV,但一次绑定到 PVC 然后解除绑定的 PV 永远无法再次绑定。

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

use pod security polcieis to restrict pods not to access host paths and only access some specific volume types and pvs使用 pod security policieis 限制 pod 不能访问主机路径,只能访问某些特定的卷类型和 pvs

https://kubernetes.io/docs/concepts/policy/pod-security-policy/#volumes-and-file-systems 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

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM