Kubernetes中的命名空间和RBAC：在公共环境中足够实现租户隔离吗？

80次阅读

问题描述

最初，命名空间被创建用于在单个Kubernetes集群中实现逻辑分区，以防止命名冲突。随着时间的推移，情况发生了变化。虽然2016年的一篇文章中提到：

任何Kubernetes集群中的用户或资源都可以访问集群中的任何其他资源，而不管命名空间如何。因此，如果您需要保护或隔离资源，最终的命名空间是一个单独的Kubernetes集群…

现在，通过RBAC，可以在特定的命名空间上设置权限，从而限制经过身份验证的用户只能访问特定命名空间及其资源。所以，如果我理解正确，上述引用已经过时了。通过RBAC，可以确保用户或资源只能访问其自己的命名空间中的内容。这是正确的吗？我很难找到明确说明使用命名空间（带有RBAC）来隔离租户不会访问彼此内容的最新文档。有人使用命名空间和RBAC来隔离（不友好的）租户吗？CNCF有关于这个问题的明确声明吗？

如果是这样，从安全的角度来看，我们在这里讨论的是什么级别的隔离？显然，集群IP对所有租户都是可访问的，即使有配额限制，我可以想象出可能会破坏单个集群的简单DOS攻击。简单的RBAC配置错误可能会导致租户之间的数据泄漏，当然还存在实现错误和未来利用的风险。但是，如果我们认为这些问题是“可以接受的”，那么命名空间真的是一个用于租户隔离的好工具吗？

解决方案

请注意以下操作注意版本差异及修改前做好备份。

方案1

命名空间和RBAC只是实现租户隔离的一部分。它们可以将Kubernetes对象与其他Kubernetes对象隔离开来，但您还需要关注共享资源，如入口命名空间。如果容器共享工作节点，则需要强制执行资源限制。Kubernetes使用的默认网络模型是扁平的，DNS公开了其他命名空间中的服务和容器，并且开放的网络策略允许任何容器与任何其他容器通信。在多租户环境中，Kubernetes API也是共享的，这可能导致对Kubernetes基础架构本身的DoS攻击。如果允许用户以特权访问、主机绑定挂载、主机命名空间和可能的其他功能运行容器，他们可以逃脱容器隔离并在运行容器的主机上获得root访问权限。要安全地实现这些功能，都不是简单的事情。

方案2

有一个致力于多租户的SIG，所以我很难相信在4年内没有关于此问题的任何文档。
除了命名空间和RBAC，还有其他方法可以实现租户隔离。例如，您可以使用网络策略来限制容器之间的通信，使用资源配额来限制资源使用量，使用PodSecurityPolicy来限制容器的权限等。这些方法可以与命名空间和RBAC结合使用，以提供更强大的租户隔离。

总的来说，命名空间和RBAC可以提供一定程度的租户隔离，但要实现完全的隔离，还需要考虑其他因素，并采取适当的安全措施。